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

Nexla's task-specific MCP servers used 4.7x fewer tokens per task on Google Ads and 32.7x fewer tokens on a HubSpot deal-analysis question than the vendors' own MCP servers, according to a Nexla benchmark that held claude-opus-5, the questions and the data fixed across Google Ads, HubSpot, Avoma and Salesforce. On HubSpot, both servers returned identical results — 199 closed deals, 135 won, 64 lost and a 67.8% win rate — but Nexla's server used 21,682 tokens against 708,973 uncached for HubSpot's 24-tool CRM MCP, which re-sends about 39,000 tokens of tool schema each turn. On Avoma, Nexla's server logged 1 errored tool call over 10 tasks versus 25 for Avoma's own server and scored 0.50 versus 0.00 on call analysis, while on Salesforce its aggregates matched Salesforce's own SOQL on 13 of 13 checks.

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. Figure 1. Fewer tokens, fewer tool errors, matching numbers: Nexla's task-specific server on four systems. Headline measure per system, against the vendor's own MCP server or, on Salesforce, Salesforce's own SOQL. Nexla Vendor's own server Google Ads4.7xfewer tokens per task, claude-opus-5 10,668 50,102 1.0 vs 4.7 tool calls per task HubSpot32.7xfewer tokens for one question 21,682 708,973 16.1x fewer in the first run Avoma1 vs 25errored tool calls over 10 tasks 1 25 Call-analysis score 0.50 vs 0.00 Salesforce13 of 13aggregates matched SOQL all four object totals exact Show the data System Measure Nexla Vendor's own server Ratio Google Ads Tokens per task, claude-opus-5 10,668 50,102 4.7x Google Ads Tool calls per task, claude-opus-5 1.0 4.7 4.7x HubSpot Tokens for one question, run 2 21,682 708,973 32.7x HubSpot Tokens for one question, run 1 51,867 832,739 16.1x Avoma Errored tool calls, 10 tasks 1 25 Avoma Call-analysis correctness, 0-1 0.50 0.00 Salesforce ICP aggregates matching Salesforce's own SOQL 13 of 13 Salesforce Object totals exact All four 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. Figure 2. Nexla ahead or level on every vendor comparison shown; 13 of 13 Salesforce checks matched SOQL. Nexla's task-specific MCP server against each vendor's own server, or Salesforce's own SOQL; claude-opus-5 as the agent. Measure Nexla Vendor Result Google Ads vs Google's google-ads-mcp Tokens per task 10,668 50,102 4.7x fewer Tool calls per task 1.0 4.7 4.7x fewer Correctness 0-1 1.00 0.975 ✓ higher HubSpot vs HubSpot's CRM MCP, one question Closed deals · win rate 199 · 67.8% 199 · 67.8% ✓ both correct Tokens, run 2 21,682 708,973 32.7x fewer Tokens, run 1 51,867 832,739 16.1x fewer Avoma vs Avoma's MCP server Call-analysis score 0-1 0.50 0.00 ✓ higher Errored tool calls 1 25 ✓ fewer Schema per turn chars 4,637 15,078 3.3x smaller Salesforce vs Salesforce's own SOQL ICP aggregates matched 13 of 13 ✓ exact Object totals matched 4 of 4 ✓ exact ICP questions correct 9 of 10 ✓ vs SOQL Show the data Measure Nexla Vendor's server Result Google Ads · vs Google's google-ads-mcp Correctness, claude-opus-5 0-1 1.00 0.975 higher Correctness, gpt-5.5 0-1 0.90 1.00 over the 9 tasks that executed 0.77 higher Tool calls per task, claude-opus-5 1.0 4.7 4.7x fewer Tokens per task, claude-opus-5, uncached 10,668 50,102 4.7x fewer Tokens per task, gpt-5.5, tasks that executed, uncached 5,788 39,086 6.8x fewer Tool-result bytes, 10 tasks, claude-opus-5 93,058 263,651 2.8x fewer HubSpot · vs HubSpot's CRM MCP · one question, claude-opus-5 Closed deals; won, lost; win rate 199; 135, 64; 67.8% 199; 135, 64; 67.8% both match ground truth Total tokens, run 2, uncached 21,682 708,973 32.7x fewer Total tokens, run 1, uncached 51,867 832,739 16.1x fewer Input tokens on the first turn, run 2 3,796 54,876 14.5x fewer Avoma · vs Avoma's MCP server · claude-opus-5 Call-analysis correctness 0-1 0.50 0.00 higher Errored tool calls, all 10 tasks 1 25 fewer Tool schema per turn characters 4,637 15,078 3.3x smaller Salesforce · results vs Salesforce's own SOQL; setup vs Salesforce's DX MCP server · claude-opus-5 ICP aggregates matching SOQL 13 of 13 exact Object totals matching SOQL COUNT 4 of 4 500; 2,500; 1,500; 2,000 exact ICP questions correct, scored run 9 of 10 judged against SOQL Snapshots labelled COMPLETE, scored run 8 of 8 Capped reads labelled PARTIAL, scored run 4 of 4 To connect an agent One URL and one key; nothing installed Salesforce CLI, browser OAuth login, local Node server 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 3. Google Ads: the Nexla server scored 1.00 on every task that executed, with both agents. Judge score per task 0–1 ; a solid cell is a perfect 1.00. claude-opus-5Mean Nexla1.00 Google’s server0.975 0.75 T1T2T3T4T5T6T7T8T9T10 gpt-5.5Mean Nexla 1.00 on 9 0.90 Google’s server0.77 0.100.500.10 T1T2T3T4T5T6T7T8T9T10 Nexla Google’s server Did not execute Show the data claude-opus-5 gpt-5.5 Task Category Nexla Google’s server Nexla Google’s server T1 structure 1.00 1.00 0.00 did not execute 0.10 T2 structure 1.00 1.00 1.00 1.00 T3 relationship 1.00 1.00 1.00 1.00 T4 relationship 1.00 0.75 1.00 0.50 T5 aggregation 1.00 1.00 1.00 1.00 T6 aggregation 1.00 1.00 1.00 1.00 T7 aggregation 1.00 1.00 1.00 1.00 T8 aggregation 1.00 1.00 1.00 1.00 T9 totals 1.00 1.00 1.00 0.10 T10 point in time 1.00 1.00 1.00 1.00 Mean 1.00 0.975 0.90 1.00 over the 9 tasks that executed 0.77 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 4. Google Ads: the Nexla server used 4.7x to 6.8x fewer tokens per task on average. Mean input plus output tokens per task that executed, uncached. Lower is better. claude-opus-54.7x fewer Nexla10,668 Google’s server50,102 gpt-5.56.8x fewer Nexla5,788 Google’s server39,086 Show the data Mean tokens per task, uncached Agent Nexla Google’s server Fewer with Nexla claude-opus-5 10,668 50,102 4.7x gpt-5.5 5,788 9 tasks executed 39,086 6.8x 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 . Figure 5. Google Ads: the Nexla server took one call per executed task and returned 2.8x to 4.8x fewer bytes. Tool calls by type, and tool-result bytes returned to the model, over 10 tasks per agent. Nexla Google’s server Discovery call claude-opus-52.8x fewertool-result bytes on Nexla93,058 vs 263,651 gpt-5.54.8x fewertool-result bytes on Nexla89,260 vs 429,906 Show the data Agent Server Account listing discovery Resource metadata discovery GAQL search data Nexla data tools Total calls Tool-result bytes claude-opus-5 Nexla – – – 10 10 93,058 claude-opus-5 Google’s server 10 6 31 – 47 263,651 2.8x Nexla gpt-5.5 Nexla – – – 9 9 89,260 9 tasks executed gpt-5.5 Google’s server 10 15 23 – 48 429,906 4.8x Nexla 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 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 6. HubSpot: both answers gave 199 closed deals and a 67.8% win rate, matching ground truth. Closed deals in the last 90 days, second run. ✓ = the answer matched ground truth. Measure Ground truth Nexla HubSpot's CRM MCP Closed deals 199 ✓ ✓ Won / lost 135 / 64 ✓ ✓ Win rate 67.8% ✓ ✓ Won value $13,756,172 ✓ $13.76M✓ Lost value $8,273,860 ✓ $8.27M✓ Avg won deal $101,898 ✓ ✓ Avg lost deal $129,279 ✓ ✓ Show the data Measure second run Ground truth Nexla HubSpot's CRM MCP Closed deals, last 90 days 199 199 199 Won / lost 135 / 64 135 / 64 135 / 64 Win rate 67.8% 67.8% 67.8% Won value $13,756,172 $13,756,172 $13.76M Lost value $8,273,860 $8,273,860 $8.27M Average won deal $101,898 $101,898 $101,898 Average lost deal $129,279 $129,279 $129,279 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. Figure 7. HubSpot: the Nexla server used 16-33x fewer tokens for the same question. Total tokens to answer one question, uncached, in each of two runs. Run 116.1x fewer Nexla51,867HubSpot’s server832,739 Run 232.7x fewer Nexla21,682HubSpot’s server708,973 Show the data Run Nexla tokens HubSpot’s CRM MCP tokens HubSpot ÷ Nexla Run 1 51,867 832,739 16.1x Run 2 21,682 708,973 32.7x 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. Figure 8. Avoma: the Nexla server scored 0.50 on call analysis, Avoma's server 0.00. Correctness on a 0–1 scale, and each server's result on the two target-month questions. Call-analysis correctness Nexla0.50 Avoma's MCP server0.00 Target-month questions Dialer-call count✓ Exact✕ No answer Outbound/inbound split✓ Exact✕ No answer Nexla Avoma's MCP server Show the data Measure Nexla Avoma's MCP server Call-analysis correctness 0–1 0.50 0.00 Call-analysis tasks scored 4 3 measured Target-month dialer-call count Exact 1.00 No answer 0.00 Target-month outbound/inbound split Exact 1.00 No answer 0.00 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. Figure 9. Avoma: 1 errored tool call on the Nexla server, 25 on Avoma's. Tool calls the harness logged as errored, across all 10 tasks on each 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. Figure 10. Salesforce: all 13 Nexla aggregates matched Salesforce’s own SOQL exactly. Counts, sums and group-bys from the Nexla server, each compared with the same aggregate run as SOQL. Checks13 of 13matched SOQL exactly Result rows176all identical to SOQL Accounts✓✓✓✓ Leads✓✓✓ Deals✓✓✓✓✓ Contacts✓ Show the data Object Check Result rows Same as SOQL SOQL Accounts Accounts by type 10 Yes, exact SELECT Type, COUNT Id FROM Account GROUP BY Type Accounts Accounts by industry 30 Yes, exact SELECT Industry, COUNT Id FROM Account GROUP BY Industry Accounts Customer accounts by billing country 9 Yes, exact SELECT BillingCountry, COUNT Id FROM Account WHERE Type='Customer' GROUP BY BillingCountry Accounts Account revenue and employee totals 1 Yes, exact SELECT SUM AnnualRevenue , SUM NumberOfEmployees FROM Account Leads Leads by status 4 Yes, exact SELECT Status, COUNT Id FROM Lead GROUP BY Status Leads Leads by source 11 Yes, exact SELECT LeadSource, COUNT Id FROM Lead GROUP BY LeadSource Leads US leads by industry 31 Yes, exact SELECT Industry, COUNT Id FROM Lead WHERE Country='United States' GROUP BY Industry Deals Deals won, lost and open 3 Yes, exact SELECT IsClosed, IsWon, COUNT Id , SUM Amount FROM Opportunity GROUP BY IsClosed, IsWon Deals Deals by stage 6 Yes, exact SELECT StageName, COUNT Id , SUM Amount FROM Opportunity GROUP BY StageName Deals Won by account industry, deal field 30 Yes, exact SELECT Account.Industry, COUNT Id , SUM Amount FROM Opportunity WHERE IsWon = true GROUP BY Account.Industry Deals Won by account industry, join 30 Yes, exact SELECT Account.Industry, COUNT Id , SUM Amount FROM Opportunity WHERE IsWon = true GROUP BY Account.Industry Deals Won deals closing in one quarter 1 Yes, exact SELECT COUNT Id , SUM Amount FROM Opportunity WHERE IsWon = true AND CloseDate = <quarter start AND CloseDate <= <quarter end Contacts Contacts per account type, join 10 Yes, exact SELECT Account.Type, COUNT Id FROM Contact GROUP BY Account.Type All 13 checks 176 13 of 13 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. Figure 11. Salesforce: the Nexla server answered 9 of 10 ICP questions correctly. Scored against SOQL ground truth; correct means a judge score of 0.8 or above. Scored run9 of 10answers correctall nine scored 1.00 Unscored re-runExacton the point-in-time question121 deals, $29,877,900 Correct answers in the scored run, by category Structure Relationship Aggregation Totals Honesty at scale Point in timeno answer Show the data Task Category Difficulty Question paraphrased Scored run Judge score Unscored re-run SF01 structure easy Customer accounts billed outside the United States count Correct 1.00 Not re-run SF02 structure easy Accounts in the Utilities industry, with Type list Correct 1.00 Not re-run SF03 relationship easy Contacts at one named account, with titles list Correct 1.00 Not re-run SF04 relationship medium A named deal’s account, its industry and employee count Correct 1.00 Not re-run SF05 aggregation hard Closed Won by account industry: top by revenue and top by count Correct 1.00 Not re-run SF06 aggregation medium Win rate, New vs Existing Business, closed deals only Correct 1.00 Not re-run SF07 aggregation hard Top two accounts by Closed Won revenue Correct 1.00 Not re-run SF08 totals medium Total Closed Won revenue and open pipeline, with counts Correct 1.00 Not re-run SF09 point in time medium Deals won with a close date inside a one-quarter window, both ends inclusive, count and amount No answer returned 0.00 121 deals, $29,877,900 exact SF10 honesty at scale hard Contacts with ‘VP’ in title, and the top account industry among them Correct 1.00 Not re-run 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. Figure 12. Salesforce: all four object totals were exact; every scored-run capped read was labelled PARTIAL. Nexla server row counts against SOQL COUNT , and the label on each scored-run snapshot and capped read. Object totals4 of 4exact against SOQL COUNT count mode and full snapshot 8 snapshotsCOMPLETEused in 8 answerssource exhausted: true 4 capped readsPARTIALused in no answertruncated: true Object SOQL Nexla Account 500 ✓ 500 Contact 2,500 ✓ 2,500 Lead 1,500 ✓ 1,500 Opportunity 2,000 ✓ 2,000 Show the data Object totals Object SOQL COUNT Nexla count mode Nexla full snapshot Rows in each scored-run snapshot Account 500 500 500 500 5 snapshots Contact 2,500 2,500 2,500 2,500 1 snapshot Lead 1,500 1,500 1,500 not needed Opportunity deals 2,000 2,000 2,000 2,000 5 snapshots Labels in the scored run Read Task Rows Label Used in an answer 8 snapshots SF01–SF08 every row COMPLETE, source exhausted: true Yes, all 8 Deals read SF04 500 of 2,000 PARTIAL, truncated: true No Deals sample SF06 5 of 2,000 PARTIAL, truncated: true No Deals read SF09 500 of 2,000 PARTIAL, truncated: true No Contacts read SF10 1,000 of 2,500 PARTIAL, truncated: true No 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. Figure 13. Salesforce: connecting an agent took 1 step on the Nexla server and 5 on Salesforce’s DX server. Steps for the person connecting an agent once the server exists. Hosted server shown as Salesforce documents it. Nexla server1 step 1Add URL and one key Salesforce DX local 5 steps 1Install Salesforce CLI 2Log in via browser 3Install server locally 4Launch with flags 5Alias + dir per query call Salesforce hosted documented 3 steps 1Admin activates server 2Admin creates OAuth app 3Each user logs in Show the data Path Step What Who does it Detail Nexla server 1 Add the streamable-HTTP URL and one bearer key to the MCP client config agent builder connected in about 1 s Salesforce DX MCP local 1 Install the Salesforce CLI agent builder CLI 2.153.5 Salesforce DX MCP local 2 Log the CLI in to the org through the browser: sf org login web a person at a browser – Salesforce DX MCP local 3 Install the server locally: @salesforce/mcp 0.30.15 agent builder 1,392 npm packages Salesforce DX MCP local 4 Launch a local Node server with --orgs, --toolsets and --no-telemetry agent builder – Salesforce DX MCP local 5 Pass the org alias and an absolute working directory as tool arguments on every query call agent or prompt – Salesforce hosted MCP documented 1 Admin activates the server platform/sobject-reads in Setup org admin – Salesforce hosted MCP documented 2 Admin creates an External Client App: OAuth authorization code with PKCE org admin – Salesforce hosted MCP documented 3 Each user logs in each user – 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. 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 14. HubSpot: 13,251 input tokens over 2 turns on the Nexla server, 700,221 over 10 on HubSpot's. Input tokens sent to the model on each turn, tool schema included. HubSpot run 2, uncached. Input tokens on each model turn, HubSpot run 2, uncached Model turn Nexla HubSpot's CRM MCP Turn 1 3,796 54,876 Turn 2 9,455 60,515 Turn 3 – 62,865 Turn 4 – 70,297 Turn 5 – 71,629 Turn 6 – 73,175 Turn 7 – 75,038 Turn 8 – 76,405 Turn 9 – 77,231 Turn 10 – 78,190 Total input, all turns 13,251 700,221 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. Figure 15. Tool schema: the Nexla servers cost the model 14.5x less on HubSpot and 3.3x less on Avoma. What each server costs the model before any data: HubSpot in first-turn input tokens tool definitions plus the question , Avoma in characters of tool schema. HubSpot14.5x lessInput tokens, first turn Avoma3.3x lessSchema characters per turn Nexla Vendor's own server Show the data Measure Nexla Vendor's server Nexla vs vendor HubSpot: input tokens, first turn of run 2 3,796 54,876 14.5x less Avoma: characters of tool schema per turn 4,637 15,078 3.3x less 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. Figure 16. What we tested: four systems, each vendor's own MCP server against a Nexla server. Each comparison held the model, tasks and data fixed and changed only the server. Salesforce's DX MCP server @salesforce/mcp 0.30.15, data toolset Nexla server 6 data tools bound to one account, plus 5 gateway tools 7 data tools plus a describe tool gateway Call-analysis server, 8 tools ICP-planner server, 13 tools Agent claude-opus-5; gpt-5.5 claude-opus-5 claude-opus-5 claude-opus-5 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. Nexla and Snowflake®: Connecting 1,000+ Enterprise Systems to Cortex Agents and the AI Data Cloud Nexla extends the Snowflake AI Data Cloud to more of the enterprise, with connectivity to 1,000+ systems, delivered as data pipelines, zero-copy access, and task-specific MCP servers for Snowflake agents. How Nexla’s Task-Specific MCP Server Outperforms Avoma’s MCP Server We benchmarked Avoma’s own MCP server against a task-specific Nexla MCP server on call analysis. Nexla returned exact call counts and direction splits, logged 1 errored tool call to Avoma’s 25, and installed with a service key instead of OAuth.