Proving Ground

What proving-ground MCP server does

The proving-ground MCP server exposes a synthetic finance-operations environment where agents work accounts-payable exceptions. The hosted twin contains approximately 8,700 invoices and 3,960 exceptions across twelve months of generated history. Exception types include price mismatches, quantity mismatches, possible duplicates, missing purchase orders, unmatched payments, and vendor bank changes.

Agents enter an isolated sandbox and interact with the twin through an HTTP API exposed as MCP. The environment returns the verifier's decision for each claim and records the associated usage charge. A proof retrieval operation returns the workflow evidence assembled by the run, including replay results, known failure modes, pricing information, and live metered outcomes.

The repository also contains the local demo loop that seeds the twin, explores candidate workflows, admits or rejects verifiers, replays held-out cases, prices admitted work, operates the workflows, and renders out/proof_packet.md.

How it works

The proving-ground MCP server keeps the system of record behind a sealed API. Each actor receives a private sandbox, while writes record the acting party. Harness-only fields such as expected truth and held-out status are not served to agents.

A workflow first needs evidence of real volume and unit cost from the customer's records. The verifier is implemented in code and recomputes the required end state, then checks the audit log for out-of-scope writes. It does not ask an LLM to judge the result.

Proof uses twenty held-out historical cases per workflow in sandbox copies. Admission requires the verifier to agree with at least 90% of historical human outcomes and prevents a blind breaker strategy from reaching 70%. This excludes fixed-rule tasks such as the demonstrated vendor-bank-change control from outcome pricing. Model calls use separate proposer, solver, and breaker roles, with their actual costs recorded.

Setup and configuration

For a local run, install the dependencies with pip install -r requirements.txt, create the deterministic twin with python -m src.cli seed, and run python -m src.cli selfcheck to check verifier agreement and replay behavior. python -m src.cli run-all executes the complete explore, admission, proof, pricing, operation, and packet sequence. Individual stages include serve, explore, admit, prove, price, operate, packet, and cost.

Model access uses an OpenRouter key supplied through OPENROUTER_API_KEY or the documented configuration file. The proposer, solver, and breaker models can be changed with PG_PROPOSER_MODEL, PG_SOLVER_MODEL, and PG_BREAKER_MODEL. A full run is described as costing roughly two to three dollars in model usage, with each call's cost included in the cost-to-serve calculation.

The hosted endpoint accepts MCP connections at /mcp. Authenticated REST requests use a bearer token and sandbox header; MCP sessions can instead create a seat during initialization. Reads are free, while resolution and escalation operations consume credits. A 402 Payment Required response indicates that the seat needs more credit.

Tools and capabilities

• Discover and inspect AP exceptions in the synthetic twin.
• Work exception cases through the supported agent actions.
• Verify claims against the coded policy and system-of-record state.
• Replay held-out cases to measure workflow pass rates.
• Apply admission checks using historical agreement and breaker results.
• Retrieve the proof packet through the proof operation.
• Track per-call model cost, credits, and metered live outcomes.

Limitations and notes

The data is synthetic and the twin is presented as an adapter boundary for a possible ERP or open-source ERP backend; it is not itself an Odoo or ERPNext integration. The unmatched-payment workflow in the recorded run fell below the contract threshold, so it was not priced. The vendor-bank-change workflow was screened because a blind fixed-rule strategy passed it.

The hosted terms and privacy documents are marked as drafts and are not legal advice. Taking a hosted seat constitutes acceptance of those terms. The local workflow depends on model access for its agent roles, while the verifier itself is code-based.