MCP Server Benchmark: Task-Specific Servers on Google Ads, HubSpot, Avoma and Salesforce

A task-specific MCP server answers the question on its own side. On Google Ads with claude-opus-5, the Nexla server used 1.0 tool call and 10,668 tokens per task against 4.7 and 50,102; on HubSpot it matched HubSpot’s own server on deal counts and win rate for 21,682 tokens against 708,973 (32.7x uncached, 16.1x in the first run). On Avoma it returned the target-month call figures exactly, from dialer-call records Avoma’s own server could not read, with 1 logged tool error to 25. On Salesforce an agent connected to it with one URL and one key, and its numbers matched Salesforce’s own SOQL on 13 of 13 checks.

We gave an agent a question as a user had typed it, typos included. It asked for an analysis of won and lost deals over the last 90 days, trends in deal size and stage, and any missing data. Same model (claude-opus-5), same HubSpot portal holding a synthetic set of 1,130 deals, two MCP servers.

Both answers came back with 199 closed deals, 135 won and 64 lost, and a 67.8% win rate, all matching ground truth computed from the source data independently of both servers. One answer used 21,682 tokens. The other used 708,973, uncached.

The difference was what each server handed the model. Nexla’s server has six aggregation tools that compute summaries over the full dataset and return finished results. HubSpot’s CRM MCP gives the agent 24 general tools, including SQL, and re-sends about 39,000 tokens of tool schema on every turn. One server answers the question. The other hands the agent a toolbox to work it out.

An MCP server decides what the model reads on every turn: its tool schema and its results. So the shape of the server sets the token bill and the places where an answer can go wrong. A task-specific server is built for a defined set of questions; we covered task-specific vs system-specific MCP servers in an earlier post.

We build these servers in MCP Studio and wanted to measure what a task-specific server changes. So on four systems, Google Ads, HubSpot, Avoma and Salesforce, we held the model, questions and data fixed, changed only the server, and checked the answers against ground truth. This post reports the measures where the task-specific server came out ahead, and the full method behind each number.

What held: on Google Ads and HubSpot, a server that answers the question itself used fewer tokens. On Avoma, a server built on modeled call tables did not hit the validation error that kept Avoma’s own server from reading dialer calls, and the harness logged fewer errored tool calls against it. On Salesforce, Nexla’s hosted task-specific server needed nothing installed to connect. And on Google Ads, HubSpot and Salesforce, its answers held up against ground truth computed outside the servers.

Results across four systems

Figure 1 has one panel per system. On Google Ads, HubSpot and Avoma it compares Nexla’s task-specific server with the vendor’s own MCP server; on Salesforce it compares the Nexla server’s numbers with Salesforce’s own SOQL (Salesforce Object Query Language) results on the same org. Figure 2 is the scorecard: the main measures on each system, against each comparator.

Google Ads (one live, low-volume account; ten tasks). Correctness was 1.00 against 0.975 for Google’s server with claude-opus-5, and 0.90 against 0.77 with gpt-5.5, where one Nexla task never executed because the OpenAI request did not return (1.00 over the nine that did). With claude-opus-5 the Nexla server made 1.0 tool call per task against 4.7, used 10,668 tokens per task against 50,102 (4.7x, uncached), and returned 93,058 bytes of tool results over ten tasks against 263,651 (2.8x). With gpt-5.5 it used 5,788 tokens per task against 39,086 over the tasks that executed (6.8x).

HubSpot (a synthetic 1,130-deal dataset; one open-ended question, run twice). In the second run, both answers gave the same closed-deal count, won/lost split and win rate, matching ground truth, and the Nexla server used 21,682 tokens against 708,973 for HubSpot’s CRM MCP (32.7x, uncached). The first run of the same comparison used 51,867 against 832,739 (16.1x), so we report the gap as 16-33x.

Avoma (Nexla’s own workspace, real data; ten questions). On call analysis the Nexla server scored 0.50 against 0.00 for Avoma’s own server, whose score covers the three call questions with a recorded measurement. The Nexla server’s target-month call count and outbound/inbound split were exact. Over all ten tasks the harness logged 1 errored tool call on the Nexla server and 25 on Avoma’s. Tool schema per turn was 4,637 characters against 15,078 (3.3x).

Salesforce (a synthetic org; ten questions for ideal customer profile, or ICP, planning). An agent connected to the Nexla server with one URL and one key. In the scored run, 9 of 10 answers were judged correct against SOQL ground truth. The tenth, a won-deals date window, returned no answer in the scored run; one unscored re-run of that question returned 121 deals and $29,877,900, exactly the ground truth. In a pre-run check, all 13 ICP aggregates the server computed matched Salesforce’s own SOQL, and all four object totals were exact.

How to read these numbers: tokens are provider-reported input plus output, summed over every turn, with no prompt caching. Each cell has one scored run (HubSpot two). On Avoma, eight cells that failed on an expired login or API timeouts were re-run, and the final run is the one reported.

What this tells us

• Answer-shaped results keep the loop short. The Nexla Google Ads server is bound to one account and to modeled performance tables, so the agent made one call per executed task with no discovery step. Google’s agent listed accessible accounts at the start of all 20 of its task-cells. With claude-opus-5, tokens fell 4.7x (uncached) while tool-result bytes fell only 2.8x, because every turn re-sends the tool schema and the conversation so far. Fewer turns did more than smaller rows, as our Google Ads post also found.
• The schema is a per-turn fee. HubSpot’s server re-sends about 39,000 tokens of tool schema on every turn. In the second run, HubSpot’s first turn alone was 54,876 input tokens, before any data came back, against 3,796 for the Nexla server. On Avoma the schemas were 15,078 characters against 4,637. The schema section below shows how HubSpot’s adds up turn by turn.
• A wrapper inherits its API’s edges. Avoma’s server requires the from and to fields of a call record (frm and to) to be strings, and dialer calls store both as null, so any page of meetings that contains a dialer call fails validation. That error made up 21 of the 25 errored tool calls the harness logged on Avoma’s server. The Nexla server reads a modeled call table, and its target-month answers were exact.

Check against something the server did not produce. On Google Ads, ground truth from the Google Ads API matched all six Nexla tools on 10 of 10 answers. On HubSpot, the counts and win rate matched ground truth computed from the source dataset. On Salesforce, 13 of 13 aggregates matched SOQL, all four object totals were exact, and every capped read in the scored run came back labelled PARTIAL.

The four systems in detail

Each section covers the setup, the measures we report, why they came out that way, and a link to the full write-up where one exists. Google Ads, HubSpot and Avoma have one; Salesforce is new in this post.

Google Ads: one call per task

We ran the Google Ads comparison against Nexla’s own live Google Ads account, a single low-volume account, over a rolling 30-day window. For more detail, read the full Google Ads benchmark.

Google’s official google-ads-mcp server has three general tools: a GAQL (Google Ads Query Language) search, a resource-metadata lookup and an account listing. Our server has six data tools over modeled campaign, ad-group, keyword, search-term, ad and daily campaign performance tables, bound to that one account. Ten tasks covered five categories: structure (2), relationship (2), aggregation (4), totals (1) and point in time (1). Two agents, claude-opus-5 and gpt-5.5, got every task once on both servers, 40 task-cells in all, with claude-opus-5 as the judge. A typical prompt: “Over the last 30 days, what were this account’s total impressions, total clicks, and total cost in dollars?”

Ground truth came from the Google Ads API (GAQL, last 30 days, impressions greater than zero). It matched all six Nexla tools on 10 of 10 answers, so both servers were reading the same data.

Figure 3 shows correctness per task. With claude-opus-5, the Nexla server scored 1.00 on all ten tasks. Google’s server scored 0.975: 1.00 on nine tasks and 0.75 on T4, which asks for one keyword’s match type and ad group without stating the window or the impression qualifier. The agent answered for the whole account and was marked down. We count that as a gap in our prompt, not in Google’s server.

With gpt-5.5, the Nexla server scored 0.90 as measured and 1.00 over the nine tasks that executed. On T1 the OpenAI API request never returned, and the cell timed out at 180 s without a tool call. Our Google Ads post gave the gpt-5.5 call, token and byte figures for the Nexla server over the nine tasks that executed, which is why it reports one call per task for both models. Google’s server scored 0.77. On T1 and T9 the agent listed the accessible accounts, saw two, and stopped to ask which one to use (0.10 each); T4 scored 0.50.

Figure 4 shows mean tokens per task: provider-reported input plus output, summed over every turn, uncached. With claude-opus-5 the averages were 10,668 tokens on the Nexla server and 50,102 on Google’s (4.7x). Per task, the Nexla server stayed between 8,635 and 16,353 tokens, while Google’s ranged from 11,734 to 96,265. The ten-task totals were 106,679 and 501,022. With gpt-5.5, the Nexla server averaged 5,788 tokens over the nine tasks that executed, against 39,086 for Google’s over all ten (6.8x, uncached).

Figure 5 shows where the calls went. With both agents, every task that executed on the Nexla server took one call, straight to a data tool, with no discovery step. Over ten tasks, the agent on Google’s server made 47 calls with claude-opus-5 and 48 with gpt-5.5: 10 account listings each (one per task), 6 and 15 metadata lookups, and 31 and 23 GAQL searches. With claude-opus-5 that is 1.0 call per task against 4.7.

Figure 5 also shows tool-result bytes, the length of the result text handed to the model. With claude-opus-5 that was 93,058 bytes on the Nexla server against 263,651 on Google’s over ten tasks (2.8x). With gpt-5.5 it was 89,260 over the nine tasks that executed against 429,906 (4.8x).

So with claude-opus-5, bytes fell 2.8x but tokens fell 4.7x. The difference is turns. Every model turn re-sends the tool definitions and the conversation so far. A one-call task takes two turns, one to call the tool and one to answer. Each call that depends on an earlier result adds a turn, and that turn re-reads everything before it. A query tool makes the agent build the report; a task-specific tool has already built it.

HubSpot: the same counts and win rate for 16-33x fewer tokens

This section summarizes the HubSpot head-to-head; for more detail, read the full HubSpot benchmark.

We loaded a synthetic dataset of 1,130 deals (1,010 closed, 120 open) into a HubSpot portal. The agent got one open-ended question, phrased exactly as a user wrote it, typos included. It asked for an analysis of won and lost deals over the last 90 days, any trends in deal size, stage and other factors behind wins and losses, what else to consider, and what data was missing. The model was claude-opus-5, streaming, with a 32,000-token output cap, no system prompt and no scoring wrapper.

On one side was HubSpot’s CRM MCP server, with 24 general tools, including one that accepts SQL. On the other was a Nexla server with seven data tools, six that compute summaries over the full dataset on the server and one that returns raw rows, plus a describe_tool gateway the agent could also call.

Figure 6 compares both answers with ground truth, which we computed from the source dataset independently of both servers. Both answers gave 199 closed deals, 135 won and 64 lost, and a 67.8% win rate. Both gave the same average deal sizes: $101,898 for won deals and $129,279 for lost ones. The Nexla answer gave won and lost value to the dollar, $13,756,172 and $8,273,860. HubSpot’s answer rounded them to $13.76M and $8.27M. We count both as matches.

Figure 7 shows what each answer cost. Tokens here are provider-reported input plus output, summed over every turn, uncached. In the second run, the agent used 21,682 tokens on the Nexla server and 708,973 on HubSpot’s, a ratio of 32.7x. In the first run of the same comparison it was 51,867 against 832,739, or 16.1x. Across the two runs, the gap was 16-33x. Our HubSpot post gave these two runs as ranges, 21.7k-51.9k tokens for Nexla and 709k-833k for HubSpot’s server; paired run by run, they are the 32.7x and 16.1x shown here.

Almost all of that gap is input. HubSpot’s server re-sends about 39,000 tokens of tool schema on every turn; we measured its 24 tools at 39,183 tokens and 136,412 characters. On the Nexla server the whole first turn, tool definitions plus the question, was 3,796 input tokens, against 54,876 on HubSpot’s. Nexla’s tools also return finished summaries, so the agent has little left to assemble before it answers. Figure 14, in the schema section below, shows the input on each turn.

One part of the question shows the tool design at work. The question asked what data was missing, and the Nexla server has a data-quality tool that reports null counts on critical fields, computed on the server. That tool answers that part of the question directly. Both answers flagged the same core gaps: no stage-entry history, one owner on every deal, no activity data, and no competitor or discount fields.

Avoma: reading the calls the vendor’s server could not

We pointed Avoma’s MCP server and a Nexla call-analysis server, built on modeled call tables, at Nexla’s own production Avoma workspace. This is real data, so this post gives no counts, names or reps. claude-opus-5 was the agent and the judge, with a fresh conversation per cell. Ten questions ran against each server. Four were call-analysis questions, and the correctness results below cover that category. The error and schema figures cover all ten. Ground truth for the call questions was counted by a script, with no model in the loop, from the Nexla server’s own call table, read through that server’s call tool in weekly slices. Avoma’s server could not read those records. The question-by-question detail is in the full Avoma benchmark.

Figure 8 shows the call-analysis category: 0.50 for the Nexla server and 0.00 for Avoma’s. The Nexla server’s target-month call count and target-month outbound/inbound split both matched ground truth exactly. Its other two call answers scored 0.00: the prior-month count came from one whole-month read that the server cut off at its size cap, and it came back at about half the true figure, stated as final. The rep question timed out. On Avoma’s server the agent returned no call figure on any call question that produced a measurement, and each answer said it could not retrieve the call data. Avoma’s 0.00 is the mean of those three cells.

The cause is in Avoma’s own API client. It declares the frm and to fields of a call’s details as required strings, and dialer calls store both as null. Any page of meetings that holds a dialer call fails validation with Failed to list meetings: 2 validation errors for CallDetails before the agent sees any data. Smaller pages do not help, because any page that holds a dialer call fails.

The harness logged 25 errored tool calls on Avoma’s server, all on those three call questions (Figure 9). The fourth call question timed out on both servers, and the harness kept no tool calls for it. Of those, 21 were this validation error. The other 4 came from a usage-metrics tool that only covers the last 30 days. Across all ten tasks, the harness logged 1 errored tool call on the Nexla server.

The tool schema the harness sent on every turn was 15,078 characters for Avoma’s server and 4,637 for the Nexla server (3.3x), with tool descriptions clipped to 1,500 characters for both. The schema section below returns to this.

A vendor’s MCP server is a wrapper on the vendor’s API, and it carries that API’s edges with it. Here, two fields declared as required strings put every dialer call out of reach. The Nexla server reads modeled call tables instead, and on the target-month questions it returned the figures Avoma’s server could not.

Salesforce: checked against Salesforce’s own numbers

Salesforce is new in this post. The org is synthetic: a trial org we seeded with 500 accounts, 2,500 contacts, 1,500 leads and 2,000 opportunities, in the Asia/Kolkata timezone with one currency. The task set is ten ICP-planning questions: which industries win, where customers are billed, who the contacts are, and what sits in open pipeline. They fall into six categories. The comparator in the run was Salesforce’s official DX MCP server (@salesforce/mcp 0.30.15, data toolset). claude-opus-5 was the agent and the judge, the harness was mcp-bench, and each task ran once.

Nexla’s ICP-planner server has four object readers with a count mode, schema inspection, and a snapshot-and-query workspace: it copies complete reader output into a workspace and runs SQL there. It also carries generic gateway tools, one of which passes SOQL through to Salesforce; the SF10 answer came through that route. Ground truth is Salesforce’s own SOQL, run read-only through the Salesforce CLI and never through either MCP server. On Salesforce we report what it took to connect each server (next section) and how the Nexla server’s numbers held up against Salesforce’s own SOQL.

Before the run, we checked the benchmarked server against Salesforce directly. A script, with no model in the loop, took a full snapshot of all four objects through the Nexla server and computed 13 ICP aggregates inside it. We ran the same 13 aggregates as SOQL through the Salesforce CLI. All 13 matched exactly (Figure 10). They cover counts, sums and group-bys over accounts, leads and deals, by type, industry, billing country, lead status, lead source, deal outcome and stage; won deals by account industry, both through the deal’s account field and through a join to accounts; won deals in a one-quarter close-date window; and contacts per account type.

In the scored run, nine of ten answers were correct (judge score 0.8 or above) against SOQL ground truth, across structure, relationship, aggregation, totals and honesty at scale (Figure 11). The honesty-at-scale question asks for a count that spans all 2,500 contacts, where a silently truncated read gives a wrong number. The tenth, a won-deals date window, returned no answer in the scored run; one unscored re-run of that question returned 121 deals and $29,877,900, exactly the ground truth.

The server also says what it read (Figure 12). In a second pre-run probe, count mode and a full snapshot each returned exactly 500, 2,500, 1,500 and 2,000 rows for accounts, contacts, leads and opportunities, the same totals SOQL COUNT() reports. In the scored run, all eight snapshots the server returned were marked COMPLETE with source_exhausted: true. All four capped reads came back labelled PARTIAL, with truncated: true and the instruction “Do not compute whole-source aggregates from this partial response.” No answer used a partial read, and no Nexla answer matched any of the wrong numbers we had listed in advance for a truncated read.

An agent can only be careful about completeness if the server tells it what it got.

Getting to the first query

This section covers Salesforce only. It counts the steps for the person connecting an agent to a server that already exists. The Nexla server was built in MCP Studio beforehand, with its Salesforce connection configured once in Nexla, so its steps start at the agent’s MCP client config. Figure 13 sets out three paths: Nexla’s server, Salesforce’s DX server, which we used in the run, and Salesforce’s hosted server, as Salesforce documents it.

Nexla. The agent builder adds a streamable-HTTP URL and one bearer key to the MCP client config. In our run the server connected in about 1 s. There is no CLI, no local install, no OAuth app and no edition gate for the agent builder. The Salesforce credential stays in Nexla, not on the agent’s machine.

Salesforce DX (local). The DX server runs on the agent’s machine and uses the Salesforce CLI’s login. These are the steps we took:

• Install the Salesforce CLI.
• Log the CLI in to the org through the browser with sf org login web. Two of our attempts ended in AuthTimeoutError and one in PortInUseError on port 1717. The documented fallback, sf org login device, is not a command in CLI 2.153.5. Login succeeded once we completed the browser flow in our own terminal.
• Install @salesforce/mcp locally. Version 0.30.15 brought in 1,392 npm packages.
• Launch it as a local Node server with --orgs, --toolsets and --no-telemetry. Telemetry is on by default, and only that flag turns it off.
• Pass the org alias and an absolute working directory as tool arguments; the query tool requires both on every call. We put both in every prompt, so the agent did not have to discover them.

Salesforce hosted (platform/sobject-reads). Salesforce documents its hosted MCP server for Enterprise Edition and above, plus Developer Edition (Confirming Availability). Our trial org reports Base Edition, which is not on that list. On a supported edition the documented path has three steps:

• An admin activates the server in Setup.
• An admin creates an External Client App with OAuth authorization code plus PKCE, the scopes mcp_api and refresh_token, and JWT access tokens for named users.
• Each user logs in. Access tokens follow the user’s session timeout, typically 2 hours and configurable up to 12.

For Google Ads, the full Google Ads benchmark walks through the equivalent setup for Google’s own server.

The schema every turn

An agent works with a model in turns. On every turn, the client sends the model the server’s tool definitions, which we call the schema, plus the whole conversation so far. None of these runs used prompt caching, so every turn paid for the full schema again. A server’s schema is a per-turn fee, multiplied by the number of turns the agent takes.

Figure 14 shows what that fee looked like on HubSpot. The run sent no system prompt, and the user message was 45 words long. Even so, HubSpot’s first turn was 54,876 input tokens, before any data came back. The Nexla server’s first turn was 3,796 tokens, 14.5x smaller. HubSpot’s input then grew with the conversation and reached 78,190 tokens on its last turn. Over the whole question, HubSpot’s input came to 700,221 tokens against 13,251 for the Nexla server, all uncached.

Figure 15 puts the schemas side by side. We measured the schema of HubSpot’s CRM MCP at 39,183 tokens (136,412 characters across 24 tools), so its server re-sends about 39,000 tokens on every turn. In run 2 the schema was at least as large, since the first turn alone was 54,876 tokens. On the Nexla HubSpot server the first turn of that run, tool definitions plus the same question, was 3,796 tokens, 14.5x less. On Avoma, our runner sent 15,078 characters of schema per turn for Avoma’s server and 4,637 for the Nexla server, 3.3x less. Both Avoma figures were measured with each tool description clipped to 1,500 characters, the same clip for both servers.

The difference comes from what the tools are. HubSpot’s server ships a general catalog of 24 tools, including one that accepts SQL, and Avoma’s server has 14 tools. A catalog lets the agent reach any object and work out the rest. The Nexla HubSpot server has seven data tools plus a describe_tool gateway, and the Nexla Avoma server has eight tools, all built around the questions they were made to answer. Because the schema is re-read on every turn, we think it should carry the question rather than a catalog, which is the argument behind the tool description is the context.

Creating the benchmark

A benchmark like this has three parts, and all three have to be right: the world (the systems and their data), the tasks, and the checks. On every system the rule was the same. We held the model, the question and the data fixed and changed only the server, so whatever moved can be traced to the server. We described the framework in how we benchmark MCP servers. The HubSpot and Salesforce data in this post is synthetic by design, which is what lets us share it.

The systems and the data

• Google Ads: Nexla’s own live account, a single low-volume account, read over a rolling 30-day window. This post gives no account IDs, names or spend.
• HubSpot: a synthetic dataset of 1,130 deals (1,010 closed, 120 open), loaded into a HubSpot portal. An answer key documents the effects planted in it.
• Avoma: Nexla’s own production workspace. The data is real, so this post gives nothing that identifies people or volumes.
• Salesforce: a synthetic org seeded with 500 accounts, 2,500 contacts, 1,500 leads and 2,000 opportunities, timezone Asia/Kolkata and one currency. The org is a Base Edition trial.

On each system the vendor’s own MCP server ran against a Nexla server built in MCP Studio for that system’s questions. The vendor servers were Google’s google-ads-mcp, HubSpot’s CRM MCP, Avoma’s MCP server and Salesforce’s DX MCP server (@salesforce/mcp 0.30.15). Figure 16 summarizes each comparison: data, servers and tasks.

The tasks

Google Ads had 10 tasks in five categories: structure 2, relationship 2, aggregation 4, totals 1 and point in time 1. No prompt names a tool, a field or a query language. Where a count could be read two ways, the prompt says which reading it wants (“at least one impression in the last 30 days”). Seven prompts state the 30-day window, one names a specific day, and the two relationship prompts state neither.

HubSpot had one open-ended revenue question in a user’s own words, typos included: won and lost deals over the last 90 days, trends in deal size and stage, and missing data. Of Avoma‘s ten questions, the four reported here are call analysis: dialer-call counts for a target month and for the month before it (the prior month), the target month’s outbound and inbound split, and which reps made calls.

Salesforce had ten ICP-planning questions in six categories: structure 2, relationship 2, aggregation 3, totals 1, point in time 1 and honesty at scale 1. They are short, in a person’s voice, with absolute dates only, and carry a membership qualifier wherever a count could be read two ways: Type exactly Customer; accounts, not leads; open means any stage other than Closed Won or Closed Lost; closed deals only for win rate; every contact, not a sample. The date question states the org’s timezone. Every prompt ends with “If anything comes back truncated or a tool fails, tell me instead of estimating.” plus the org alias and working directory that the DX server requires.

Before the Salesforce run we wrote down each trap and the wrong answer it produces:

• The industry that leads on won revenue is not the one that leads on won-deal count.
• Counting open deals in the win-rate denominator gives 26.5% and 22.7% instead of 63.8% and 54.7%.
• Won deals fall on both boundary days of the date window, so an off-by-one window gives 118, 120 or 122 instead of 121.
• The 2,500 contacts exceed a 1,000-row or 2,000-row read, so a silently truncated read gives 93 or 206 VP contacts instead of 252.

No question asked for an unfiltered object total, because the Nexla tool descriptions already state those totals. We checked the totals separately (Figure 12).

Ground truth

• Google Ads: the Google Ads API (GAQL, DURING LAST_30_DAYS AND metrics.impressions > 0). We confirmed it against all six Nexla tools: 10 of 10 answers were identical, and every campaign and ad group matched on impressions, clicks and cost. A pre-flight gate confirmed, for each task and server, that the expected answer could be derived from the exact text the harness hands the model (20 of 20).
• HubSpot: computed from the synthetic source dataset, independently of both servers.
• Avoma: the call figures were counted by a script, with no model in the loop, from the call table behind the Nexla server, read through that server’s own call tool in weekly slices so that no read hit its size cap. Avoma’s own server could not read those records.
• Salesforce: SOQL run read-only through the Salesforce CLI, never through either MCP server. A second pass recomputed every expected answer in Python from raw exports of every row, without reusing the derivation SOQL; each export was matched to SELECT COUNT() and to the same count with ALL ROWS. A read-only drift check before the run re-queried the object counts, the total opportunity amount and every expected value. After the run, the counts, latest modification times and amount total were queried again and matched the values recorded at derivation.

Grading

On Google Ads and Salesforce, claude-opus-5 judged each answer on a 0-1 rubric: 1.0 perfect; 0.8-0.9 minor issues; 0.5-0.7 partial; 0.2-0.4 largely wrong; 0.0-0.1 wrong or no answer. The judge sees the prompt, the expected answer, the final answer, and the names of the tools called with an ok/error flag. It does not see tool outputs. On Salesforce an answer counts as correct at 0.8 or above, and we also checked every trace against the wrong answers listed in advance.

On Avoma the same model judged on its own rubric (1.0 exact; 0.5-0.9 minor imprecision; 0.1-0.4 attempted but wrong; 0.0 wrong or could not retrieve) and saw only the task, the expected answer and the final answer. A failed judge call left the cell unscored rather than scoring it zero. HubSpot had no judge: we compared the figures in each answer with ground truth directly.

On Google Ads we show both views of an infrastructure failure. One gpt-5.5 task on the Nexla server never executed because the OpenAI request did not return, so that cell is reported as measured (0.90) and over the nine tasks that executed (1.00). One judge call also failed with HTTP 529 (overloaded) on a recorded claude-opus-5 answer from the Nexla server; we re-judged that answer with the same prompt and it scored 1.0, without re-running the agent.

Harness and models

Google Ads and Salesforce ran in mcp-bench, where each cell is one server, one agent, one task and one trial. If an agent there asks a clarifying question before its first tool call, a small model (claude-haiku-4-5) replies from a fixed note about the dataset. HubSpot and Avoma ran in standalone runner scripts with the same loop: list the server’s tools, give them to the model, run each tool call, and repeat until the model answers.

claude-opus-5 was the agent on all four systems, and gpt-5.5 also ran on Google Ads. claude-opus-5 was the judge wherever we used one. Run caps:

• Google Ads: 15 iterations, 180 s per task, 5 tasks at a time, output caps of 20,000 tokens (Claude) and 32,000 (OpenAI).
• HubSpot: up to 14 model turns, 32,000-token output cap.
• Avoma: up to 18 model turns, 16,000-token output cap.
• Salesforce: 15 turns, 180 s per task, 90 s per tool call.

No run sent a system prompt or requested prompt caching. The HubSpot and Avoma runners clipped each tool description to 1,500 characters for both servers. Tokens are the provider-reported input plus output, summed over every turn.

Reproduce it

Two of the four datasets are synthetic, so we can share them.

• HubSpot: the synthetic CSV of 1,130 deals, the answer key with its planted effects, the question, and the comparison rule: each figure in an answer is checked against ground truth.
• Salesforce: the ten prompts with their expected outputs, tolerance notes and truncation signatures; the ground-truth SOQL; and the seed volumes (500 accounts, 2,500 contacts, 1,500 leads, 2,000 opportunities). TODO: confirm the org-seeding script can be published before the trial org expires.
• Harness: mcp-bench, run as mcp-bench run --env claude_api --server <server> --data-system salesforce. TODO: link the public repository.

The Google Ads and Avoma data is real business data, so we do not publish it. The Google Ads task templates can be shared with identifiers removed. We can also share the rows behind every figure in this post as one JSON file, with internal paths removed, so readers can redo the arithmetic. TODO: link the figure data file.

Frequently asked questions

What is an MCP server benchmark, and what did this one measure?

An MCP server benchmark holds the model, the questions and the data fixed and changes only the MCP server. Here, Nexla’s task-specific servers ran against the vendors’ own servers on Google Ads, HubSpot and Avoma, and on Salesforce we checked the Nexla server’s numbers against Salesforce’s own SOQL. We report correctness against ground truth, tool calls and tokens per task (Google Ads), tokens per question (HubSpot), schema re-sent per turn (HubSpot, Avoma), logged tool errors (Avoma) and the steps to connect an agent (Salesforce).

Why did the task-specific servers use fewer tokens on Google Ads and HubSpot?

Every turn re-sends the tool schema and the conversation so far. On Google Ads, the Nexla server is bound to one account and to modeled performance tables, so with claude-opus-5 the agent made 1.0 tool call per task instead of 4.7 and used 10,668 tokens instead of 50,102 (4.7x, uncached). On HubSpot, the first turn alone, tool definitions plus the question, was 3,796 input tokens on the Nexla server against 54,876 on HubSpot’s, and the question took 21,682 tokens against 708,973, or 32.7x (16.1x in the first run of the same comparison, so 16-33x), uncached.

Were the task-specific server’s answers correct?

On Google Ads it scored 1.00 with claude-opus-5 (Google’s server 0.975, its only shortfall on T4), and Google Ads API ground truth matched all six Nexla tools on 10 of 10 answers. On HubSpot it matched ground truth on closed deals, won/lost split and win rate, as HubSpot’s server did. On Avoma it scored 0.50 on call analysis against 0.00, with the target-month call count and outbound/inbound split exact. On Salesforce, 13 of 13 aggregates matched SOQL, all four object totals were exact, and 9 of 10 ICP questions were correct in the scored run, with the tenth exact on an unscored re-run.

What does it take to connect an agent to a Salesforce MCP server?

Nexla’s server needs a streamable-HTTP URL and one bearer key, and it connected in about 1 second, with no CLI, local install or OAuth app for the agent builder. Salesforce’s DX MCP server needs the Salesforce CLI, a browser login, a local Node server launched with flags, and the org alias and a working directory on every query call. Salesforce’s hosted MCP server is documented for Enterprise Edition and above, plus Developer Edition; it needs admin activation, an External Client App with OAuth and PKCE, and per-user logins, with access tokens that typically last 2 hours (configurable up to 12).

Can I reproduce these results?

The synthetic parts, yes. The HubSpot dataset (1,130 synthetic deals) with its answer key, and the Salesforce task set with its SOQL ground truth, can be shared. The harness is mcp-bench (TODO: public repository link before publishing). The Google Ads and Avoma runs used real business data, so we do not publish those datasets.

Which models ran the benchmark?

claude-opus-5 was the agent on all four systems, and gpt-5.5 also ran on Google Ads. claude-opus-5 was the judge wherever a judge was used: Google Ads, Avoma and Salesforce. No run sent a system prompt or requested prompt caching.

Each Nexla server in this post was built in MCP Studio by describing the questions it had to answer. You describe the questions your agents need answered, MCP Studio builds a governed, task-specific server, and an agent connects to it with a URL and a key. Start with MCP Studio, or read a short introduction to how it works.