What is an MCP server for a CRM?

What is the Model Context Protocol (MCP)?

Anthropic published the Model Context Protocol in November 2024 as an open standard for connecting AI assistants to the systems where data lives, from content repositories to business tools ^[1]. The project's own docs compare it to a USB-C port for AI applications, one standard plug instead of a custom cable for every device ^[2].

A tool, in MCP terms, is simply a function the model is allowed to call, with a name, a description and typed arguments ^[3]. So an MCP server for a CRM is basically a list of CRM functions, like find an account or move a deal, described in a way a model can read and use.

How does an MCP server for a CRM work?

1. The client asks for the tool list. Claude connects to the server and reads which tools exist and what arguments they take.
2. The model picks a tool. From your prompt, Claude decides which tool to call, for example a search for an account by its domain.
3. The server checks access. The server checks the key or the connection, applies its scopes and records the call.
4. The CRM does the work. The CRM runs the function exactly like a click in the interface would.
5. The result goes back. Claude gets the result and either answers you or calls the next tool.

For a remote server the transport is usually Streamable HTTP, which means the CRM just needs one https endpoint the client can reach ^[4]. In my experience the transport is the easy part, and the real work is deciding which functions you expose and with which rights.

MCP server vs. REST API vs. CRM plugin: what is the difference?

None of these replaces the others. A REST API is still the right thing for a nightly sync with your ERP. The MCP server is what lets a person or an agent work with the CRM in plain language, and that is a different job.

Which CRM jobs make sense for Claude over an MCP server?

The good first jobs are the ones your team does every week and kind of hates: researching an account before a call, the Monday pipeline review, cleaning up an imported lead list, writing the weekly summary. They read a lot of records and write very little, so they're low risk and you see the value in the first week.

• Account research with the signals logged on the record
• A daily pipeline review that lists deals without a next step
• Import, dedupe and enrichment of a lead list with a dry run first
• A weekly summary saved as a note the team can comment on

We describe twelve of these with the real tool names on the Sigma CRM MCP server page.

What should a CRM MCP server never allow?

OWASP lists excessive agency as one of the top risks for LLM applications: damaging actions that happen because a model had too much functionality, too many permissions or too much autonomy ^[5]. A CRM full of customer data is exactly where that hurts.

The MCP spec itself says there should always be a human in the loop with the ability to deny tool invocations ^[3]. For a CRM I read that as: keys with clear scopes, confirmation before bulk changes, merges, imports and enrollments, and a history that shows which change came from an agent.

How do you decide which CRM functions an AI may call?

You decide it once, in one place, and not per integration. At JadenX we built Sigma CRM around one tool registry with more than 130 tools that backs the interface, the REST API, the MCP server and our built-in agent Sammy, so there is no second, reduced AI API that falls behind. An API key belongs to one workspace and reaches shared lists and segments only, and the workspace configuration tools are refused for API keys altogether. Every write is tagged as UI, MCP, agent or observer, so you can always see who changed what.

Frequently asked questions