Skip to main content
AnyCRM exposes a Model Context Protocol server at /mcp, on the same origin and port as the REST API. It’s a tool-calling surface over the same data — every tool enforces the same scopes as the equivalent REST endpoint, isolated to the same organization by the same row-level security. If you’re wiring up an agent rather than a script, MCP is usually the more convenient integration point; if you’re calling the API directly from code, use the REST reference instead.
MCP and the REST API are two views of the same backend, not two different products. A tool call and the equivalent curl request run through the same authorization checks and hit the same database rows.
You connect by signing in with your AnyCRM account. There’s nothing to paste and no key to manage — and no other way in: API keys and personal access tokens are for the REST API and are refused here, so a connection has exactly one identity and one thing to revoke.

​
Transport

The server speaks streamable HTTP (not stdio, not SSE) and is stateless — there’s no session handshake or sticky routing to worry about; any request can be served by any backend process. The endpoint is:

​
Connecting

You don’t need to create a key. Point your client at the endpoint and it will walk you through signing in:
The first time the client connects, your browser opens on an AnyCRM approval screen. Sign in if you aren’t already, pick which organization the connection should start in (you’ll only be asked if you belong to more than one), and approve. The browser hands the connection back to your client and you’re done.

​
When a connection ends

Nothing expires on a timer. An access token lasts an hour and the client renews it silently, and the refresh token behind it has no expiry of its own, so an approved connection keeps working indefinitely. What ends one:
  • You disconnect it in Settings → Tokens. It stops on the very next request, and the client will ask you to sign in again the next time it’s used.
  • It sits unused for 180 days (MCP_OAUTH_IDLE_DAYS). This catches a client left on a device nobody uses any more, where no other check would ever fail. Expired connections are retired for real on a weekly sweep, so their credentials do not linger in the identity provider. If you run a scheduled agent that fires less often than that, set the variable to 0 for that deployment.
  • Its refresh token is replayed. Each refresh issues a new one and retires the old; if a retired token is ever presented again, that means a copy was taken, so the whole connection is revoked rather than just that request refused.
In every case the next call gets a 401 carrying the standard OAuth challenge, which is the client’s cue to reopen the approval screen. So a revoked connection prompts you to reconnect rather than failing silently.
The connection acts as you. Whatever your role lets you do in the web app is exactly what it can do — no more. Change someone’s role and their connection follows within about five minutes; remove them from an organization and it loses that organization within about a minute. Disconnecting takes effect on the very next request.
This is standard OAuth 2.1 with PKCE, so any MCP client that supports it works the same way: Claude Desktop, Claude Code, VS Code, Cursor, or your own. A client identifies itself one of two ways. It can publish a client id metadata document at an https URL and use that URL as its client id, in which case its name and logo come from the origin that claims them. Otherwise it registers dynamically and supplies those details itself, which is why the approval screen shows the redirect target rather than taking a self-chosen name at face value.

​
Working across organizations

A connection isn’t locked to the organization you picked. It can reach every organization you belong to, two ways:
  • switch_organization changes where the connection works from now on, and it sticks — including in later conversations. Ask for it by name: “switch to Globex”.
  • The organization argument, which every tool accepts, redirects a single call without changing anything: “how many open deals does Globex have?” while you stay in Initech.
list_organizations shows what’s available and which one is active. Both resolve the organization against your live memberships on every call (cached for at most a minute), so neither can reach one you aren’t in.

​
Seeing and disconnecting your connections

Every approved connection is listed in the web app under Settings → Tokens, with the client’s name, the organization it’s working in, and when it was last used. Disconnect one there and it stops working on its very next request. Organization admins also see connections belonging to other members of their own organization, and can disconnect those — the same way they can already see other members’ API keys.

​
Unattended agents

Approving a connection needs a person at a browser once. After that the client holds a refresh token that doesn’t expire on its own, so a server-side agent or a scheduled job keeps working indefinitely without anyone signing in again — set it up once, and revoke it from Settings when you’re done. If you need a credential with no human step at all, that’s what the REST API and its organization API keys are for. MCP accepts connections only.

​
What the server tells a connecting client

On initialize, the server describes itself with a short system-level brief that orients a model to AnyCRM’s data model:
AnyCRM — a B2B sales CRM. Accounts are companies, deals are opportunities on an account, and contacts are people. Contacts use a single funnel stage: target (added, no reply) → lead (responded) → contact (converted). There is no separate “lead” record — filter contacts by stage instead. Prefer resolving records by name; tools accept either a name or a UUID and will tell you when a name is ambiguous rather than guessing.
That last point matters operationally: most tools accept a plain name in place of a UUID and resolve it server-side, refusing to guess if the name is ambiguous — see Name and ID resolution.

​
Configuration reference

These are deployment-level settings — you can’t change them from a client, but they explain what a given AnyCRM deployment will and won’t let an MCP client do. There is no deployment flag that makes MCP read-only. A connection can do whatever its owner can do in the web app, so give a user a read-only role if that is the access you want their AI client to have. There is no MCP_ENABLED switch — the /mcp mount itself is always present; these variables only shape which tools it advertises. See Available Tools for the full tool inventory, or Safety, Scopes & Errors for how permissions, idempotency, and error reporting work.