CRM with an MCP server: what Claude and ChatGPT can do in five CRMs

What an MCP server adds to a CRM

MCP, the Model Context Protocol, is a standard way for an AI assistant to call tools exposed by another system. A CRM with an MCP server lets Claude or ChatGPT run a search, read a record or, if you allow it, change one, without a developer wiring up the API for you.

The protocol itself says tools are model-controlled, meaning the model can discover and call them on its own, and that there should always be a human in the loop with the ability to deny invocations. What that human sees, and how much the server lets the model do, is up to each vendor. That is what this guide compares.

We make Lead Friendly, which has its own MCP server, so we read our own documentation from the files in our repository and read every other vendor from the pages linked in the sources. Where a page does not say something, the table says "not stated" and we have not filled the gap from memory.

Side by side: hosting, sign-in, reads and writes

Each row comes from the vendor's own documentation, opened on the date in the sources. Documentation changes often, so verify on the vendor's site before you decide.

Salesforce's developer pages returned an access error to our fetch tool, so that row rests on the public README alone. Check Salesforce's own guide for authentication and tool lists.

HubSpot: the most detailed public tool list

As of October 2026, HubSpot's remote server documentation lists its tools by name. The read set includes search_crm_objects, get_crm_objects, query_crm_data and search_conversations. The read-and-write set is led by manage_crm_objects, which shows a change summary before it writes, with other manage_ tools for segments, custom properties, pipelines, marketing email and landing pages.

Permissions follow the signed-in user, and HubSpot lists per-request limits (for example 200 results per page on search and 100 IDs per get). The page we read does not mention a rate limit. Activity and conversation data are blocked when the account has Sensitive Data turned on.

HubSpot's separate developer server is a local tool for building apps and is not the CRM connector. If you only want Claude to read deals, you want the remote one.

GoHighLevel: one connector, a large operation catalog

GoHighLevel's marketplace documentation describes a remote server that exposes four unified tools: list_locations, search_operations, describe_operation and execute_operation. The assistant finds an operation by intent, reads its required scopes and safety information, then executes it. The page cites more than 550 operations across 38 domains.

The documented sign-in is OAuth, with no manual token to rotate, and you can review or revoke access from your account. Each request targets one sub-account; agency-wide connections are described as rolling out. The page says sensitive and irreversible operations need extra confirmation, but it does not list scope names, and it points to a separate page for rate limits that we did not read, so we mark them not stated.

Where GoHighLevel is the better fit: if you already run your business on it, the breadth of that catalog is hard to match, and an agency can see its sub-accounts through one install once that rollout is complete. Third-party GoHighLevel MCP servers on GitHub also exist; those are community projects, not the vendor's, and are outside this comparison.

Salesforce and Zoho

Salesforce's public README for its hosted MCP servers says they are generally available and that admins can enable and disable servers, create custom servers, attach APIs and Flows, and manage External Client Apps. It does not list tools or say whether any are read-only. For an enterprise that already runs Salesforce, the admin-governed, custom-server model is a real strength, and it is also why the details live behind your admin and Salesforce's developer guide.

Zoho CRM documents four pre-built servers and is the clearest of the five about separating reading from changing: Data Insights is read-only, and the other three can modify records or configuration. Zoho's page says actions are limited to the signed-in user's CRM role and that MCP calls consume API credits like standard API calls. It does not state whether the servers run remotely or locally.

Lead Friendly: an API key, three key types, a gated write path

Our account server has 38 tools: 19 that only read, 8 that write, and 11 setup tools that build things switched off. Some of the tools (deals, F&I products, desk defaults) apply only to car dealerships. A key is created by an owner or admin under Settings, API keys, and it is one of three types: read only, read plus setup, or read plus write.

A read-only key is shown the 19 read tools and nothing else. A read-plus-setup key adds the setup tools but never the ones that text, call or book. Texts and AI calls run the account's compliance checks, and a marketing message from an assistant needs a consent record on the contact. What an assistant builds starts off: agents land in review, campaigns as drafts, workflows paused. Buying a number, and editing a live agent's script, each need a second confirmed call.

The honest trade-offs: we use an API key, not OAuth, so the key identifies the account rather than a named user, and one key sees exactly one account. Our tool set is narrower than HubSpot's or GoHighLevel's because we are a smaller product. In exchange, every call, including refusals, is logged under Settings, AI agents, with arguments stored only as a hash. The full tool list and limits are on the MCP page.

Safety: treat CRM text as untrusted input

A CRM is full of text written by strangers: form fills, inbound emails, call transcripts, notes. When an assistant reads that text, an instruction hidden in it can be treated as a command. This is prompt injection. The MCP specification does not claim to prevent it; what it says is that servers must validate inputs, apply access controls, rate limit and sanitize outputs, and that clients should prompt for confirmation on sensitive operations, show tool inputs before calling the server, and log tool usage.

The specification's security guidance on scope minimization points the same way: start with a minimal set of low-risk read operations and escalate only when a privileged operation is needed. In a CRM that means a read-only connection first, one key or connector per assistant, and write approvals left on.

• Read-only first: you can ask what is unsigned, who is overdue or which leads went quiet without any ability to change a record
• Least privilege: pick the narrowest key type or OAuth scope; revoke by connector, not by sharing one login
• Approvals on for every write, and look at the inputs before you approve a text, call or bulk update
• Do not let a record's contents decide what the assistant does next; if a note says to email a list, that is data, not your instruction
• Check the audit trail weekly; know where each vendor logs MCP activity before you rely on it

How to connect Claude to a CRM safely

1. 1

   Pick the narrowest access

   Choose a read-only key, a read-only server such as Zoho Data Insights, or OAuth scopes limited to reading the objects you need.

2. 2

   Use a test or low-risk account first

   Connect to a sandbox or a small account so a mistake does not reach real customers.

3. 3

   Add the connector in Claude or ChatGPT

   In Claude, Customize then Connectors then Add, with the server URL from the vendor's docs. ChatGPT needs a paid plan with Developer Mode for custom connectors, per our own connection guide.

4. 4

   Leave write tools on needs-approval

   Set read tools to always allow if you like, and keep anything that texts, calls, books or deletes on approval.

5. 5

   Ask a read-only question

   Start with something that proves the connection and changes nothing, such as which open deals are missing a signature.

6. 6

   Review the log, then widen access

   After a few days, check what the assistant did and was refused. Only then create a write key or add scopes, and revoke the old key.