Model Context Protocol (MCP) settled a question that had blocked agents since function calling shipped in 2023: how a model reaches a tool it was never trained on. That part now works. Point Claude or Cursor at a server and it will send email, query Postgres, or drive Blender. What the protocol never specified is what those tools hand back, and for marketing agents that gap is the whole problem.
This post covers what MCP standardized, what it deliberately left open, why marketing data is a harder case than the developer tooling that adopted MCP first, and how we built OpenRush against that gap.
What MCP actually standardized
MCP is an open protocol for giving models context in a way that generalizes across integrations. It defines how a client discovers the tools a server offers, how it calls them, and how the transport works. Anthropic published it in November 2024, and the client side is now table stakes: Claude, Cursor, Codex, and most agent frameworks speak it.
The protocol borrowed its shape from the Language Server Protocol (LSP), which ended the N-times-M problem between editors and languages. One server, any editor. MCP makes the same trade for models: one server, any agent.
Where it goes further than LSP is the execution model. LSP reacts to a user typing. MCP assumes an agent that decides on its own which tools to call, in what order, and how to chain them, with a human in the loop for approval when the call has consequences. That autonomy is the point, and it is also what raises the bar on the data underneath.
Where agents are doing real work today
Adoption ran through developer tooling first, which is normal for a new protocol, and the second wave is business software.
Developer-first workflows
Developers wanted to stop leaving the editor. Postgres and Supabase servers put database reads in the IDE, browser servers give coding agents a live environment to debug against, and documentation servers inject accurate context instead of leaving the model to recall an API from training data. The pattern is consistent: the tool was already an API, and MCP wrapped it.
The business clients that were predicted
Yoko Li's a16z deep dive on MCP called this in March 2025, arguing that specialized clients for customer support, marketing, and design would follow once the protocol matured. That happened. Marketers now run competitor research, keyword work, and site audits by conversation, and the ambitious ones run them unattended on a schedule.
The clients arrived. The data underneath them did not.
Marketing is the harder case
A Postgres server has one source, one schema, one freshness answer, and one owner. Marketing has none of those properties, which is why wrapping marketing APIs in MCP servers produced disappointing agents.
The data splits across two categories that behave nothing alike:
- Sources you own, reached through OAuth per client account: Search Console, analytics, ads, and customer relationship management (CRM)
- Sources nobody owns, reached by observation: live search results, competitor rankings, keyword demand, backlink graphs
An agent answering "who is taking our traffic and what do we do about it" has to cross that line several times in one task. It needs your rankings, then a competitor set derived from an index, then a live search result to confirm what the page actually looks like today, then your own analytics to size the loss. Every one of those sources has its own auth, schema, rate limit, and staleness. The agent burns most of its context reconciling formats rather than reasoning.
There is a second problem that matters more. Marketing numbers vary in how much they should be trusted. A rank pulled from a search index this morning and a rank observed in a live search result thirty seconds ago are both "position 3," and they are not the same claim. A raw API dump flattens that distinction, so the model treats an estimate and an observation as equally solid, and its recommendation inherits the error without ever flagging it.
The layer the protocol leaves open
MCP is deliberately unopinionated about payloads. That was the right call for a transport protocol and it leaves a real gap:
| MCP defines | MCP leaves to the server |
|---|---|
| Transport and connection lifecycle | The shape of the response body |
| Tool discovery and schemas | Whether a result states its source |
| Invocation and results | Whether a result states its freshness |
| Human approval hooks | Whether a result states what it omits |
Two servers can answer the same marketing question and return payloads that force the agent to interpret them differently. That is not a protocol bug. It is the layer above the protocol, and it has no standard yet.
This is where the a16z piece landed a prediction worth repeating: the mapping from API to tool is rarely one to one, and tools are a higher abstraction chosen for the moment of task execution. We agree, and would put it more strongly for data. An agent-facing data tool is a different product from the API underneath it, not a wrapper on top.
What an agent-native data layer looks like
We ran an AI-native SEO agency before building OpenRush, so we hit this from the wrong side first. Our agents were capable, and they kept losing to plumbing: client OAuth, third-party API quirks, and payloads that ate the context window before the model reached a decision. We built the layer we needed, then found that every agency around us was stuck on the same thing.
OpenRush returns one envelope for every tool, versioned as ofe/1.0. Here is a trimmed response:
{
"schema_version": "ofe/1.0",
"domain": "seo",
"data": { "domain": "competitor.com", "keywords_returned": 25 },
"facts": [
{
"type": "seo.keyword_ranking",
"subject": { "domain": "competitor.com", "keyword": "mcp server hosting" },
"value": { "position": 3, "url": "https://competitor.com/hosting" },
"provenance": {
"source_class": "live_serp",
"method": "serp_fetch",
"confidence": 0.94,
"observed_at": "2026-07-24T14:02:11Z",
"cache_hit": false
}
}
],
"coverage": { "returned": 25, "total_available": 412, "truncated": true },
"next_actions": [
{ "tool": "compare_keyword_coverage", "use_when": "you want the gap against this competitor" }
]
}Three parts of that envelope matter most for how an agent reasons.
Tools are named for jobs, not endpoints
The surface is 11 tools across four domains: SEO, SERP, audit, and core. discover_competitors answers who competes with you organically. compare_keyword_coverage answers where they cover demand you miss. audit_site answers what is broken on your own pages. None of these map cleanly to a single upstream call, and the agent should not have to assemble them.
Tool selection is a real cost at inference time. We narrowed the surface on purpose: a model choosing among 11 job-shaped tools has fewer ways to pick wrong than one facing 60 endpoint-shaped ones, and every wrong call costs a round trip plus the tokens to recover from it.
Facts carry their own provenance
Every claim is typed and namespaced by domain, so seo.keyword_ranking and serp.result stay distinguishable. Each one carries its own provenance block: source class, method, a confidence between 0 and 1, the observation time, and whether it came from cache. Trust attaches to the individual fact rather than to the tool that returned it, because a single response often mixes a live observation with an indexed estimate.
The subject field pins each fact to stable entity ids, so an agent can join a claim from inspect_domain to one from inspect_serp without string matching on domain names.
Coverage says what it left out
The coverage block reports what the result does and does not include: how many rows came back against how many exist, whether the response was truncated, and the scope of the observation. An agent reading returned: 25, total_available: 412 knows it is looking at a sample and can call export_dataset for the full set. Without that block, a truncated list reads as a complete one, and the agent confidently reports a partial answer.
In our benchmarks, agents running on OpenRush answer 40% faster and spend 25% fewer tokens than the same agents pointed at the raw upstream API, and the answers are better because the model spends its budget deciding rather than parsing.
What is still unsolved
We are early, and shipping this has surfaced problems the ecosystem has not settled.
Identity across client accounts
An agency agent works across dozens of client accounts, each with its own connections to Search Console, ads, and analytics. MCP's session model assumes one authenticated context, which fits a developer on a laptop and fits an agency badly. Scoping an agent to the right client's data, and proving afterward which account a fact came from, needs a tenancy model the protocol does not define.
Write access and approval
Reading marketing data is the safe half. The valuable half is acting: publishing a page, adjusting a bid, pausing a campaign. Those calls need granular approval, not a session-level grant that treats "read a rank" and "spend money" as the same permission. MCP's human-in-the-loop hooks are a start, and the authorization model underneath them is still coarse.
Work that outlives the conversation
Marketing questions are rarely answered in one call. Tracking visibility across a keyword set over a quarter, or watching a competitor for movement, means scheduled and resumable execution. Today most of that lives in client-side glue that every team rebuilds.
Attribution across sources
Once an agent can reach owned and open-web data in one place, the obvious next question is which change caused which outcome. That requires joining sources whose entity models disagree about what a page, a keyword, and a conversion are. Stable entity ids are a prerequisite, which is why we put subject in the envelope early.
The cost of a single fact
Every tool call has a price, in credits and in latency. inspect_serp costs 2 credits, compare_keyword_coverage costs 12, and an autonomous agent that plans a week of work should reason about that budget the way it reasons about tokens. We expose per-tool cost in describe_capabilities for exactly this reason, and agent-side cost-aware planning is barely started across the industry.
What changes when marketing agents run themselves
If this plays out, a few things follow:
- Data vendors compete on agent legibility, not dashboard polish. The winning product is the one an agent picks correctly and parses cheaply, which is a different design target from the one every SEO tool optimized for over the last decade.
- Provenance becomes a product requirement. Once agents act without a human reading the intermediate steps, an unsourced number is a liability. Buyers will start asking where a figure came from and how old it is, and the answer has to be in the payload.
- Pricing moves toward per-fact economics. Seat-based pricing assumes a human in a dashboard. Agents consume data in bursts against a task, and the pricing that survives will meter the work.
- The moat moves from data access to data shaping. Raw SERP and index data is a commodity with several suppliers. Turning it into decision-ready context an agent can act on in one pass is the part that is hard to copy.
Where we are taking this
OpenRush covers SEO, SERP, and site audit data today, with 11 tools live and more of the surface enabled as we go. Ads, analytics, social, and CRM are next, and the target is one layer where an agent reasons across your owned data and the open web in a single conversation without a human stitching sources together.
The protocol question is answered. The data question is open, and it is the one that decides whether autonomous marketing agents are a demo or a job. If you are building in this space, connect an agent and tell us where the envelope falls short. Start with Welcome to OpenRush for the short version of what we do, or the use cases for what people run on it.