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.