Skip to content

MCP & AI agents ​

BootForm has a full MCP (Model Context Protocol) server, so an AI coding agent - Claude Code, Cursor, VS Code, Claude Desktop, ChatGPT, or anything else that speaks MCP - can set up your forms without you opening the dashboard. You connect once: your client opens the browser, you sign in to BootForm (or create a free account) and click Allow. There is no API key to create, copy or paste. MCP access is included on every plan, including Free.

Quick start (Claude Code) ​

bash
claude mcp add --transport http bootform https://mcp.bootform.com/mcp

Then run /mcp in Claude Code, pick bootform and choose Authenticate. Your browser opens on BootForm's sign-in page; sign in or create an account, check the app name, and click Allow. Back in Claude Code, ask something like "Add a contact form to my site using BootForm."

You stay connected: the client refreshes its access in the background, so you only sign in again if you disconnect it, or after 90 days without using it.

How connecting works ​

  1. You add the server URL to your client: https://mcp.bootform.com/mcp. No headers, no key.
  2. The first time the client talks to BootForm, BootForm answers that it needs you to sign in, and your client opens the browser on app.bootform.com.
  3. You sign in (or sign up), see which app is asking and where it will send you back, and click Allow. If you belong to a team, you also choose which account the app works in. Signed in as the wrong person? Click Not you? Use another account: you sign out, sign in as someone else, and come back to the same request.
  4. The browser hands control back to the client, which now has its own access to that one account.

The app gets the same permissions you have in that account in the dashboard. On your own account that is everything; on a team account it is your role there (a Viewer can list forms, get snippets and read submissions; an Editor can also create, change and delete forms, add notifications and mark or moderate submissions). To work in a different account, disconnect and connect again, choosing the other account.

Add BootForm to your client ​

The URL is the same everywhere: https://mcp.bootform.com/mcp. Leave out any headers or Authorization settings; the client asks you to sign in by itself.

Claude Code ​

bash
claude mcp add --transport http bootform https://mcp.bootform.com/mcp

Then /mcp → bootform → Authenticate.

Claude Desktop ​

Settings → Connectors → Add custom connector, name it BootForm and paste https://mcp.bootform.com/mcp. Leave the OAuth client ID and secret empty, then click Connect and sign in in the browser. (This is the Connectors screen, not claude_desktop_config.json, which is only for local servers.)

ChatGPT ​

Turn on Developer mode, add a developer-mode app for the remote server https://mcp.bootform.com/mcp, and choose OAuth as the authentication. ChatGPT opens the BootForm sign-in when you connect. Developer mode needs a paid ChatGPT plan (it is not offered on Free), and on a Business or Enterprise workspace an admin has to allow it.

VS Code (GitHub Copilot) ​

In VS Code, MCP tools are used by GitHub Copilot Chat in Agent mode, so sign in to Copilot first (the free tier is enough). Then, in the editor rather than the chat:

  1. Press Ctrl+Shift+P (Cmd+Shift+P on a Mac) and run MCP: Add Server.
  2. Choose HTTP, paste https://mcp.bootform.com/mcp, name it bootform and pick Global. Recent versions offer Copilot Global (~/.copilot/mcp-config.json, shared with Copilot CLI); pick that one.
  3. VS Code asks to authenticate the server and opens the browser: sign in and click Allow. If it does not ask, run MCP: List Servers, pick bootform and choose Start Server.
  4. Open Copilot Chat, switch it to Agent, and check the BootForm tools under the tools icon.

Asking the chat to "set up BootForm" does not run the sign-in: the browser step is VS Code's own, and only starts from the commands above.

Clients configured with a JSON file ​

Each tab shows that client's own config shape - the key names genuinely differ, and using another client's spelling is the most common way to end up with a server that never connects.

json
// ~/.cursor/mcp.json (global) or .cursor/mcp.json (project)
{
  "mcpServers": {
    "bootform": {
      "url": "https://mcp.bootform.com/mcp"
    }
  }
}
json
// .vscode/mcp.json (workspace). For a global setup, use "MCP: Add Server" instead (see above).
{
  "servers": {
    "bootform": {
      "type": "http",
      "url": "https://mcp.bootform.com/mcp"
    }
  }
}
json
// ~/.codeium/windsurf/mcp_config.json
{
  "mcpServers": {
    "bootform": {
      "serverUrl": "https://mcp.bootform.com/mcp"
    }
  }
}
json
// settings.json, via the "zed: open settings file" command
{
  "context_servers": {
    "bootform": {
      "url": "https://mcp.bootform.com/mcp"
    }
  }
}
json
// ~/.cline/mcp.json for the CLI; in the IDE extension use the MCP Servers panel
{
  "mcpServers": {
    "bootform": {
      "type": "streamableHttp",
      "url": "https://mcp.bootform.com/mcp",
      "disabled": false,
      "autoApprove": []
    }
  }
}
json
// ~/.gemini/settings.json (user) or .gemini/settings.json (project)
{
  "mcpServers": {
    "bootform": {
      "httpUrl": "https://mcp.bootform.com/mcp"
    }
  }
}

The one thing to get right in each:

ClientWatch out for
CursorNo type/transport key on a remote server - it's inferred.
VS Code"type": "http". VS Code shows a sign-in prompt the first time the server starts.
WindsurfThe key is serverUrl, not url. Using url is the most common Windsurf misconfiguration.
ZedTop-level key is context_servers, not mcpServers.
Cline"type": "streamableHttp" - camelCase, no hyphen. Omit it or write streamable-http and Cline drops to legacy SSE and fails.
Gemini CLIUse httpUrl, not url. url means SSE to Gemini.

Anything else: the mcp-remote bridge ​

For a client that only speaks stdio, mcp-remote proxies to the remote server and handles the browser sign-in itself:

json
{
  "mcpServers": {
    "bootform": {
      "command": "npx",
      "args": ["mcp-remote", "https://mcp.bootform.com/mcp", "--transport", "http-only"]
    }
  }
}

The server speaks Streamable HTTP. Pick your client's "HTTP" or "Streamable HTTP" option, not "SSE". Older setups used https://mcp.bootform.com/sse; that path still works and is the same server (the name is historical, it is not an SSE endpoint), but /mcp is the one to use from now on.

Moved from an API key? ​

API keys no longer work on the MCP server. If your client config has an Authorization: Bearer bf_live_... header or a ?api_key= URL, remove it, point the server at https://mcp.bootform.com/mcp, and connect again: the client opens the browser so you can sign in. Until you do, the server answers 401 with a message saying so.

Restart your client after changing the config, then sign in. A client that is already running can keep the old entry loaded: in Claude Code, claude mcp remove bootform followed by claude mcp add in the same session saved the new sign-in against the old ?api_key= URL, and the server refused it until Claude Code was restarted.

API keys still work on the REST API, for scripts, Zapier, Make and anything else that calls BootForm over HTTP.

Available tools ​

ToolMinimum team roleWhat it does
bootform_create_formEditorCreates a form on the connected account (in a given workspace, or the default one) and returns its live endpoint and a ready-to-paste snippet
bootform_get_snippetViewerReturns a ready-to-paste HTML snippet for one of the account's forms
bootform_configure_formEditorUpdates a form's name, allowed origins, redirect, or subject template, moves it to another workspace (workspace_id), turns the honeypot on or off (honeypot_enabled) or renames its field (honeypot_field), and turns on the moderated content feed (content_feed_enabled, public_fields, report_threshold; Pro plan or higher). After a honeypot change it returns the exact line your page needs
bootform_list_formsViewerLists every form on the connected account, each with its spam protection: honeypot on or off, the honeypot field's name, and whether a CAPTCHA is set up (never a key), plus its spam alert when it has one
bootform_get_accountViewerShows which account the connection works in and your role there, its plan, submissions and storage used against the plan's limits, form/workspace/verified-email counts, and the other accounts you could connect to instead. Billing details (cadence, renewal date) only for an Admin
bootform_list_workspacesViewerLists the account's workspaces (groups of forms), with their form counts and shared defaults
bootform_create_workspaceEditorCreates a workspace, optionally with default allowed origins and time zone (Pro plan or higher)
bootform_configure_workspaceEditorRenames a workspace or changes the defaults its forms inherit
bootform_delete_workspaceEditorDeletes a workspace. Its forms move to the default workspace (never deleted); requires confirm: true
bootform_delete_formEditorPermanently deletes a form and all its submissions - irreversible, requires an explicit confirm: true. The form disappears at once (status deleting) and its data is removed in the background
bootform_add_emailEditorAdds an email notification recipient to a form. The address must be verified for the account first
bootform_add_verified_emailEditorEmails an address a confirmation link so it can receive notifications. Someone must click the link; until then the address is pending. On a pending address it sends a fresh link
bootform_list_verified_emailsViewerLists the account's notification addresses, each pending or verified
bootform_remove_verified_emailEditorRemoves an address from the account's verified emails. Forms already sending to it keep sending until you remove those destinations
bootform_add_discordEditorAdds a Discord webhook notification destination
bootform_add_slackEditorAdds a Slack webhook notification destination (Starter plan or higher)
bootform_add_webhookEditorAdds an outgoing webhook notification destination (Starter plan or higher)
bootform_list_destinationsViewerLists where a form sends its submissions, with ids. Webhook URLs are masked (host and last 4 characters), header values never shown
bootform_remove_destinationEditorRemoves one notification destination from a form
bootform_get_submissionsViewerLists recent submissions for a form from the inbox, or from the spam folder with spam: true; optionally only read or unread ones
bootform_mark_submissionEditorMarks a submission read/unread, starred/unstarred, archived/unarchived, and moves it to spam or back to the inbox (spam). Moving only changes the folder: no late notification, no quota change
bootform_delete_submissionsEditorPermanently deletes up to 200 listed submissions of one form, with their files. Irreversible, requires confirm: true, and only takes ids the agent has listed (no "delete everything")
bootform_check_spamViewerChecks a form for a spam problem: inbox and spam counts over the last 14 days (up to 90), why the spam was caught, the form's spam protection, and inbox signals such as links, bursts from one address and identical messages. Facts, not a verdict
bootform_moderate_submissionEditorApproves or rejects a submission for the form's public moderated content feed

The role column only matters on a team account; on your own account every tool is available. Every tool call applies the same plan-limit checks as the REST API (quota, email recipient cap, integration availability), so a call that would fail over REST fails the same way here, with the same error code. A call your role doesn't allow returns FORBIDDEN and changes nothing. Every tool also tells your MCP client whether it only reads, whether it can delete something, and whether it reaches outside BootForm, so a client that asks before risky actions knows which calls those are.

To send notifications to a new address, the agent calls bootform_add_verified_email, you click the link in that inbox, and then bootform_add_email accepts the address. The click is the one step that stays with a person: it proves the inbox belongs to someone who wants the notifications.

Connected apps and security ​

  • Every connection is listed under Settings → Connected Apps: which app, who connected it, which account, and when it was last used. Disconnect cuts it off on its next request. An admin of a team account also sees, and can disconnect, teammates' connections to it.
  • Connecting and disconnecting are recorded in the account's activity log, and so is every change an app makes (shown as "you (via MCP)").
  • The consent page always shows where the browser will return. Only allow apps you started connecting yourself.
  • Nothing secret ever passes through the chat: the client keeps its own access, the model never sees it, and there is no key for an agent to ask you for.
  • bootform_delete_form is genuinely irreversible - forms and submissions deleted through it don't come back, and the form's ID is retired for good. Its confirm: true requirement is the only safety gate.
  • Anything an agent adds it can also take away: bootform_remove_destination, bootform_remove_verified_email and bootform_delete_workspace. Deleting a workspace never deletes its forms; they move to your default workspace, and there is no undo that moves them back, so the agent asks first.
  • bootform_delete_submissions is irreversible too, like Delete in the dashboard. Each call is recorded in the activity log with the form and how many were deleted (never what they said).

Fighting spam with an agent ​

Tell your agent "I'm getting spam on my contact form". It runs bootform_check_spam, reads a few of the submissions, and suggests fixes in this order:

  1. If the honeypot is off, turn it on and add its hidden field to your page.
  2. If it's on and spam still gets through, set up Cloudflare Turnstile in the dashboard. Renaming the hidden field doesn't help: these bots leave every hidden field empty. CAPTCHA keys never go through the agent.

It can then move the spam it found to the Spam folder or delete it, but it names the submissions and asks you first.

You don't always have to ask: when a form has a spam alert, bootform_list_forms shows it as spam_alert (counts only), and the agent mentions it and offers to check the form and set up Turnstile.

Claude Code skills ​

If you use Claude Code, the bootform plugin bundles the MCP connection with skills that know the right steps:

/plugin marketplace add BootForm/site-skills
/plugin install bootform@site-skills

That gives you /bootform:add-contact-form (a real form on any site; the first use signs you in, and creates your free account if you don't have one), /bootform:style-form, and /bootform:show-submissions (approved submissions shown on your site from the content feed, photos included), and /bootform:fix-spam (checks a form for spam, then turns on the honeypot and cleans up once you agree). The same marketplace has a vitepress plugin for starting and growing a whole site from a template. Details: github.com/BootForm/site-skills.

Showing submissions on a site ​

An agent asked to "collect submissions and show them on the page" should use the moderated content feed, not build a backend: it's a public, key-free, CORS-open list of the submissions the owner approved, photos included (Pro plan and up). The MCP tools cover the whole setup: bootform_create_form, bootform_configure_form with content_feed_enabled: true and the public_fields to show (file fields like photo included), then bootform_moderate_submission to approve each submission. The site itself reads https://f.bootform.com/forms/{form_id}/feed directly, with no MCP call and no key.

For AI agents reading this directly ​

A condensed, machine-readable summary of the whole platform (not just MCP) is available at llms.txt, with a fuller version at llms-full.txt - useful context to load before making tool calls.

Clients that discover servers on their own can find BootForm through its MCP Server Card, which bootform.com lists in its AI Catalog at /.well-known/ai-catalog.json. The card only says who the server is and where to connect; sign-in still happens through the browser as described above.