End-to-end evidence · Run 5b · Run 5 follow-up · 20 August 2026

Isolate the variable: same client, same logical task, individual calls versus one semantic batch call

Run 5b is a controlled follow-up to Run 5. It reuses the exact Run 5 HttpClient and manual JSON-RPC MCP transport, unchanged, against both endpoints, so the client itself cannot explain any difference between them. The only thing that changes is the shape of the request: the conventional path sends batchSize individual transfer_funds MCP calls, while Foundgine sends one transfer_funds_batch MCP call carrying the same batchSize logical transfers. The matrix repeats Run 5's four workload tiers (10, 100, 1,000, 10,000 customers) and four concurrency levels (8, 16, 32, 64), with 5 warmups and 30 measured runs per cell.

Inspect the matrix evidence →Read Run 5 first

Same client. Different request shape.

Both paths use the same HttpClient

The transport is deliberately held constant so the comparison isolates one variable: how many MCP calls carry the same logical work.

ConventionalSame client → batchSize individual transfer_funds MCP callsOne MCP round-trip per logical transfer. At concurrency 8 with batch size 8, that is 64 calls for one task.

FoundgineSame client → one transfer_funds_batch MCP callOne MCP round-trip carries every logical transfer in the batch, regardless of concurrency.

Why this run existsRun 5 found that the Foundgine path hit a scalability cliff at concurrency 64. Before treating that as a property of the execution architecture, the benchmark needed to rule out a simpler explanation: an artifact of how many separate requests each path was making at the transport layer. Holding the client fixed and only changing individual-call versus batch-call shape isolates that variable directly.

What was comparedThe same Run 5 HttpClient against both endpoints: batchSize individual transfer_funds MCP calls versus one transfer_funds_batch MCP call, at every workload/concurrency cell in the Run 5 matrix.

What it meansThis closes the loop on Run 5's open question. The C64 regression seen in Run 5 was tied to the specific endpoint under test, not to batching or semantic execution generally. When the same client sends one semantic batch call instead of many individual calls, throughput and latency both improve consistently across the full matrix, with no concurrency cliff.

Published finding

What the evidence says

With the same client on both sides, Foundgine's single batch call outperformed the conventional path's individual calls at every workload and every concurrency level tested, including C64 — no cliff appeared. Averaged across all 16 workload/concurrency cells, Foundgine sustained about 2.95× the conventional path's RPS (range 2.22×–3.78×) and 3.7×–6.4× lower average wall time. At 10,000 customers/C64 specifically, Foundgine averaged about 4,291 RPS versus 1,571 RPS for the conventional path, with 74 ms versus 311 ms average wall time. Tool calls were 8 → 1 per task in every cell, since batch size is fixed at 8 independent of concurrency. Foundgine's total task payload was 1.3×–1.8× larger than the conventional path's despite the 8× fewer calls — the win comes from eliminating round-trips, not from sending fewer bytes. Zero failures across all 960 published samples.

Key measurements

toolCalls8 → 1 per task

rps~2.22×–3.78× higher

c6410k/C64: 1,571 vs 4,291 RPS

wallC64311 vs 74 ms

payload1.3×–1.8× more bytes

failures0 published

How to use this run

Read the finding first, then inspect the exact evidence.

This page tells the story of the experiment. The benchmark explorer contains the interactive workload/concurrency matrix and selected-cell comparison for Run 5b, alongside Runs 2, 4 and 5.

The benchmark distinguishes measured timings and tool calls from its estimated context-load heuristic. Payload size (bytes sent and received) is measured directly, not estimated.

← Benchmark landing page · Run 5 · How it works · Architecture