Running your CRM from Claude or ChatGPT: what MCP breaks

An agent connected over MCP can search your CRM, write to it, and fire off a message. The protocol does not rank those three moves: it publishes tools, the schemas for their arguments, and a handful of behavioral hints, then leaves the client to decide. CRMArena-Pro, the benchmark released by Salesforce AI Research on May 24, 2025, measures roughly 58% single-turn success on CRM tasks, and 35% over several turns.

The working rule fits in two lines. An agent handles on its own whatever is reversible and unambiguously targeted: search, read a history, add a note, advance a deal one stage. Whatever is irreversible or bulk gets confirmed, and the server has to demand that confirmation: sending, an import, a duplicate merge, a deletion, a change to the data model.

The protocol does not draw that line. The NSA writes in its May 2026 sheet on the Model Context Protocol that binding a session to an identity is not defined by the protocol, that components can be configured with no access control, and that many implementations omit authentication.

What an agent actually gets right in a CRM, and where it falls apart

The detail inside CRMArena-Pro moves the problem. On workflow execution, where the target is named and the procedure known, top agents clear 83% single-turn. The overall figure drops to 35% precisely when the agent has to ask a question to fill a gap. The agent is not failing to write. It is failing to know what to write on.

The same paper carries a less quoted finding: the agents tested show near-zero inherent awareness of confidentiality rules, and prompting them into that awareness costs them task performance. An agent with write access to a CRM does not hold itself back, and teaching it to hold back makes it less accurate.

Three journeys describe the real usage. Find: the agent reads and cross-references, and that is where it pays off. Write: it creates and updates, as long as the record is named without ambiguity. Send: the effect leaves the CRM, and the mistake is no longer recoverable. Three journeys, three levels of authorization, which the CRM has to encode somewhere.

Why having an API is not the same as being drivable by an agent

A REST API assumes a developer read the documentation, picked the endpoints, and wrote the mapping. MCP moves that documentation into the session: the server returns its tools, the JSON schema for their arguments, and a natural language description. The map of your CRM becomes a document rather than code somebody wrote.

The July 28, 2026 revision of the specification made the protocol stateless. It drops the initialization handshake and the session identifier, moves routing into the Mcp-Method and Mcp-Name headers, and makes tool lists cacheable through ttlMs and cacheScope. The map can be memorized and reused across turns.

In a CRM where objects and fields are configured per org, the description has to be generated per workspace, or the agent reasons about a schema that is not yours. The November 25, 2025 revision had already added guidance on tool naming, which suggests the confusion came from practice rather than theory.

The four things MCP breaks

Once the map is read, four failures show up, none of them an implementation bug. They are four responsibilities the specification hands to the server: name things unambiguously, cap the blast radius of a call, reapply the signed-in user's permissions, bind the session to an identity.

Schema ambiguity

Two fields called status, one on the contact and one on the deal, are enough. The model picks on the strength of a label, and a wrong pick writes a plausible value in the wrong place. The CRM sees no error, because the value is the right type. The remedy: names that carry their subject, and a schema introspection the agent can call first.

Bulk writes

The protocol does not distinguish a call that touches one record from a call that touches two hundred. Only an annotation distinguishes them, destructiveHint. The official Model Context Protocol blog restated on March 16, 2026 that annotations are not guaranteed to faithfully describe tool behavior, and that clients must treat them as untrusted unless they come from a trusted server.

Permission scope

An MCP token has no particular reason to carry the exact scope of the person signed in. Asana launched its MCP server on May 1, 2025 and found a cross-organization isolation flaw on June 4. Roughly 1,000 customers were potentially exposed per the vendor notices reported by BleepingComputer: tasks, comments and files readable from one tenant to another.

The Supabase case documented by Simon Willison on July 6, 2025 shows how that failure turns fatal. A support ticket carried hidden instructions, which the agent executed while reading the queue. The injection was the vector; what made it exploitable was the role in use, a service key to which row level security did not apply.

The identity the protocol does not define

That leaves the point the NSA raises. Censys counted 12,520 internet reachable MCP services as of April 28, 2026, across 8,758 IP addresses, and notes that the ones it describes had no authentication. Wiz published on July 28, 2026 that around 70% of exposed servers hand their tool catalogue to an anonymous caller, and 42% return real data.

Recent revisions close part of the gap. Since June 18, 2025 the specification classifies MCP servers as OAuth 2.0 resource servers and gives them protected resource metadata. The November 25, 2025 revision aligns that discovery with RFC 9728 and adds incremental scope consent through the WWW-Authenticate header. Both describe how to authenticate, not how to force a server already deployed without it.

The guardrail the protocol leaves to the server

Those four failures converge on one missing operation: making an irreversible action impossible without explicit agreement, and that agreement verifiable somewhere other than inside the client. Plenty of clients pop a dialog when destructiveHint is true. Good instinct, poor guarantee: the decision to show it belongs to the client.

The shape that holds is a preview that binds. The first call executes nothing: it returns what is about to happen plus a token tied to the exact fingerprint of the operation. The second echoes that token, single use and short lived, and the server refuses it otherwise. Approval given for one email cannot be spent on a different one.

The protocol is moving that way. Elicitation, introduced on June 18, 2025, lets a server pause execution to ask for information through a JSON schema. The July 28, 2026 revision replaces it with multi round-trip requests: the server answers with resultType input_required, and the client retries the call. Nothing obliges a vendor to use either one for irreversible writes.

None of this belongs to any one vendor. A fingerprint-bound token is a few dozen lines of code; its real difficulty is deciding what it does when the store holding it goes down. A guardrail that lets calls through during an outage is a setting, not a rule.

Which CRMs ship an MCP server, as of September 6, 2026

This table moves fast, and a claim about a competitor is worth nothing undated. Here is what each vendor's public documentation states as of September 6, 2026, with the address of the page that states it. The dates are general availability announcements, not betas.

• Salesforce: hosted MCP servers generally available on April 29, 2026 per the developer blog, for every Enterprise Edition org and above, with standard servers for Agentforce 360, Tableau Next and Data 360 SQL. The dedicated Data 360 MCP server is only a developer preview, announced in May 2026.
• HubSpot: remote MCP server generally available on April 13, 2026 per the developer changelog, read and write on CRM objects and engagements, read only on marketing content, no access to sensitive properties. At developers.hubspot.com/ai-tools/mcp.
• Pipedrive: native MCP server announced on June 30, 2026 in the company newsroom, on every plan with token quotas, OAuth connection, scope bounded by the user's own permissions, change log. At pipedrive.com/en/features/mcp-server.
• Attio: hosted MCP server announced in the vendor changelog on February 19, 2026, authenticating as your own user over OAuth. At docs.attio.com/mcp/overview.
• Kasar: MCP server exposed for reading and writing.

What the table does not say is more instructive. Attio is the only one to write that its reads are auto-approved and its writes request confirmation. No page says which writes, nor whether the refusal comes from the server or the client. Pipedrive documents user permissions and a log, never a stop before execution.

What actually happens when you paste a URL into Claude or ChatGPT

Wiring a CRM to an assistant takes three moves: paste the server address, clear an OAuth consent, pick the workspace. The client then queries the tool list and keeps it available. Since the November 25, 2025 revision that consent can be incremental: the server asks for an additional scope when it becomes necessary, through the WWW-Authenticate header.

That detail changes the buying experience. A server that asks for full access up front gets an authorization signed that nobody will reread. A server that asks at the point of use makes every widening visible. It is the last moment the buyer sees anything. After that, it all happens between the model and the server.

Six questions to ask before you wire an agent to your CRM

Each section above produces one question, and each answer should sit in a document rather than in a sales promise. They are about the server, not the processing chain behind it: that second grid is the subject of another article on this blog, Where is my data: six answers, and only one is about a country. Both go to the same vendor.

• The schema: does the server describe your real objects and fields, and can the agent introspect it before writing?
• The irreversible: which operations require a server side confirmation, and is that list written down anywhere?
• The scale: how many records can a single call modify, and is that ceiling documented?
• The rights: is the agent's scope the scope of the person signed in, or an application token?
• The consent: is authorization requested in one block, or widened at use?
• The trace: is there a tool call log, tied to an identity and exportable?

Three of those six questions did not exist before agents started writing. A vendor who answers all six with a dated document has done the work. One who answers that its MCP server is secure has described an intention. The first outage will show which of the six it had handled.

Kasar is an AI-native CRM whose agent is called Leo. It captures interactions across email, LinkedIn, WhatsApp, calendar and calls, and it exposes an MCP server: the six questions apply to us the way they apply to any other vendor, and nothing obliges you to believe us before asking for that log. The trial runs 14 days.