Launch special: 50% off paid Self-Serve plans, stacking with 20% off annual billing.
All articles
Product·4 September 2026·Updated 25 September 2026·4 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 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: find new people who match your target profile and pull them 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 change attributable?Each change is logged against the key that made it, so an audit later can tell a person from an assistant.
Can you revoke it in one click?Keys are listed in settings, 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; in HuntSales a key can use only the MCP tools its creator's role permits, so the safest keys belong to a role that holds only what the assistant needs. 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 with reading. Ask about contacts and pipeline 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. Move on to write actions 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 the permissions behind the key matter 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 Claude Code and other MCP clients that send an API key connect with no local install; Claude Desktop on Mac uses a small bridge. The key inherits its owner's role, which means a member without campaign permissions cannot acquire them by asking an assistant nicely. Claiming prospects from the database, building a list from a filter and launching a campaign 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, live B2B People Search, and an AI copilot. Free forever for registered businesses.

Start free

Keep reading