MCP

Connect it

Point an MCP client at the probatio-mcp binary. Nothing else is needed: verification is arithmetic, so there is no endpoint to configure.

{
  "mcpServers": {
    "probatio": {
      "command": "npx",
      "args": ["-y", "@probatio/mcp"]
    }
  }
}

PROBATIO_API points at a specific instance and defaults to the hosted one. It is the only setting there is.

The tools

Five, each a plain wrapper over the SDK.

verify_record   { wallet, season? }
    Rebuild every fill from the figures it was priced from and compare
    each hash to the seal recorded with it. Returns verified, the record
    root, any fills that disagree, and every check.

get_record      { wallet }
    The public record: name, the seasons traded, and where to prove it.

get_standings   { limit? }
    The standings of the current ranked season, or null when none runs.

get_season      { }
    The current ranked season: status, pot, projected payouts, and the
    ruleset hash recorded for the season versus the one recomputed now.

get_proof       { wallet, season? }
    The raw inputs verify_record recomputes from: every fill, the
    figures it was priced from, and the seal written with it.

verify_record is the one that matters. It needs nothing but a wallet, and it returns the verdict along with each step, so an agent can show its work rather than assert a result.

Why an agent can trust it

For the same reason a person can. The server reads a trader's fills from a Probatio instance, because the data lives somewhere, but it does not read the verdict from anywhere. It rehashes every fill with the same open-source function the engine seals with, and compares. An instance that altered a stored fill has to hand over the altered figures, which no longer produce the seal beside them, so it fails verify_record rather than being believed by it.