> ## Documentation Index
> Fetch the complete documentation index at: https://apidocs.neetoform.com/llms.txt
> Use this file to discover all available pages before exploring further.

# NeetoForm MCP server

> Let an AI assistant read your forms and submissions and manage your team.

NeetoForm runs a hosted [Model Context Protocol](https://modelcontextprotocol.io)
server at `https://connect.neetoform.com/mcp/messages`. Point an assistant at
that URL and it can answer questions about your forms in your own words, without
you writing a request or handling an id.

There is nothing to install and nothing to run. The server is hosted by
NeetoForm; the assistant connects to it over HTTP.

## What an assistant can do

<CardGroup cols={2}>
  <Card title="Find forms" icon="magnifying-glass">
    Search by title, or list the active, archived or favorited forms in a
    workspace.
  </Card>

  <Card title="Read submissions" icon="inbox">
    Pull completed submissions for a form, with each answer next to the question
    it responds to.
  </Card>

  <Card title="Manage the team" icon="user-group">
    List members, invite people, change roles and profile fields, and deactivate
    accounts.
  </Card>

  <Card title="Work across workspaces" icon="buildings">
    One connection can reach every workspace you approved it for. Name the one
    you mean in the prompt.
  </Card>
</CardGroup>

The full list is on the [Tools](/mcp/tools) page.

## MCP vs CLI: which should I use?

NeetoForm's [CLI](/cli/introduction) reaches the same resources this server
does - forms, their submissions and team members. The server is ahead in one
place only: finding a form by title and reading that form's questions back,
which no `neetoform` command does. Past that neither can do more than the other,
so choose on how the work reaches NeetoForm.

### Reach for MCP when

* **The details live in your chat, not in your head.** Paste the thread where
  three people asked for access and they are invited with the role you name,
  with no address retyped. The CLI cannot see any of it.
* **The answers need reading, not matching.** Submissions carry free text - "what
  would you change?", "why did you cancel?" - and the assistant can go through
  two hundred of them and tell you which complaints keep repeating. `jq` only
  matches wording you already knew to look for.
* **One request should cover several steps.** "Find the onboarding feedback form,
  read last week's submissions and tell me who scored us below 5" is one
  sentence: search by title, pull the submissions, then judge - with no id copied
  between commands.
* **The person doing it does not use a terminal.** NeetoForm hosts the server, so
  there is nothing to install on the machine and nothing to keep updated.

### Reach for the CLI instead when

* **No AI assistant should be in the loop.** A nightly job that pulls yesterday's
  submissions into your own store runs the CLI with nothing but the binary and a
  workspace it is already signed in to - no assistant open, no model account, no
  tokens spent per run. Every call here needs something with model access
  running.
* **The output feeds another program.** The CLI prints a bare id for the next
  command, or the JSON envelope for `jq`, a spreadsheet or your own script. Here
  you get prose you would have to copy out by hand.
* **You are exporting thousands of submissions.** A form with 5,000 of them is 50
  pages at the maximum page size of 100, and every answer to every question comes
  back with each one. Here each page is a separate tool call whose whole payload
  lands in the assistant's context, and a list that long crowds out everything
  else. The CLI returns `total_pages` and `total_records` next to the records
  instead, so a shell loop walks all 50 pages unattended and writes each one to a
  file or into `jq`.
* **The run has to be repeatable and reviewable.** A command is the artifact: it
  records exactly what ran, against the same form id with the same page size, and
  repeats identically. Ask twice here and the assistant may take a different
  route.

<Tip>
  You can have both. Run [`neetoform setup claude`](/cli/ai-assistants) and the
  same assistant you are talking to here can drive the CLI too, so a
  plain-language request still ends in an exact command you can read, repeat
  and paste into a script.
</Tip>

<Warning>
  Ask your assistant to show you the addresses and the role before it invites or
  deactivates anyone. These tools act on your live workspace.
</Warning>

## Prerequisites

* A NeetoForm workspace and your [workspace subdomain](/getting-started/workspace-subdomain).
* An assistant that supports remote MCP servers. See
  [Connect your assistant](/mcp/connect) for the ones covered here.
* Optionally, an API key. It is needed only for workspace-scoped access, since
  every supported client can connect over OAuth instead. See
  [Authentication](/mcp/authentication).

## Pick how you connect first

The server takes two kinds of credential, and the choice decides what the
assistant can reach:

* **OAuth** scopes the connection to you, so the assistant sees what your
  account sees.
* **An API key** scopes it to the whole workspace, with no user attached.

That is a permissions boundary rather than a setup preference, so read
[Authentication](/mcp/authentication) before configuring a client.

## Where to go next

<CardGroup cols={2}>
  <Card title="Authentication" icon="shield-halved" href="/mcp/authentication">
    What OAuth and an API key each let the assistant see.
  </Card>

  <Card title="Connect your assistant" icon="plug" href="/mcp/connect">
    Server details and per client setup.
  </Card>

  <Card title="Examples" icon="comments" href="/mcp/examples">
    Prompts that work once you are connected.
  </Card>

  <Card title="Tools" icon="wrench" href="/mcp/tools">
    Every tool the server exposes.
  </Card>
</CardGroup>