Skip to main content
The MCP server accepts two kinds of credential, and the difference is not just setup. It decides what the assistant can see. Claude and ChatGPT always use OAuth. Claude Code, Codex, Cursor, Gemini CLI, VS Code and Windsurf support both, and you choose by what you put in their config file: leave the credential out and the client signs you in over OAuth, supply one and the client reaches the whole workspace. Both routes hit the same server and expose the same tools.

​
OAuth, scoped to you

The assistant acts as the person who approved the connection. Every tool call runs with that person’s permissions, so listings come back filtered to what they can see, and a form they cannot open is refused rather than returned. That makes OAuth the better fit whenever a real person is driving the assistant, because the reach of the connection is the reach of that person’s account. Clients that add a server by URL discover everything else on their own. The server publishes its OAuth metadata at https://connect.neetoform.com/.well-known/oauth-authorization-server and registers each client automatically, so there is no client id or secret for you to create. What you see when you connect:
  1. Choose your workspace. Enter the subdomain of the workspace you want the assistant to reach. For acme.neetoform.com, enter acme. See Workspace subdomain.
  2. Sign in to that workspace, if you are not signed in already.
  3. Pick the workspaces to connect. When your email belongs to more than one workspace, the approval screen lists them all. The one you signed in to is always included; tick any others the same connection should reach.
  4. Authorize. The assistant is granted access as you, to each workspace you ticked.
One OAuth connection can therefore cover several workspaces. Name the one you mean in a prompt, or ask the assistant to list what it can reach. Every tool takes an optional workspace argument for this, and the ListWorkspaces tool reports the subdomains to pass.

​
API key, scoped to the workspace

An API key carries no identity. Every tool call covers the entire workspace, no matter whose machine the assistant runs on or who is typing. Two people sharing one key are indistinguishable to NeetoForm, and neither is limited to the forms they created. Because there is no user behind the key, the organization role checks do not run at all. Where OAuth refuses an action your role does not allow, an API key performs it. A key handed to someone with a Standard role therefore lets their assistant do what an Admin could, including inviting members and changing roles. That is what you want for automation that has to see everything, and what you do not want on a laptop belonging to someone who should only see their own work. The key is the same one the REST API uses. The REST API takes it in an X-Api-Key header; MCP clients send it as a bearer token instead:
API keys are created in your NeetoForm workspace settings. Learn how to generate your API key here.
A key belongs to one workspace. To let an assistant work with two workspaces, add the server twice with a different key and a different server name in each entry.
An API key reaches every form, submission and team member in the workspace and is not tied to a person, so it cannot be traced back to one either. Treat it like a password: keep it out of shared config files and commits, and revoke it if it leaks. Prefer OAuth wherever the client supports it.

​
How the three interfaces authenticate