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, but the current endpoint still has a C64 scalability limitation. Run 5b is the controlled follow-up that isolates request shape and tests batching with the same client.

Published finding

What the evidence says

After applying the runner's native batch accounting, Foundgine delivered higher logical-transfer throughput in every published Run 5 cell. Across the 16 cells it sustained about 2.02–3.87× the MCP + EF Core logical RPS (mean about 3.00×). At 10,000 customers/C64, Foundgine averaged about 3,633 logical transfers/s versus 1,638. The raw MCP request wall time was about 89.8 ms versus 33.3 ms, but the requests are not equivalent units: Foundgine carries 8 transfers per batch request while EF Core carries one. Both paths recorded zero failures.

Key measurements

toolCalls1 → 1

rpsFoundgine ~2.02–3.87× logical RPS

c6410k/C64: 1,638 vs 3,633 logical transfers/s

wallC6433.3 vs 89.8 ms/request (1 op vs 8-op batch)

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