An MCP Server for Forms: Let Your AI Agent Manage Form Submissions

The Model Context Protocol (MCP) is a standard way to hand an AI assistant a set of tools it can actually call. Without it, an agent that wants to use a service has to read API docs, compose raw HTTP requests, and guess at authentication — workable, but slow and error-prone. With MCP, the service publishes a small server that says, in a machine-readable way: "here are my tools, here's what each one is called, here are the exact inputs it takes." The agent sees typed, named operations — create_form, get_submissions — the way your IDE sees functions with signatures, instead of a wall of prose documentation.

The plumbing is deliberately boring: an MCP server is usually a small local program your AI client launches in the background and talks to over stdin/stdout. You add a few lines of config once, restart the client, and from then on every conversation can use those tools. Think of it as a USB port for AI assistants — one connector standard, and any tool that speaks it plugs into Claude Desktop, Claude Code, Cursor, and a growing list of other clients without custom integration work for each.

formslist-mcp exposes FormsList's AI-native form backend as seven tools:

• instant_provision — mint a live form endpoint for any email, no account or API key needed.
• create_form — create a named, permanent form in your account.
• list_forms — enumerate every form in the account.
• get_form — inspect one form's details and settings.
• get_submissions — read a form's submissions, paginated.
• configure_autoresponse — set up the automatic reply email sent to submitters.
• get_embed_snippet — generate ready-to-paste HTML (and an AJAX example) for any endpoint.

Two of the seven — instant_provision and get_embed_snippet — work with zero configuration. The other five authenticate with a FormsList API key (prefix ff_sk_), created in about ten seconds at /account/api-keys and available free on every plan. The server lives in the mcp/ directory of our repo and is coming to npm as formslist-mcp.

Clone and build once (until the npm package lands, after which this becomes a single npx):

git clone https://github.com/formslist/formslist-mcp
cd formslist-mcp && npm install && npm run build

Claude Desktop — add to claude_desktop_config.json (macOS: ~/Library/Application Support/Claude/), then restart the app:

{
  "mcpServers": {
    "formslist": {
      "command": "node",
      "args": ["/path/to/formslist-mcp/dist/index.js"],
      "env": { "FORMSLIST_API_KEY": "ff_sk_your_key_here" }
    }
  }
}

Claude Code — one command in your terminal:

claude mcp add formslist -e FORMSLIST_API_KEY=ff_sk_your_key_here \
  -- node /path/to/formslist-mcp/dist/index.js

Cursor — add the same JSON block to .cursor/mcp.json in your project (or ~/.cursor/mcp.json for all projects):

{
  "mcpServers": {
    "formslist": {
      "command": "node",
      "args": ["/path/to/formslist-mcp/dist/index.js"],
      "env": { "FORMSLIST_API_KEY": "ff_sk_your_key_here" }
    }
  }
}

In every case the env block (or -e flag) is optional — omit it and the two keyless tools still work fully. Add the key whenever you want the agent managing forms you own.

instant_provision is the star. Give it an email address (and optionally a form name) and it returns a live endpoint at https://formslist.com/f/<hash>, a paste-ready html_snippet, a curl_example for testing, and a claim_url that's also emailed to the owner. The form works immediately; the human claims it into a dashboard account later — the full flow is our 10-second contact form tutorial. Prompts that exercise it:

• "Add a contact form to this site — provision a FormsList endpoint for hello@mysite.com and wire it into the contact page."
• "Set up a bug-report form for reports@myapp.dev and send a test submission to verify it works."

get_embed_snippet is a pure generator: hand it any form hash and it builds the HTML <form> markup plus a fetch()-based AJAX example that posts to that endpoint. It makes no API call at all, so it needs no key. Useful prompt:

• "Generate an AJAX submission snippet for form x7k2m9qa and integrate it into the React contact component."

Between the two, an agent can go from "this site needs a form" to "the form is live and embedded" without you touching a browser, a dashboard, or a credential.

With FORMSLIST_API_KEY set, five more tools open up. What each does, with a prompt that works verbatim:

• create_form — creates a named, permanent form directly in your account (no claim step, since you're authenticated). "Create a form called 'Careers Applications' and put its endpoint in the jobs page."
• list_forms — enumerates your forms with their hashes and stats; usually the agent's first call when you reference a form by name. "Which of my forms got submissions this month?"
• get_form — full detail on one form: settings, endpoint, notification config. "Check whether the newsletter form still points at my old email."
• get_submissions — reads submissions with pagination. This is the tool that turns your editor into a lead-review interface. "Summarize this week's contact form submissions and flag anything that looks like a sales lead."
• configure_autoresponse — enables and edits the automatic reply (subject, HTML body, from-name) sent to people who submit. If your plan doesn't include auto-responses, the tool returns the upgrade message and link instead of erroring — so the agent can tell you exactly what's needed rather than failing cryptically. "Set up an auto-response on the contact form thanking people and promising a reply within one business day."

Notice what's not in the list: there are no delete or bulk-modify tools. The server is deliberately scoped to create, read, and configure — an agent acting on your behalf can't destroy data through it.

The MCP server and the v1 REST API hit the same backend, so this is a question of ergonomics, not capability.

Use MCP when a person is driving an agent interactively. Day-to-day work in Claude Code, Claude Desktop, or Cursor — "add a form," "check my leads," "set up an auto-response" — is where typed tools shine. The agent doesn't need docs in context, can't mistype an endpoint, and gets structured errors it can act on. Configure once, benefit in every session.

Use REST when there's no MCP client in the loop. CI pipelines, cron jobs, your own product's backend, a script that provisions a form per customer — anything programmatic should just POST to the API with a Bearer ff_sk_ key. And for one-shot agents you don't control (a hosted site-builder, someone else's bot), the raw unauthenticated POST /api/v1/instant is the universal fallback: it works from any HTTP client with zero setup, and llms.txt plus the OpenAPI spec at /api/v1/openapi.json mean any LLM can discover it unaided.

A useful rule of thumb: if you'd naturally phrase the task as a sentence to your editor, it's an MCP job. If it runs on a schedule or inside other software, it's a REST job.

Handing an agent credentials deserves a moment of thought, so here's the exact trust model.

• The API key is account-scoped, not admin-scoped. An ff_sk_ key authorizes form operations — create, list, read submissions, configure — for your account via the v1 API. It cannot change your password, billing, or email, and the MCP server exposes no destructive tools regardless of key.
• Keys live in local config, not in conversations. The key sits in your MCP client's config file as an environment variable and travels straight from client to local server process. Prefer this to ever pasting a key into a chat, where it lands in conversation history.
• Keys are revocable in one click. Rotate or revoke at /account/api-keys any time; nothing else about your setup changes.
• The keyless mode can't touch existing data. With no key configured, the server can only mint new claim-later endpoints and generate HTML locally. Ownership of a provisioned form anchors to the recipient's email inbox — the claim link goes there — and unclaimed forms expire after 7 days, with per-IP and per-email rate limits on provisioning. An agent in keyless mode has no path to any submission ever sent to any form.

Practical recommendation: run keyless by default, and add the key on the machines where you actually want conversational form management. It's the same least-privilege instinct you'd apply to any credential.