Skip to main content
The NeetoForm MCP server lets your AI assistant manage forms and submissions from plain-language requests. Ask it to search for a form, read submissions, invite someone to the team, or change a member’s role, and it works with your NeetoForm workspace for you. MCP (Model Context Protocol) is an open standard that connects AI assistants to tools such as NeetoForm. You describe the task; the assistant uses the right tool.

​
What you can do

Find forms

Search by title, or list the active, archived, or favorited forms in a workspace.

Read submissions

Pull completed submissions for a form, with each answer next to the question it responds to.

Manage the team

List members, invite people, change roles and profile fields, and deactivate accounts.

Hand off the busywork

Ask your assistant to find last week’s onboarding submissions, invite a new hire, or fix a role for you.

​
MCP vs CLI: which should I use?

NeetoForm’s CLI reaches the same resources MCP does - forms, their submissions, team members, and the rest. 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. An email, a thread, or a pasted note turns into the invitation with no retyping. The CLI cannot see any of it.
  • You have not decided the steps yet. “Someone filled out the same form twice with different answers - work out which one to keep” means looking at what is there and choosing. A command can only carry out a decision you have already made.
  • One request should cover several steps. Search for the onboarding feedback form, pull last week’s submissions, and flag anyone who scored below 5, with no glue between commands.
  • The person doing it does not use a terminal. NeetoForm hosts the server, so there is nothing to install or 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 MCP call needs something with model access running.
  • The output feeds another program. The CLI prints a bare identifier or raw JSON for jq, a spreadsheet, or your own script. Here you get prose you would have to copy out by hand.
  • You are working through thousands of records. A form with 5,000 submissions 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 next to the records, so a shell loop walks all 50 pages unattended and writes each one to a file or into jq - the size of the list stops mattering.
  • The run has to be repeatable and reviewable. A command is the artifact: it records exactly what ran and repeats identically. Ask twice here and the assistant may take a different route.
You can have both. Run neetoform setup claude and the same assistant drives the CLI for you, so a plain-language request still ends in an exact command you can read, repeat, and paste into a script.
Ask your assistant to show you the addresses and the role before it invites or deactivates anyone. These tools act on your live workspace.

​
What you need

  • An AI assistant that supports MCP. Setup steps for Claude, ChatGPT, Claude Code, Codex, Cursor, Gemini CLI, VS Code with GitHub Copilot, Windsurf, and Antigravity are on Connect.
  • A NeetoForm API key, but only for workspace scoped access, and for Antigravity, where it is the only documented route. Every other client can sign you in over OAuth instead, which needs nothing beyond the server URL. See Authentication.
The choice decides what the assistant can reach: an OAuth connection acts as you and sees what you see, while an API key acts as the workspace and sees everything in it.
An OAuth connection is approved in the browser, much as the CLI signs you in, and you decide there whether the assistant may create, update, or delete. An API key is the same one the REST API uses, passed as a bearer token from your assistant’s config, and it carries every permission for the whole workspace.
Connect your assistant to get started.