CRM for developers
Where the tools come from, and the REST surface underneath them: one operation table behind the router, the OpenAPI document and this server.
Read it →POST/v1/tasks/{id}/claim
The CRM MCP server, one tool per operation
Point a client at /mcp, send the same bearer key the REST API takes, and 97 tools appear — one for every operation, generated from the table the routes are registered from. There is no hand-written tool layer to drift out of step with the product it describes.
What a CRM MCP server is
The short version, then the version that matters — what the term means in general, and what it turns out to mean when a product is actually built that way.
The shape you already know
Most tools an engineer touches now have one — GitHub, Slack, Postgres, Figma. A server speaks the Model Context Protocol so a model can call that product directly, and connecting it once makes its tools appear in the client. This is that, for a CRM.
What this one exposes
This CRM's operations, as tools: read the schema, write a company, claim a task, move a deal, add a field, run a saved view. Everything the REST API does, under the same key and the same role, with nothing added and nothing simplified away.
A generated tool layer against a written one
Every CRM with an MCP server got one somehow. What matters is what happens to it the week after an operation is added.
Coverage
A hand-written MCP wrapperThe dozen operations somebody had time for. The rest need a REST call the model cannot make.
Agent Native CRM97 tools — every operation but the one that serves the spec document itself.
Staying current
A hand-written MCP wrapperA new endpoint is a new tool somebody has to remember to write and describe.
Agent Native CRMA new operation is a new tool. The generation reads the same table the router registers from.
Argument schemas
A hand-written MCP wrapperWritten by hand, so a required field can be optional in the tool and rejected by the API.
Agent Native CRMDerived from the operation's own request schema, which is the schema the API validates against.
Permissions
A hand-written MCP wrapperA second authorisation path, and a second place for it to be wrong.
Agent Native CRMThe same key, the same role, the same forbidden. MCP is a transport, not a privilege level.
Naming
A hand-written MCP wrapperWhatever read well at the time, per tool.
Agent Native CRMThe operationId from the spec, which a test keeps unique across the whole surface.
What that looks like in calls
Every route named below is one this API serves — a test reads them back against the operation table and fails on anything invented. Read them in order and you have the argument on this page without the prose around it.
Connecting it is a URL and a key
The endpoint is /mcp, the transport is JSON-RPC over POST, and the credential is the bearer key a principal already holds. Nothing to install and nothing to run locally. The tool list is the operation list: names are operationIds, descriptions are the operation summaries, and argument schemas come from the request bodies the API validates against.
- GET /v1/openapi.json
- GET /v1/skill
- GET /v1/me
The first tools any agent should reach for
Read the workspace, find out who you are, then write something. This is the same order the skill file gives, because a tool call that guesses a field name costs a round trip and an error that lists the fields it should have used.
- GET /v1/schema
- GET /v1/me
- POST /v1/companies
Work moves through the same queue over MCP
List what is open, claim it, do the job with the client's other tools, close it with an outcome. A model that has a mailbox tool and this queue can run the whole loop, and the CRM records the half it can actually vouch for.
- GET /v1/tasks
- POST /v1/tasks/{id}/claim
- POST /v1/tasks/{id}/complete
- POST /v1/tasks
Everything else is there too, including the schema
Custom objects, fields, stages, activity types, saved views, principals and keys are all tools, because they are all operations. An MCP client can shape the workspace it is about to work in rather than filing a request and waiting.
- POST /v1/schema/fields
- POST /v1/schema/objects
- POST /v1/views
- GET /v1/views/{id}/records
GET/v1/activities
One operation table. A router, a spec and 97 tools that cannot disagree.
Where a person still decides
None of these is a setting somebody switches on. Most are enforced by the API itself; the rest are enforced by the fact that the work sits in a queue until somebody takes it.
The key decides, not the transport
An MCP session authenticates as a principal and inherits that principal's role exactly. There is no tool that does something the same key could not do over REST, which is what makes the permission model on this product one model rather than two.
Refusals arrive as refusals
409 do_not_contact, 409 already_claimed and 403 forbidden come back through MCP with the same codes and details. A model can tell the difference between work that failed and work somebody else already took.
The skill file is the prompt
GET /v1/skill returns the whole contract as markdown, served at /skill.md as well so an agent with only the domain can find it. It documents every path the API serves — a test fails the build if a route exists that it does not describe.
Reads are cheap and unmetered
Tool calls are API calls, and API calls are never rate limited. A model that reads the schema before every write is not paying for the caution, which is the only way that advice is honest.
POST/v1/tasks/{id}/claim
What you get back
Not a diagram of the architecture — the actual shape of the response the rest of this page is built on. Nothing in it was configured in a settings screen; every part of it is readable and writable over the same API.
GET /mcp
- tools
- 97, one per operation. The spec-fetching operation is the only one left out
- names
- The operationId from the spec — getSchema, createCompany, claimTask, moveDealStage
- arguments
- The operation's own request schema, so the tool and the API agree on required fields
- transport
- JSON-RPC over POST at /mcp. Nothing to install, and no local process to keep alive
- auth
- The principal's key. Same role, same permissions, same errors as REST
- docs
- /skill.md, the contract an agent should read before its first write
What this does not do
Said plainly, because each of these is a thing a product described this way is usually assumed to do, and an agent that assumes it will write code that never runs.
We are not an MCP gateway
This server exposes this CRM and nothing else. It will not proxy your mailbox, your data vendor or another SaaS product. An agent that needs those brings its own tools for them and writes the results here.
No tool sends a message
There is no sendEmail. The contact tools create and close tasks; the message inside one is delivered by the client, from its own account. A tool list that implied otherwise would be the most expensive kind of wrong.
Tools are not smaller than operations
There is no curated subset and no simplified tool that wraps three calls into one. Every operation is a tool, which means the list is long and honest rather than short and lossy.
Questions people ask before they build on it
Answered here rather than in a call, and answered the way they would be answered in a call.
What is a CRM MCP server?
An implementation of the Model Context Protocol that exposes a CRM's data and operations as tools an AI client can call. Instead of writing code against the REST API, the model discovers what it can do and calls it directly.
How do I connect an MCP client to this CRM?
Point the client at the /mcp endpoint on this domain and give it a bearer key issued to a principal. It lists tools over JSON-RPC and gets one back per operation. There is nothing to install, no local process to run and no second credential to manage.
How many MCP tools does this CRM expose?
97 — one for every operation in the API except the one that serves the OpenAPI document. They are generated from the same operation table the routes are registered from, so the list moves whenever the API does.
Do MCP tools have different permissions from the REST API?
No. An MCP session authenticates with a principal's key and inherits that role exactly. Anything refused over REST is refused here with the same code, and there is no tool that reaches something a key could not reach directly.
Can an MCP client change the data model?
Yes, if its role allows it. Adding fields, stages, activity types and whole custom objects are ordinary operations, so they are ordinary tools. Every change is logged as a schema_changed activity carrying the diff.
Can the MCP server send email or LinkedIn messages?
No. Contact channels exist as task shapes: a tool writes the message into a task payload and a person can review it, and the client that claims the task sends it from its own mailbox or account. This product delivers nothing.
Where to read next
The same product from a different angle. None of these repeats this page; each answers a question this one deliberately leaves alone.
CRM for AI agents
What an agent does once it is connected — identity, provenance, and the queue between several of them.
Read it →For agents
The quickstart, and the error vocabulary a client should branch on.
Read it →Start with an empty workspace
An agent can create one with no key, no invitation and no human, and shape it through the same API you are about to hand it. Your API calls are never rate limited and agents are never counted.