Foundgine
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 compares different request shapes, so raw request latency alone cannot establish a semantic-execution scalability cliff. The follow-up holds the client constant and isolates individual-call versus batch-call shape directly. 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 controlled follow-up shows the batch-call advantage with the client held constant. Its throughput is now calculated at the concurrent-iteration boundary using the slowest worker, matching the runner's methodology and avoiding optimistic per-task RPS averaging.
Published finding
What the evidence says

With the same client on both sides and throughput reconstructed using the runner's slowest-worker-per-iteration method, Foundgine's single batch call outperformed the conventional path's individual calls in every one of the 16 published cells. The corrected advantage ranges from about 2.19× to 3.79× RPS (mean about 2.86×). At 10,000 customers/C64, Foundgine averaged about 3,570 logical transfers/s versus 1,582, with average task wall time about 92 ms versus 308 ms. Tool calls were 8 → 1 per task and the published samples contain zero failures.

Key measurements
toolCalls8 → 1 per task
rps~2.19×–3.79× higher (mean ~2.86×)
c6410k/C64: 1,582 vs 3,570 logical transfers/s
wallC64308 vs 92 ms/task
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