End-to-end evidence · Run 5 · 18 August 2026

Test the capability boundary: high-assurance TransferFunds through the same MCP protocol

Run 5 asks a different architectural question. The operation is a high-assurance TransferFunds capability with tenant isolation, ownership, authorization revalidation, frozen-account checks, available-funds and daily-limit checks, idempotency, audit evidence and an atomic transaction. Both paths expose the same capability through MCP. The conventional path uses a purpose-built MCP tool backed by EF Core; the Foundgine path uses MCP + Foundgine High-Assurance Postgres. MCP is the common agent-facing protocol — the experiment changes what happens behind MCP.

Inspect the matrix evidence →All five runs

Same protocol. Different execution boundary.

Both paths use MCP

MCP is deliberately held constant. The experiment compares the implementation behind the agent-facing protocol.

ConventionalAI agent → MCP → purpose-built tool → EF Core → PostgreSQLA handcrafted MCP operation contains the application-specific transfer implementation.

FoundgineAI agent → MCP → semantic capability → Foundgine → PostgreSQLThe capability is exposed semantically while the execution boundary owns planning and controlled execution.

Why this run existsThis is the test of whether semantic execution is useful beyond graph reads. The interesting comparison is not 'which endpoint is faster?' but whether an agent can consume a business capability without every capability becoming another handcrafted endpoint and orchestration contract.

What was comparedMCP + conventional EF Core implementation versus MCP + Foundgine High-Assurance Postgres.

What it meansSemantic execution can carry a richer high-assurance capability without increasing the agent tool-call count, and the Foundgine UNNEST batch path sustains substantially higher throughput than the purpose-built conventional path at every workload and concurrency level tested. The trade-off is per-transfer latency, which rises under batching as expected; that is a tuning question (batch size, concurrency shape), not a scalability cliff.

Published finding

What the evidence says

Both paths issue one MCP tool call per flow, but that call does different amounts of work: the conventional path transfers one record per call, while the Foundgine path batches a full concurrency-sized group of transfers into a single UNNEST call. Measured per-second throughput reflects that: Foundgine's batched path sustained roughly 6–11× the conventional path's RPS across every workload/concurrency cell in the matrix, including at C64. At 10,000 customers/C64 specifically, Foundgine averaged about 10,159 RPS versus 1,714 RPS for the conventional MCP + EF Core path. Average wall time per completed transfer was higher on the Foundgine path (about 180.9 ms versus 32.9 ms at that cell), which is the expected cost of queuing inside a large batch rather than a scalability problem. Both paths recorded zero failures in the published cells.

Key measurements

toolCalls1 → 1

c8to32Foundgine ~6–11× RPS

c6410k/C64: 10,159 vs 1,714 RPS

wallC64180.9 vs 32.9 ms

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.

The benchmark distinguishes measured timings and tool calls from its estimated context-load heuristic.

Run 5b → is a controlled follow-up that holds the client fixed and isolates individual MCP calls versus one semantic batch call, to test whether the C64 behaviour above is tied to this specific endpoint or to batching generally.

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