Reach Is Not Analysis

The Model Context Protocol, known as MCP, has changed what the agents inside your tech stack can see. Conversation intelligence platforms and CRMs now let their agents call out to other systems and pull in context: support tickets, CRM fields, email history, internal threads.

That is real progress for deal-level work. An agent preparing a rep for a call can now see far more of the account than its host application holds.

But reach is not analysis. An MCP-connected agent retrieves data at the moment a question is asked, for the record in front of it. Questions about why you win and why you lose need something different: every engagement record from every system, matched to the same opportunities, kept over time, and counted.

That is the job of a GTM data lake. This paper explains how the two approaches differ, which questions each can answer, and what to ask before assuming the agents you already own can answer questions about your whole pipeline.

What MCP is, and what it changed

MCP is an open standard, introduced by Anthropic in November 2024 and since adopted widely, that gives AI applications a common way to connect to outside tools and data. A system publishes an MCP server describing what it can return. An AI application, acting as an MCP client, calls that server when it needs the information.

In go-to-market software the effect has been fast:

• Gong offers an MCP client that lets its AI agents connect to external MCP servers and use that data in its workflows, for example pulling support tickets, implementation updates or CRM information into an account briefing.
• Salesforce Agentforce includes a native MCP client, so agents can register external MCP servers and use their tools and data.
• Many other vendors now publish MCP servers so that assistants and agents elsewhere can reach their data.

The practical result is that the walls between applications are lower. The old line that an in-app agent sees only its own application's data is no longer accurate, and any analysis of the GTM stack should say so.

How an MCP-connected agent actually works

It helps to follow a single question through the system.

1. A question arrives in context. A rep opens a deal, an account or a call and asks the agent something.
2. The agent chooses tools. It decides which MCP servers to call and what to ask each one for.
3. Each server returns what it returns. Results come back system by system, shaped by that server's permissions, filters, paging and rate limits.
4. The model reads and writes. The language model reads the returned text inside its context window and writes an answer, often with citations.
5. Nothing is kept. The next question starts the process again.

This is a strong design for the question it was built for: what is happening on this deal, and what should the rep do next? It is a weak design for a different kind of question: across every deal we worked last year, which pattern comes before a loss?

Questions that need a denominator

Revenue leaders are ultimately accountable for questions about the whole pipeline, not one deal:

• Of deals above $50K that were cut down to fit a budget, how many closed won?
• Which competitor comes up on calls in the deals we lose, and at what stage?
• Which campaigns produce opportunities that close, not just opportunities that open?
• Which rep behaviors separate won deals from lost ones?

Each of these needs four things at once: the full population of relevant opportunities, every engagement record matched to each of them, enough history to see the pattern, and a count. Without the count there is no denominator, and without a denominator there is an anecdote, not a finding.

No single deal reveals a losing pattern. The pattern only exists in the count.

A Rev-Lens customer example makes the point. Among 62 qualifying deals above $50K over 180 days, 14 had their configuration cut down to fit a budget, or never attempted. None of those 14 closed won. The CRM recorded none of the descope decisions; they lived on calls, in revised quotes and in internal threads. Looking at any one of those deals, even with every system in reach, shows a lost deal with a price reason. Counting all of them shows a tactic that never wins.

Five limits of analysis at question time

None of these are flaws in MCP. They follow from what retrieval at question time is designed to do.

Scope

Agents act on the record in view. A pipeline question needs the population, and an agent working deal by deal has no natural way to assemble it.

Joins

Every system identifies people and companies differently: an email address, a web domain, a call participant's name, a Slack channel. Matching them all to the same opportunity is entity resolution, and it has to be done once, carefully, with deduplication. An agent calling several servers in turn gets several separate result sets, not a join.

History

Retrieval interfaces page their results and enforce rate limits. Pulling a year of calls, emails and threads for hundreds of opportunities through tool calls is slow at best, and incomplete at worst, without anyone being told what was missed.

Counting

A language model reading retrieved text is excellent at summarizing it. Counting reliably across hundreds of records is a different task, and it needs those records in a structured store. When results exceed what fits in the context window, the model is working from a sample, and the answer does not say so.

Repeatability

Each run retrieves afresh, so two runs of the same question can come back different, and there is rarely an audit trail of which records drove the conclusion. That makes a finding hard to defend in front of a CRO, a board or the reps who are being asked to change.

What a GTM data lake does differently

A GTM data lake starts from the other end. Instead of reaching into each system when a question is asked, it brings the data together first.

• Consolidate. One governed copy of engagement data, including CRM history, recorded calls, email, internal chat, website visits and content engagement, held inside your own infrastructure.
• Resolve and join. People, companies and conversations matched to the same accounts and opportunities once, with duplicates removed.
• Keep history. The full record for the period you choose, not whatever an interface returns on a given day.
• Count. Every finding carries a denominator and traces back to the records it came from.
• Then apply agents. LLM agents read the joined, structured dataset, so they can find the pattern and quote the evidence behind it.

The two approaches compared

Use both

This is not a choice between the two. They answer different questions, and they work best together.

• MCP-connected agents for deal execution. Call preparation, account briefings, follow-ups and next steps, where reach across systems for one record is exactly what is needed.
• The data lake for pipeline decisions. Why you win and why you lose, which deals sales management should inspect, which reps to coach and on what, and which segments to pursue or defocus.

The two connect naturally. Findings from the data lake tell sales management which deals and behaviors to inspect. The agents in the stack then help reps work those deals better.

Questions to ask your vendors

Before assuming an agent in your stack can answer a pipeline question, ask:

• When your agent answers a question about many deals, how many records did it actually read?
• How does it match a call participant, an email thread and a Slack conversation to the same opportunity?
• How far back can it retrieve, and what happens when it reaches a rate limit?
• Can it show the denominator and the source records behind a pattern it reports?
• Where does the retrieved data go during the request, and who keeps it?

If the answer is a well written summary without a count, you have reach. You do not yet have analysis.