Nexla MCP Server vs. Google Ads MCP: What a Task-Specific vs. Native Benchmark Actually Showed

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.

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.

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.

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.

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.

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

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

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.

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.

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.

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:

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

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.

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.