Schema Drift Reaches the Tool Definition
Context layer series Everyone who sells a context layer talks about freshness. Fresh rows, streaming…
Aug 20, 2026
Short answer: A task-specific MCP server and a vendor-native one can return the exact same data and still cost very different amounts to run. We tested both against one live Google Ads account across 40 task-cells. The task-specific server answered every task in one tool call. The native server averaged 4.7. It also used 4.7× fewer tokens with claude-opus-5 and 6.8× fewer with gpt-5.5. And it installed with one config block, while the native path needs a developer token approval, a Cloud project and an OAuth client you cannot script.
Almost every vendor ships an MCP server now. Google shipped google-ads-mcp. If you are putting agents in front of business data, you have a real choice to make. Use the vendor’s native server, or use a task-specific server that exposes pre-modeled data products instead of a raw API.
We ran that comparison ourselves and tried to be fair about it. One live Google Ads account. Two servers. Ten tasks written so neither side had a home-field advantage. Two frontier agent models. Forty task-cells in a single pass. Here is what we saw.
4.7× fewer tokens
Task-specific vs. native MCP
With Claude Opus 5, and 6.8× fewer with GPT-5.5, across 40 benchmarked task-cells.
100% identical data
Correctness, verified
Both servers returned byte-identical results from the same live Google Ads account.
1 tool call vs. 4.7
Agent efficiency
Every task answered in exactly one tool call where the native server averaged 4.7.
Native vs. task-specific: two different jobs for the agent
Both servers reached the exact same data. That is not where they differ. They differ in what the agent has to decide before it can answer you.
Native / general-purpose (Google)
“What query do you want to run?”
- 3 tools: row search, resource metadata, list accessible customers
- Agent must choose the account, the resource, the fields, the filters and the date segmentation
- Schema knowledge comes from model priors or a metadata call
- Full API surface reachable, including questions you did not anticipate
Task-specific (Nexla)
“Which question are you answering?”
- 6 data tools: campaign, ad group and keyword performance, plus a daily-grain campaign tool
- Inputs are
limit,offsetand an optional name filter. No query language, no customer ID - Account and 30-day window are bound at configuration time. Nothing to discover
- Bounded surface: only the questions that were modeled
That one design choice, who resolves the schema, shows up in every number below.
Before a single query: the setup gap
Runtime benchmarks miss the biggest practical difference between these servers, so we will start there. We installed both on the same clean macOS machine.
| Setup requirement | Task-specific (Nexla) | Native (Google) |
|---|---|---|
| Software to install | None. npx fetches the remote client |
uv or pipx, Python, gcloud |
| Cloud projects | 0 | 1 |
| APIs to enable | 0 | 1 |
| OAuth clients to create | 0 | 1, Cloud Console only |
| Approval processes | 0 | 1, on Google’s timeline |
| Steps that cannot be scripted | 0 | 3 |
| Recurring maintenance | None | 7-day re-consent unless the consent screen is Internal |
| Credential the agent carries | One revocable, task-scoped service key | A developer token plus a user’s Application Default Credentials |
What it takes before the first query
Native (Google)0/5 done
1Create a Google Cloud project
2Enable the Google Ads API
3Create a Desktop OAuth client, Console only, cannot be scripted
4Apply for a developer token with Explorer access, then wait
5Run gcloud auth to produce ADC carrying the adwords scope
Task-specific (Nexla)0/1 done
1Paste the server URL and a service key
The native path needs a developer token. Google issues that token only from the API Center of a Google Ads manager account, and you need at least Explorer access or production queries fail. Upgrading access is an application to Google, on Google’s schedule. No amount of engineering shortens it. Creating the Desktop OAuth client has no gcloud equivalent either. It is a browser-only step, so you cannot run it in CI.
There is also a trap the README leaves out. If the OAuth consent screen is set to External, refresh tokens expire after seven days. Your integration dies weekly until a human re-consents. To avoid that you need an Internal consent screen, which requires the Cloud project to sit in a Workspace org that owns the user. Nothing in the setup docs tells you this. You discover it at debug time.
The task-specific path was one config block: a URL and a bearer token.
The entire Nexla server configuration
command: npxargs: -y mcp-remote --header "Authorization: Bearer ${NEXLA_GOOGLE_ADS_SERVICE_KEY}" https://api-genai.nexla.io/mcp/service_key/google-ads-performance-7fbt0kzrm
In practice the native setup took us two working sessions across two days, most of it waiting on a token and clicking through Console. That gap never shows up in a latency chart. For most teams it is the number that decides the question.
Data fidelity: we checked, we did not assume
Before benchmarking anything, we pulled ground truth straight from the Google Ads API using GAQL with DURING LAST_30_DAYS AND metrics.impressions > 0, then checked it against all six Nexla tools independently.
| Check | Result |
|---|---|
| Ground-truth answers, Google API vs Nexla | 10 of 10 identical |
| Per-campaign metrics (impressions, clicks, cost) | All 6 campaigns matched exactly |
| Per-ad-group metrics | All 10 ad groups matched exactly |
| Account totals over the window | 8,639 impressions, 266 clicks, $1,387.70 |
| Entity counts, both sides | 6 campaigns, 10 ad groups, 31 keywords |
They agreed at every level. Pre-modeling cost us nothing in fidelity. The modeled datasets are a faithful projection of the vendor API.
How we ran it
Benchmark configuration
- Harness:
mcp-bench - Agent models:
claude-opus-5andgpt-5.5 - Judge:
claude-opus-5, scored against exact ground truth - Dataset: 10 tool-agnostic tasks, v6.0. No tool names, no field names, no query language in any prompt
- Account: one live Google Ads customer, rolling 30-day window
- Scale: 2 servers × 2 agent environments × 10 tasks = 40 task-cells, one pass
- Limits: 180s task timeout, 15 max iterations, 5 concurrent tasks
Prompts name no tool and no field, so each server answers through its own interface. Before we issued the benchmark, a pre-flight gate confirmed for every task and every server that the expected answer was actually derivable from the bytes the model receives. We executed the run once.
The results
Google divided by Nexla, pick the agent model
4.7×
Fewer tool calls1.0 against 4.7
4.7×
Fewer tokens10,668 against 50,102
2.8×
Fewer bytes93,058 against 263,651
1.9×
Faster end to end18.0s against 33.8s
| Agent | Server | Tool calls | Tokens | Bytes returned | Latency (adjusted) |
|---|---|---|---|---|---|
claude-opus-5 |
Nexla | 1.0 | 10,668 | 93,058 | 18.0s |
claude-opus-5 |
4.7 | 50,102 | 263,651 | 33.8s | |
gpt-5.5 |
Nexla | 1.0 | 5,788 | 89,260 | 11.8s |
gpt-5.5 |
4.8 | 39,086 | 429,906 | 25.4s |
One handicap you should know about. We adjusted latency for measured transport startup, five samples per server: 4.21s for Nexla through npx mcp-remote, respawned for every task, against 0.75s for Google’s local binary. That handicap of roughly 3.5s per task runs against Nexla for the whole benchmark, and it still finishes ahead on both models.
Finding 1: one tool call per task, against 4.7
Nexla made exactly one tool call per task, in both model families. Google averaged 4.7 and 4.8. Here is where those calls went, across all 20 of its task-cells.
| Efficiency ratio, Google divided by Nexla | claude-opus-5 |
gpt-5.5 |
|---|---|---|
| Tool calls | 4.7× | 4.8× |
| Tokens | 4.7× | 6.8× |
| Bytes returned | 2.8× | 4.8× |
| Latency, adjusted | 1.9× | 2.2× |
The ten questions, one at a time
Read the middle row. The agent opened every one of the 20 tasks, on both models, by asking which accounts it could see. It often followed with a schema lookup before fetching any data. That is the discovery tax. It is baked into the server’s contract, which forces the agent to work out where it is before it can ask anything.
A task-specific server binds to one account and one set of modeled tables at configuration time. There is nothing to discover, so the agent goes straight to the query.
Finding 2: 4.7× to 6.8× fewer tokens, and why
The byte reduction does not explain the token reduction on its own.
| Google server, tool call | claude-opus-5 |
gpt-5.5 |
|---|---|---|
search_search |
31 | 23 |
customers_list_accessible_customers |
10 | 10 |
metadata_get_resource_metadata |
6 | 15 |
| Total across 10 tasks | 47 | 48 |
One task, from prompt to answer
Task-specific1 tool call
nexset_read_campaign_performanceanswer
Native4 tool calls
customers_list_accessible_customersmetadata_get_resource_metadatasearch_searchsearch_searchanswer
Input tokens get billed again on every turn. Each turn resends the system prompt, the full tool schemas and everything accumulated so far. A four-call task pays that four times over. Turns are what you are actually paying for.
Tool-schema overhead also runs slightly in the task-specific server’s favour.
| Tools | Schema chars | Cost per turn | |
|---|---|---|---|
| Nexla | 11 | 6,927 | ~1,731 tokens |
| 3 | 7,401 | ~1,850 tokens |
Fewer tools does not mean a cheaper schema. Three general-purpose tools carrying a query language cost more per turn than eleven narrow ones.
Finding 3: discovery is also a failure mode
Against the native server, gpt-5.5 left two of its ten tasks unanswered, and both failed the same way. This follows directly from discovery-first design.
On two tasks the agent called customers_list_accessible_customers, saw two accessible accounts, and stopped to ask which one you meant instead of proceeding:
What the agent returned instead of an answer
“I have access to two Google Ads accounts… Which account should I check?”
That is reasonable agent behaviour. Our judge agreed. It is also the operational shape of the difference. The general-purpose server hands the agent more decisions, and every decision is a place where a capable model can reasonably choose to stop.
How to choose
Reach for the native server (Google) when
- You cannot predict the questions. Pre-modeling is a bet that you know them
- You need selective filtering over large tables, where pushing predicates into the query is worth more than saving round-trips
- You need surface outside the modeled scope: budgets, audiences, asset groups, arbitrary historical windows
- You want a path toward write operations
Reach for a task-specific server (Nexla) when
- You want agents answering this week rather than after a token approval
- Token cost matters. 4.7× to 6.8×, measured across two frontier model families
- The questions are known and repeat, which is what most production reporting actually looks like
- The reporting window and the account must not be gettable-wrong
- The question spans more than one system, and stitching several vendor servers together would put the join in the agent context window
- Governance matters: one revocable task-scoped key instead of per-person OAuth credentials on laptops
Credential: native server
A person’s laptop
- Application Default Credentials sitting in a file on a developer machine
- Scoped to that person’s entire Ads access, not to the task
- No way to express “read campaign performance and nothing else”
- Offboarding means chasing files. Every new hire repeats the OAuth client setup
Credential: task-specific server
One revocable key
- The vendor credential lives centrally, never on a laptop
- Scope binds to the key, not the person
- “What can this agent touch?” is answerable by reading the key
- Revocation is one action, and it takes effect everywhere at once
Why build task-specific MCP servers with MCP Studio
MCP Studio turns a task-specific MCP server into a configuration step instead of an engineering project. You build from 1000+ enterprise systems and tools. Every tool it exposes runs on governed data access. One server can span as many systems as the question needs. Setup is a URL and a bearer token.
The server in this benchmark was built in MCP Studio, on top of Nexla connectivity that reaches 1000+ systems bidirectionally: SaaS applications, databases, warehouses and lakehouses, streams, files, APIs and legacy systems. Google Ads is one of them, which is the only reason this comparison was possible.
Task-specific does not have to mean single-system. That is where the confusion in this benchmark came from. In MCP Studio the tables behind one server can come from as many systems as you need, so the agent still makes one call against one contract.
Access is governed all the way down. Each tool runs on a Nexset, a governed data product that carries its schema, semantics, lineage and policy with it. Scope binds to the key instead of to a person. So “what can this agent touch” is a question you answer by reading the key, and revoking it is one action instead of a hunt through credential files on laptops.
Setup does not get harder as scope grows. A server spanning six systems installs exactly like the one config block above: a URL and a bearer token. No Cloud project, no OAuth client, no approval queue for each system you add.
This matters more every quarter. Gartner predicts that 40% of enterprise applications will be integrated with task-specific AI agents by the end of 2026, up from less than 5% in 2025. Anushree Verma, Sr Director Analyst at Gartner, put it this way: “AI agents will evolve rapidly, progressing from task and application specific agents to agentic ecosystems.” Every one of those agents will pay the discovery tax or it will not. That choice is made when you pick the server.
The takeaway
A native server ships an API gateway. A task-specific server ships a data product. Both can be correct. They do not cost the same to run.
The results that hold up come from architecture. Tuning cannot move them. One call versus 4.7 is a property of the contract. So is the two-day setup versus the one config block. Change the model, change the prompts, change the tasks, and those two numbers stay.
If you are choosing a server for agents, ask the boring questions. How many calls does it take. How much does the bill move when the question changes. How many ways can the agent misread which account it is looking at. And how many people have to click through a Cloud Console before anything works.
The bottom line
- One call, not 4.7. A server bound to one account and one set of modeled tables has nothing to discover, so the agent goes straight to data.
- 4.7× to 6.8× fewer tokens. Round-trips are what you pay for, because every turn re-bills the system prompt, the tool schemas and the whole accumulated context.
- One config block, not an approval queue. A URL and a bearer token, against a Cloud project, an OAuth client you cannot script, and a developer token on Google’s timeline.
Want the wider pattern? Read how it plays out against HubSpot’s MCP server, and see the full method in how we benchmark MCP servers. We also wrote about why the future is not one MCP server per application and about giving agents scoped access. For the platform side, MCP Studio is where these servers get built.
Frequently asked questions
What is the difference between a native MCP server and a task-specific MCP server?
A native MCP server wraps a vendor’s API and hands the agent the whole surface, so the agent decides which account, which fields and which query to use. A task-specific MCP server exposes a small set of pre-modeled data products for a defined job, so the agent makes one call against one contract. Both can return identical data.
Why did the native Google Ads MCP server use more tool calls?
Its contract makes the agent discover context first. In every task-cell the agent listed accessible accounts before doing anything, and often looked up the schema next. Those discovery calls are structural, so they repeat on every task.
Why do fewer tool calls mean fewer tokens?
Input tokens get billed on every turn, and each turn resends the system prompt, all tool schemas and the accumulated context. A four-call task pays that overhead four times. Cutting turns cuts tokens faster than cutting payload size does.
Is the token difference specific to one model?
No. The task-specific server used 4.7× fewer tokens with claude-opus-5 and 6.8× fewer with gpt-5.5, and made one call per task in both.
Did the task-specific server return the same data as the Google Ads API?
Yes. We derived ground truth directly from the Google Ads API with GAQL and checked it against all six Nexla tools. They agreed at every level, so pre-modeling the data cost nothing in fidelity.
How long does each server take to set up?
The task-specific server installed with one config block, a URL and a bearer token. The native path took us two working sessions across two days, most of it waiting on a developer token and clicking through Cloud Console to create an OAuth client.
