Most CRM vendors now say they have an MCP. The claim is close to meaningless on its own, because whether it writes is the entire difference between an assistant and an expensive search box.
One question sorts the field, and it is not the one the comparison articles ask.
The question
Which actions does the server publish, and do any of them change data.
Everything else is detail. A vendor who can hand you the action list in thirty seconds has built something real. A vendor who answers "we support MCP" and moves on has built a feature bullet for a pricing page.
Why read-only is a smaller product than it sounds
A read-only CRM connection answers questions. Which deals went quiet after the proposal. Which accounts have not been touched in six weeks. Who has three open opportunities and no meeting booked. That is useful, and nobody built a report for any of it.
Then it stops. Every conclusion ends with a person opening the CRM and typing in what the assistant just worked out. The thinking was free and the admin was not, and the admin was always the slow part.
That is the gap between the demo and the Tuesday.
What to compare
| What to check | Why it decides things |
|---|---|
| Can you see the action list | If not, nothing else can be evaluated |
| Reads, writes, or both | The difference between knowing and doing |
| Whose permissions it uses | Should be the connecting person, never an admin |
| Are writes attributable | You need to know who changed what, later |
| Can access be withdrawn centrally | Staff leave. Connections should not outlive them |
| Which objects are covered | Deals and contacts are common. Activities and notes often are not |
That last row catches people. A server that reaches deals and contacts but not activity history can tell you the state of a deal and nothing about what happened in it, which rules out most of the questions worth asking.
The querying limits nobody mentions
Even where a server reads broadly, the way it reads is usually narrower than the product's own reporting. Joining across objects, following associations between records, and searching by meaning rather than by field are the three that tend to be missing.
In practice that means a question like "which accounts went quiet after someone changed role" often cannot be answered in one step, because it needs two objects joined. The assistant will usually try, take several passes, and give you something partial. Knowing the limit in advance saves the frustration of discovering it mid-question.
Where this leaves a growing team
Most of the value of connecting an assistant to a CRM assumes the CRM holds the whole picture. Where a team runs a CRM for records, a separate tool for prospect data, another for sequences, a booking link and a proposal tool, the assistant can only see into whichever ones publish a server, and the answer to any real question is split across the rest.
So the connection is worth less in a fragmented stack, which is the opposite of what you would expect, and it is worth checking before the problem is blamed on the assistant.
Empiraa Signal is a CRM and more. It is also the B2B prospect database, the enrichment, the email sequences, the booking link and the proposal tool, in one system with unlimited users on every plan, so the record of what happened is not spread across five subscriptions. Signal's own MCP is in build and not shipped at the time of writing, which is the honest answer and the one this post is asking you to demand of every vendor. Empiraa GPS shipped one in version 1.22, so the access model is published and running.
Related reading: does HubSpot have an MCP, and what can it do, and what an MCP server is, and what it is not.
See also a CRM migration checklist if consolidating is the actual answer.
