MCP is an open standard that lets an AI assistant call external systems directly, and for GTM teams it removes the export step. Instead of pulling a list out of a database and pasting it into a chat, your agent queries companies, buying signals and verified contacts mid-conversation and acts on what comes back.
Key facts
- MCP stands for Model Context Protocol. It is an open standard for connecting AI applications to external systems, introduced by Anthropic and now supported across Claude, ChatGPT, VS Code, Cursor and others.
- The current protocol revision is
2026-07-28. Revisions are dated strings marking the last backwards-incompatible change. - Clients set the practical limits, not servers. Claude caps a tool result at roughly 150,000 characters on its hosted surfaces and 25,000 tokens in Claude Code, with a 300-second timeout.
- Setup is not an engineering task for a hosted server. It is a connector setting plus an OAuth approval.
- The failure modes are specific: truncated results, tool confusion between overlapping servers, and auth that works in one client and not another.
What MCP actually is
Strip away the analogies and MCP is a specification for how an AI application talks to an external system. A server exposes a set of tools. Each tool has a name, a description, and a schema describing its parameters. The client fetches that list, hands it to the model, and the model decides which tool to call and with what arguments.
That is the whole idea, and the reason it matters is that the description is machine-readable. Nobody has to write integration code that says "when the user asks about companies, call this endpoint with these parameters". The model reads the schema and works it out, because reading a specification and mapping a sentence onto it is a thing language models are unusually good at.
The 2026-07-28 revision changed how versions get negotiated. Rather than a handshake at the start of a session, every request declares the protocol version it is using, and the server accepts or rejects each one independently. There is also a mandatory server/discover call a client can use to ask what versions and capabilities a server supports before committing to one. Clients and servers may both support several versions at once.
That is more engineering detail than a GTM buyer needs, with one exception, which is covered under "authorization is where things break" below.
Why this matters more for GTM than for most functions
Sales data has a structural problem that MCP happens to be shaped to fix.
The problem is that B2B data is stale the moment it stops moving. A contact record decays as people change jobs. A technographic record decays as stacks change. A funding record is accurate forever and useful for about eight weeks. Every part of a prospecting dataset has a half-life, and the traditional workflow, which is export a list and work it over the following weeks, is a machine for guaranteeing you work the list at its least accurate.
The export step exists for a technical reason rather than a good one. Data lived in a database, the database had a UI, the UI had a download button, and everything downstream was built on the assumption that a list is a file.
An agent does not need the file. It needs the answer to one question, at the moment it is asking. "Which companies in my ICP raised in the last two months and are hiring salespeople" is a query, and a query returns something current by construction. The list-shaped workflow was an artefact of the tools, and it is the artefact MCP removes.
The second reason is more mundane and possibly more important: the research work sits in the same window as the writing work. A rep researching an account in a data tool and writing the email in another tool is doing two context switches per account, and at forty accounts a day that is most of the friction in the job.
What a request actually looks like
Concretely, here is the shape of one exchange.
You type a sentence into Claude:
Find UK fintechs that raised a Series A in the last 60 days,
under 200 employees, and tell me which ones are hiring salespeople.The model has the tool list already. It picks search_signals and fills in the schema:
search_signals({
industry: "fintech",
country: "GB",
fundingStage: "series_a",
fundedWithinDays: 60,
employeeCountMax: 200,
hasOpenRole: true,
openRoleTitleContains: "sales"
})Nobody wrote that mapping. The model read the parameter descriptions, matched your sentence to them, and made the call. The server runs the query and returns structured rows: company, domain, signal type, an ICP score, when the event happened, when it was detected.
The model then reads those rows in the same conversation and you carry on. "Rank those by fit against my ICP." "Which one had the most senior sales hire open?" "Draft a first line for the top three based on what they raised for." Each of those is either a follow-up question about data already in context, or another tool call.
The thing that has changed is not any individual step. It is that the loop closed.
What you can and cannot do today
Honest state of play, verified 25 August 2026.
| Capability | Status |
|---|---|
| Query live company and signal data from a chat | Works well |
| Pull verified contacts on demand | Works well |
| Chain research into drafting in one conversation | Works well |
| Run a standing query on a schedule | Depends on the server, not the protocol |
| Write back to your CRM | Possible, and see the caution below |
| Agent-initiated actions with no human in the loop | Technically possible, rarely wise |
The gap between "technically possible" and "wise" is where most disappointment lives. An agent with write access to a CRM will, at some point, confidently update the wrong record, and the cost of that lands on a human who did not see it happen. Read access is where the return is, and the asymmetry is stark: a bad read wastes a minute, a bad write corrupts a system of record that other people depend on.
Authorization is where things break
This is the part worth reading twice, because it is the single most common reason a connector that works for one person fails for another.
Auth in MCP has its own specification, and clients support specific versions of it. As of 25 August 2026, Anthropic documents Claude as supporting the 2025-03-26, 2025-06-18 and 2025-11-25 authorization specifications, and as having Dynamic Client Registration enabled. Note that the current protocol revision is 2026-07-28, which is ahead of the newest auth spec on that list. A server built strictly against the newest specification is not guaranteed to authenticate against a client that has not implemented it yet.
For a buyer, that translates into three practical questions:
- Does the server offer OAuth, or only a pasted API key? OAuth means you never handle a secret and you can revoke one client without rotating a credential every other client uses. A key-only server is workable but the blast radius of a leak is larger.
- Does it support Dynamic Client Registration? Without it, a client that cannot pre-register has to be handled manually, which usually shows up as a support ticket rather than an error message.
- What happens on a 401? A well-behaved server returns a
WWW-Authenticateheader pointing at where to discover the authorization server. Without it, a client's connector UI has nothing to work with and the user sees a generic failure.
Signl runs its own OAuth server for exactly the first point, and accepts an sk_signl_ API key for clients with no OAuth flow. Keys are shown once and stored as a SHA-256 hash, so a lost key is replaced rather than recovered.
Tool confusion, and why fewer servers is usually better
Every connected server adds its tools to one list the model chooses from. That list is a prompt, and like any prompt it degrades as it gets longer and more repetitive.
When two servers both expose something called roughly "search companies", the model picks between them on description text alone. It will not pick consistently. You will get different answers to the same question on different days, and the reason will be invisible because both calls succeeded.
The practical rules:
- Connect servers with distinct jobs, not overlapping ones. One signals layer plus one CRM is fine. Two contact databases is asking for it.
- If you must run overlapping servers, put them in different workspaces or projects rather than the same one.
- When an agent gives an inconsistent answer, check which tool it called before you blame the data.
Result size, the limit nobody mentions
Covered fully in why your prospecting agent silently drops results, but it belongs in any honest overview because it is the failure people hit first.
Claude caps a tool result at roughly 150,000 characters on Claude.ai and Claude Desktop, and 25,000 tokens in Claude Code. Ask for a hundred rows of dense JSON and you may get sixty, with no error anywhere: the server returned everything, the client trimmed to fit, and the model summarised what arrived.
The design consequence for servers is real. A tool that returns forty fields per company fits a third as many companies into a response as one that returns twelve. When you evaluate a server, ask what a single row weighs.
How to evaluate a GTM MCP server
Six questions, in the order they actually matter.
1. Does it answer live, or serve a cached export? Both are legitimate; they are different products. A cached layer is faster and cheaper and its data was true at collection time. A live query costs a round trip and tells you what is true now. What matters is that the vendor says which one it is. A server that describes a snapshot as real-time has told you something useful about the vendor.
2. What does one row weigh? See above. Verbose rows are a hidden cap on how much you can actually retrieve.
3. How is it priced against agent behaviour? Per-seat pricing prices a human. An agent making a hundred queries in an afternoon is not a seat, and per-seat pricing either becomes very expensive or gets enforced with rate limits that make the agent useless. Usage pricing aligns better, with the caveat that usage pricing on attempts rather than results means you pay for misses.
4. What are the coverage gaps, and will they tell you? Every B2B dataset has holes: geographies, verticals, company sizes, seniorities. A vendor that publishes its gaps is more useful than one claiming universal coverage, because you can plan around a stated gap and cannot plan around a discovered one.
5. What auth does it support? See above.
6. Which clients has anyone actually tested? "Works with any MCP client" is a claim about the protocol, not about the product. Ask which ones someone has connected end to end.
Build or buy
The threshold is narrower than it looks.
Build when the data is yours: your product usage, your CRM, your warehouse, your proprietary scoring. Nobody can sell you a server for data only you have, and the MCP SDKs make wrapping an internal API a genuinely small project. This is the strongest case and it is underused.
Buy when the data is external. Building a server is easy; acquiring and maintaining B2B data is not. The server is a few hundred lines. The pipeline behind it is contracts, coverage testing, entity resolution, verification and a permanent maintenance burden.
The common mistake is building a thin wrapper around a vendor API you already pay for, which gets you an integration to maintain and no new data. If the vendor has its own MCP server, use it.
What MCP does not solve
Data quality. A protocol moves data. It does not improve it. Bad data arriving faster is still bad data, now with more confidence attached because a model wrote it up in fluent prose.
Judgement about who to contact. An agent will happily research an account nobody should be selling to. The ICP is still your job.
Deliverability. Nothing here affects whether your email lands. That is domain reputation, sending infrastructure and list hygiene, and it is unmoved by how you sourced the address.
The message. A better first line from a real signal beats a generic one, and neither survives a product nobody wants.
Compliance. Querying data live rather than exporting it does not change your lawful basis for contacting someone. If anything, an agent that can pull contacts on demand makes it more important that someone has thought about that.
Where to go next
- What is an MCP server for sales? for the plain-English version of the mechanics.
- Why your prospecting agent silently drops results for the limits in detail.
- The best MCP servers for sales for the current field, with our bias disclosed.
- How to connect Claude to live B2B data for a setup you can follow in ten minutes.
- B2B buying signals for what to actually ask for once you are connected.
Sources
- Model Context Protocol, Introduction and Versioning. Verified 25 August 2026.
- Anthropic, Building custom connectors. Verified 25 August 2026. Source of the result-size limits, timeouts and supported authorization specifications.