On this page
A GTM MCP server should expose four kinds of tool:
Business context tools return what the company intends: ICP, personas, funnel stages, value propositions, messaging, the motion.
Data tools return what exists, resolved to one identity: leads, accounts, opportunities, campaigns, conversations, meetings, journeys, buying groups.
Decision intelligence tools return what has already been computed: attribution, signals, predictions, recommendations, next best actions.
Action tools change something, under approval: update an opportunity, refine an audience, send a message, move spend, create a task.
Most MCP servers we have looked at expose only the second kind and leave the agent to reconstruct the other three from scratch.
That is the argument. The rest of this is why we hold it, and what it costs to get it wrong.
Try it with a data-only server
Connect an assistant to a CRM through a plain MCP server and ask which accounts are at risk this quarter. Watch what it does. It calls a tool to list opportunities. Another to list activities. Another for contacts. Another for email threads. Then it reconstructs which activities belong to which opportunity, decides for itself what "at risk" means, reasons about engagement decay, and produces an answer. Ask again tomorrow and it does all of that again, with a slightly different definition of risk, at the same token cost.
People hit the wall quickly. A marketing operations leader at a software supply chain company found MCP tool definitions eating so much of a 200,000-token window that he now disables every other server to run one. A marketing leader at an enterprise search company said the agent "trips over itself" once heavy business logic sits on top of the raw data. They are describing the same architecture from two sides: the tool layer supplies records, the model is asked to supply the analytics, and the model is the most expensive and least consistent place in the whole stack to do analytics.
The principle we have landed on is not complicated. Deterministic, domain-specific analytical logic belongs in the tool layer. The model belongs where flexible reasoning adds something: interpreting, orchestrating, choosing what to do with a computed answer.
Gartner's March 2026 data and analytics predictions expect universal semantic layers to be treated as critical infrastructure by 2030, alongside data platforms and cybersecurity, and expect half of AI agent deployment failures by then to trace to insufficient runtime enforcement by governance platforms. A tool layer that serves raw records is a data platform without a semantic layer and without governance. The four primitives are what closing that gap looks like for a revenue team specifically.
The four MCP Tools:
Business context
Tools that return the operating logic: ICP definitions, persona models, funnel stages and what conversion means at each one, value propositions, messaging by segment, and the motion itself, meaning which stages hand off to whom and what a qualified opportunity means here as opposed to at the company next door. Without these, the agent infers the process from the data and gets it subtly wrong. A stage called "Evaluation" is a technical proof at one company and a pricing conversation at another. With these, the agent reasons inside your definitions instead of its own.
Data and context
Tools that return identity-resolved entities. The word doing the work is resolved. Every record comes back already matched to one person and one account across CRM, marketing automation, ad platforms, web, product and conversations, with history attached. In our catalogue these look like get_account_context, get_buying_group, get_journey and resolve_identity, and they can be that simple because the Full Funnel Data Graph did the resolving before the agent asked.
Decision intelligence
Tools that return computed outputs: attribution weights per touchpoint, engagement and momentum signals, sentiment from conversations, expansion and risk signals, lead and account propensity, pipeline and booking readiness, campaign performance predictions, incrementality, marketing mix response curves, next best actions. Names like get_account_momentum, score_propensity, predict_pipeline_readiness, run_attribution, run_incrementality, get_response_curve. We run more than 20 models on the same resolved context, which matters less as a number than as a property: the propensity one tool returns and the attribution another returns were computed from the same facts, so they agree.
This is the layer that changes what an agent costs to run. One call returns the risk flag and the reason for it. The model does not recompute engagement decay from three hundred activity records to get there.
Action
Tools that change state: update_crm, push_audience, trigger_outreach, reallocate_spend, create a task or a sequence. Every one runs through governance. Proposed, held for approval where policy says so, committed, reversible from the ledger. On the GTM Harness that is Propose, Approve, Commit, Roll back, and an external assistant's write goes through it exactly as one of our own agents' does. The security side is in MCP security for enterprise AI agents.
One request, through all four
An account's ad engagement rises. Three people from it visit the site. A champion replies to an email. A meeting transcript lands. Someone asks an assistant what to do.
The data tools return the four events already resolved to one account and its buying group, with the campaign journey attached. get_buying_group returns the contacts, their roles against the persona model, and the open opportunity they map to. get_account_momentum and get_sentiment come back with rising momentum, positive sentiment with one open objection, multi-threaded engagement and high pipeline propensity. The agent computed none of that. The next-best-action tool recommends SDR outreach to the two unengaged stakeholders, inclusion in the acceleration audience, a task on the opportunity and a spend increase on the campaign that produced the engagement. Then update_crm, push_audience, trigger_outreach and reallocate_spend are proposed. The audience push and the task commit under standing approval. The spend change waits for a person.
The model's contribution to that flow was reading five computed outputs and choosing. Everything deterministic happened below it, once, in the tool layer.
What each role actually asks
The reason the four primitives exist is that every GTM role asks the tool layer a different question, and a data-only server cannot answer any of them directly. A CMO asks what is driving pipeline and where to move spend. An SDR asks which leads are hot today and what to say. A CRO asks which opportunities are at risk and what improves the odds of close. A customer success lead asks which accounts show expansion signals and where engagement is weakening. Every one of those is a decision intelligence question with an action behind it, and every one gets answered in fewer calls, with less context, when the intelligence was computed before the call was made.
A marketing operations leader at a software supply chain company described working this way as picking through a crowded journey, "a needle in a haystack a little bit, but RevSure has been helping me pick through that haystack. In general, it's feeling powerful." An operations manager at a market-data company used one MCP query to settle an executive's claim that the company's top twenty accounts had never visited the website. They had. One report, one tool, argument over.
Frequently asked questions
What tools should a GTM MCP server expose?
Four kinds. Business context tools that return the ICP, personas, funnel definitions and motion. Data tools that return identity-resolved leads, accounts, opportunities, campaigns, conversations, journeys and buying groups. Decision intelligence tools that return computed attribution, signals, predictions and next best actions. Action tools that update the CRM, refine an audience, send a message, move spend or create a task, under approval.
What is the difference between a data MCP tool and an intelligence MCP tool?
A data tool returns records and leaves the reasoning to the model, so the agent recomputes attribution from raw touchpoints every time, at token cost, with different answers on different days. An intelligence tool returns the computed answer: the weights, the propensity score, the risk flag. The model orchestrates instead of recalculating.
Why do MCP servers cause context-window problems?
Tool definitions and raw results eat the model's context budget. A server exposing dozens of raw-record tools, each returning big payloads, can fill a 200,000-token window before the agent has reasoned about anything. Fewer, higher-level tools returning computed outputs use far less context per task.
How does MCP relate to the GTM Harness?
MCP is how outside agents reach RevSure's context and intelligence. The GTM Harness is where actions run under Propose, Approve, Commit and Roll back. Action tools exposed over MCP execute through the Harness, so an external assistant's write is governed the same way our own agents' writes are.
Are the RevSure MCP tool names fixed?
The tool families are the stable design: context and identity, signals and intelligence, prediction and forecasting, measurement and optimisation, activation and orchestration. Individual names such as get_account_context or run_attribution are illustrative and will change as the product does.
Related reading: what is an MCP server, MCP for GTM, AI context layer.