All articles
Product·4 September 2026·8 min read

How to connect your CRM to Claude with MCP

MCP lets an AI assistant read and act on your CRM directly. What the protocol does, what a sales MCP server should expose, and how to connect one safely.

Sales teams increasingly start the day in an AI chat window rather than a CRM tab. That works right up to the moment the assistant needs real data. Ask it who to call today and, with no access to your pipeline, it can only guess. The Model Context Protocol closes that gap. It is the standard that lets an assistant such as Claude read your CRM and act inside it, with your permission and inside your existing role limits.

What MCP actually is

MCP is an open protocol for connecting an AI client to a data source or a tool. The client is the assistant you talk to. The server is a small service that sits in front of a system and publishes the tools it is willing to run, each with a name, a description and a typed set of arguments. When you ask a question, the assistant picks a tool, calls it, and reasons over what comes back. Nothing is scraped and nothing is pasted. The assistant is making ordinary, audited API calls on your behalf.

The practical consequence is that you stop moving data by hand. No CSV export, no copying a list of contacts into a prompt, no stale spreadsheet pasted into a chat thread. The assistant reads the live record at the moment you ask.

Read access is the easy half

Most CRM integrations stop at reading, and that is a sensible place to start. But the work a rep actually wants taken off their plate is the writing: logging the call, moving the stage, adding the follow-up, enrolling new contacts in the right sequence. A CRM MCP server earns its keep when it can do those things and still refuses to do anything the person holding the key could not do in the interface.

What a sales MCP server should expose

  • Contacts and companies: search, filter and read the full record, not just a name and an email address.
  • Pipeline: stages, values and movement between them, so the assistant can summarise a week without anyone building a report.
  • Prospecting: search the contact pool and pull new people into your workspace, with the credit cost stated before anything is spent.
  • Campaigns and sequences: create a draft, set the steps, enrol a list. Sending should always need a separate, deliberate confirmation.
  • Engagement: opens, replies and call outcomes, so the question of who is worth chasing gets a real answer.

Four questions to ask before you connect anything

QuestionWhat a good answer looks like
Whose permissions does the key carry?Exactly what its owner can do in the app, never more. Role limits are enforced on the server, not in the prompt.
Are destructive actions gated?Anything that sends email, spends credits or changes a live campaign runs as a dry run first and needs an explicit confirmation.
Is every call attributable?Each tool call is logged against the key and its owner, so an audit later can tell a person from an assistant.
Can you revoke it in one click?Keys are listed in settings, individually scoped, and deleting one does not disturb anyone else's access.

Connecting a server, in practice

The mechanics are much the same across assistants. You create an API key in the CRM, scoped to the permissions you actually need. You add the server to your AI client by URL and paste the key as the credential. The client fetches the tool list on connect, and from then on those tools sit alongside everything else the assistant can do. Where the CRM offers a remote server over HTTP there is nothing to install locally, which matters when you want a whole team on it rather than one engineer.

Start read only. Give the key contact and pipeline read for a week and watch which questions you genuinely ask. Most teams find the useful set is smaller and more mundane than the demo suggested: what changed since Friday, who has not replied, which campaign is underperforming. Add write scopes once you know which ones you would really use.

Where this still falls short

Be honest about the limits. An assistant with CRM access is still working from whatever is in the CRM, so a pipeline nobody updates will produce confident nonsense. Tool descriptions are written by whoever built the server, and a vague description sends the model to the wrong tool. Long multi-step requests drift, so asking it to clean up the pipeline is a far worse instruction than three specific ones. And an assistant will occasionally reach for a tool you did not intend it to touch, which is why scoping the key narrowly matters more than it sounds.

The test of a CRM integration is not what the assistant can read. It is whether you would be comfortable letting it write.

How HuntSales does it

HuntSales ships a remote MCP server, so any MCP client can connect with an API key and no local install. The key inherits its owner's role, which means a member without campaign permissions cannot acquire them by asking an assistant nicely. Actions that send email, claim prospects or spend credits are dry runs by default and need a second, explicit confirmation. Setup, the full tool list and the role each tool requires are in the MCP documentation, and there is an n8n integration if you want the same access from an automation rather than a chat window.

Where to go next

Outreach built for how Asia sells

Sequenced sends from your own mailbox, a deep regional contact pool, and an AI copilot. Free forever for solo founders.

Start free

Keep reading