For months I had Claude Code doing beautiful work on files and completely blind to the CRM. So I became the courier. Export the accounts to a CSV, drag it into the folder, let Claude work, then copy the results back into HubSpot by hand. I had built an agent and then spent my afternoons being its intern, walking data back and forth between tools that could not talk to each other.
MCP is what ended the courier job. It is the standard that lets Claude Code reach into your CRM, your warehouse, your enrichment tools, and read and act there directly. This is the piece that turns Claude Code from something that works on files you feed it into something that works in your stack.
MCP is how Claude Code reaches your stack
Out of the box, Claude Code works on the files in your folder. That is powerful, but your GTM life is not in files, it is in HubSpot, in Salesforce, in a warehouse, in an enrichment service. MCP, the Model Context Protocol, is the standard connector that lets Claude Code talk to those systems through one consistent interface instead of a bespoke integration per tool.
The practical upshot: once a server is connected, asking Claude Code about your pipeline is the same motion as asking it about a file. It reads the real data, works with it, and can write back, all inside one run. You stop being the bridge between your agent and your tools, because the bridge is now the protocol.
How a server connects
An MCP server is a small program that sits in front of a tool and speaks the protocol. When you add one to Claude Code, they do a short handshake: the server tells Claude Code what it can do, and from then on Claude Code can call those capabilities as needed. You do this once per tool; after that it is just there.
You do not write the server for the big tools. Vendors ship them, HubSpot, your warehouse, enrichment services, and increasingly GTM platforms build their own. Your job is to connect the ones you use and authorize them with your account, which is a minute of work, not an integration project.
Adding a server
Connecting a server is one command in Claude Code, followed by authorizing it in your browser with your own login. Because it uses your account, it inherits your permissions: a connected CRM server can see exactly what you can see in the CRM, no more. That property is worth holding onto, it means connecting a tool does not widen access, it just lets Claude reach the access you already have.
Servers can be scoped to a project or to you personally. Scope a shared GTM workspace's servers to the project so the team gets the same connections; keep experimental or personal ones to yourself. The how-to below walks the exact commands.
One practical note: servers can run locally or be hosted remotely, and the difference is mostly about where the connection lives and who maintains it. For the big GTM tools you will usually connect a hosted server the vendor runs; for something bespoke you might run one locally. Either way the motion in Claude Code is the same add-and-authorize, and the same read-first discipline applies.
TipConnect servers with your own account and normal permissions. An MCP server never grants Claude access you do not already have yourself.
What a server gives Claude
A server exposes two kinds of things: tools and resources. Tools are actions, search contacts, create a task, update a deal. Resources are data Claude can read, a record, a report, a document. When you connect HubSpot, you are handing Claude Code a set of both, and it picks the right one for the job the way it picks any tool.
This is why the read-versus-write distinction matters so much here, which is the next section. A server does not just let Claude look at your CRM; it can let Claude change it. The power and the risk arrive in the same connection.
Read first, write on purpose
The rule that keeps this safe is simple: start with reads, prove them, then allow writes deliberately. Let the first thing Claude Code does with your CRM be answer a question only your real data could answer. When you trust that it reads correctly, allow specific write actions, and keep them behind your approval until the pattern is boring.
The failure mode is granting broad write access to a system of record on the first day, then discovering the agent logged forty notes you did not want or advanced deals it should not have. Reads cannot hurt you; writes touch your pipeline and your prospects. Treat the two completely differently.
TipYour first CRM prompt should be a read that only real data can answer. If that comes back right, you have earned the confidence to allow a write.
The GTM servers worth connecting
Not every server earns a slot. The ones that consistently pay off for GTM are the systems where your work actually happens and the tools that enrich it. Connect the CRM, because that is the system of record. Connect an enrichment service, because that is what turns a thin lead into a workable one. Connect the warehouse if your real numbers live there.
The test for whether a server belongs is boring on purpose: would you use it in this task at least weekly? A connection you reach for constantly earns its place because it removes a courier trip every time. A connection you added out of curiosity just sits there as access you now have to account for. Wire the daily drivers, skip the maybe-somedays, and your setup stays something you can actually reason about.
- Your CRM (HubSpot, Salesforce): the system of record Claude should read from and, carefully, write to.
- Docket: its GTM MCP server, so Claude Code can work with inbound demand and account context in your stack.
- FullEnrich: enrichment on tap, so a thin lead becomes a workable one without leaving the run.
- Your data warehouse: when the numbers that matter live there, not in a dashboard.
TipConnect the two or three tools your day actually runs on, not everything with a server. Each unused connection is surface area you have to reason about.
Keep the credentials safe
Connecting your stack means handing tokens around, so it is worth a word on doing it safely. Because a server authorizes with your own account, you are not creating new access, but you are creating a new path to it, and that path deserves the same care as any other. Authorize through the official flow, keep tokens out of any file that gets committed, and treat a connected CRM the way you treat your own logged-in session, because that is effectively what it is.
The good news is that the read-first habit doubles as a safety habit. A server you have only granted read access cannot damage anything even if something goes wrong, so the blast radius stays small while you build trust. Widen to writes only for the specific actions you have watched behave, and you keep the powerful connection from ever being a careless one.
Where it goes wrong
The first mistake is connection sprawl: wiring up a dozen servers because you can, then losing track of what has access to what. Every connected server is something to keep in your head when you reason about safety. Connect what you use; disconnect what you stopped using.
The second is the blind write, covered above but worth repeating because it is the expensive one. The third is subtler: assuming a connected server means Claude has perfect knowledge of that tool. It has the access you gave it and the tools the server exposes, no more. If a report lives behind a permission you lack, Claude cannot see it either.
- Connection sprawl: a dozen servers connected, two actually used.
- Blanket write access to a system of record before you have watched it read.
- Assuming a connection means omniscience; it only grants your access, through the exposed tools.
- Forgetting a server is connected, so you reason about safety with a stale mental map.
The GTM version
Here is the shift once MCP is wired. Instead of exporting a CSV, I ask Claude Code directly: pull my open opportunities with no activity in two weeks, enrich the contacts that are missing a title, and draft a re-engagement note for each, then show me before you log anything. It reads from the CRM, enriches through the enrichment server, drafts, and waits for my yes before it writes.
The courier job is gone. The data does not leave its home, the work happens where the data is, and I approve the writes instead of performing them. What is the tool you keep exporting from by hand? That is the first server to connect.
How to set it up
Add the server
Connect the tool with one command and authorize it in the browser with your own account. This is the same motion whether it is your CRM, your warehouse, or an enrichment service.
Prove it with a read
Before you trust it to change anything, ask a question only your real data can answer:
"From HubSpot, list my 10 oldest open opportunities with no activity in the last 14 days, with owner and last-touch date."
TipIf the read comes back matching what you see in the CRM, the connection is sound. If it is off, fix that before you allow any writes.
Allow a write, one action at a time
Once reads are solid, let it act, but deliberately and with approval, not as blanket permission:
"Enrich the contacts on those three that are missing a title, then draft a re-engagement note for each. Show me before you log anything."
Keep the connection list tight
Review your connected servers now and then and remove the ones you stopped using. Every live connection is access you are responsible for reasoning about, so a short, current list is a feature, not a limitation.
Frequently asked questions
What does MCP do in Claude Code specifically?
It connects Claude Code to external systems like your CRM, warehouse, or enrichment tools, so it can read and act in them from inside a run, instead of only working on the files in your folder.
How do I add an MCP server?
Run claude mcp add followed by the server name, then authorize it in your browser with your own account. Use claude mcp list to see what is connected.
Does connecting a server give Claude more access than I have?
No. A server uses your account and inherits your permissions, so Claude can see and do exactly what you could in that tool, no more.
What is the difference between tools and resources?
Tools are actions a server exposes, like create a task or update a deal. Resources are data Claude can read, like a record or a report. A connected server typically offers both.
Should I let Claude write to my CRM?
Eventually, but deliberately. Start with reads, confirm they are correct, then allow specific write actions behind your approval. Never grant blanket write access to a system of record on day one.
Which servers should a GTM team connect first?
The CRM, an enrichment service like FullEnrich, and your warehouse if your real numbers live there. Docket also ships a GTM MCP server. Connect what you use daily, not everything available.
Can I scope a server to just one project?
Yes. Servers can be scoped to a project so the whole team shares the connection, or kept personal to you. Scope shared workspaces to the project and keep experiments to yourself.
How is this different from connectors in the Claude apps?
Same protocol, different surface. Connectors are how you turn on MCP in the Claude apps; claude mcp add is how you do it in Claude Code. The underlying standard is identical.
Sources & further reading
Claude ships fast. This page was last reviewed Aug 22, 2026; verify time-sensitive details against the official docs above before relying on them.