Read your recorded AI agent runs, and what changed when you swapped a model or prompt.
Runs on your machine from its package; the steps are below.
Not assessed yet.
Odel charges nothing per call. The publisher may charge for its own service.
Runs locally over stdio
This server isn't hosted — your MCP client launches it from a package registry. Use one of the commands below, or drop the config into your client (e.g. Claude Desktop).
Run
uvx pramana-mcp
MCP client config
{
"mcpServers": {
"pramana": {
"command": "uvx",
"args": [
"pramana-mcp"
]
}
}
}mcp-name: io.github.loopg/pramana-mcp
Decide whether a prompt or model change is safe to ship, by running it against your own production runs.
Pramana is a flight recorder for AI agents. It records every non-deterministic decision your agent makes in production, replays any past run exactly against your changed code, and reports which decisions moved — not which sentences got reworded.
This MCP server lets an assistant read what Pramana recorded, and check a signed evidence bundle offline. It is read-only. There is deliberately no tool that starts a replay or a comparison: a sandboxed batch calls the model for real on every trace, so it spends money, and an MCP tool is a button any assistant can press without a person deciding. Producing a comparison stays a CLI verb behind its own confirmation gate.
Nothing to install — uvx fetches it on demand.
~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or
%APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"pramana": {
"command": "uvx",
"args": ["pramana-mcp"],
"env": {
"PRAMANA_API_KEY": "<your-engineer-or-admin-api-key>"
}
}
}
}
$ claude mcp add pramana --env PRAMANA_API_KEY=<your-engineer-or-admin-api-key> -- uvx pramana-mcp
Create a key in Settings → API keys at reliai.in. Use an engineer
or admin key — an auditor key deliberately never receives recorded prompts or responses, so
get_trace would come back empty. Self-hosting? Set PRAMANA_API_URL to your own API.
list_tracesList recorded AI agent runs (traces) captured by Pramana, optionally filtered by agent, status or time range.
"What agent runs did we record last Tuesday?"
{ "agent": "refund-agent", "since": "2026-09-22T00:00:00Z", "limit": 20 }
get_traceGet one recorded agent run: its steps, model calls, tool calls with arguments, and outcome.
"Walk me through what the agent did in run loan-07 — which tools did it call, and with what?"
{ "trace_id": "loan-07-5a6eef" }
Long payloads are truncated, and the response says so rather than looking complete.
list_model_diffsList comparison runs that checked a prompt or model change against recorded production runs.
"Have we compared anything against production since the model upgrade?"
{ "since": "2026-09-20T00:00:00Z", "limit": 20 }
get_model_diffGet the findings of one comparison run: which decisions changed behaviourally, which were cosmetic, and which runs halted.
"What changed when we moved to the new model last Tuesday?"
{ "diff_id": "mdr_9f2c1a", "trace_id": "loan-07-5a6eef" }
Returns bucket counts first, then root findings, then consequent ones — never merged. One
root cause that produced forty downstream differences is one thing to investigate, not forty.
Passing trace_id is optional but much faster (see What the API could not do below).
verify_bundleVerify a Pramana signed evidence bundle offline, with no account and no network access.
"Here's the evidence bundle the vendor sent. Is it intact?"
{ "bundle_path": "./bundle.json", "public_key_path": "./pramana-public-key.txt" }
public_key_path is required. The public key shipped inside a bundle is never used to check
that same bundle — that would defeat the point.
A pass proves the bundle has not been altered since it was signed. It does not prove that what was captured was everything that happened. This is a proof of record, not a judgement of conduct.
Two tools are worse than they should be, and it is the API's fault rather than a design choice:
/v1/traces/{id}/model-diffs), so list_model_diffs and a get_model_diff without trace_id
walk the 20 most recent traces. A comparison against an older trace will not be found. Every
response says so in a notes field rather than quietly returning a short list. The bound is 20
rather than something larger because the walk is that many sequential round trips: measured
against the production API, 50 took 6.0s and 20 takes 2.4s./v1/traces returns agent_count, not agent ids, so filtering by agent means opening each
trace. That filter is applied to the 20 most recent traces only, and says so.These are the same limitations as the SDK. They are not softened for a registry listing.
AnthropicBedrock are routed to
those adapters and covered by tests; neither has been exercised against live cloud credentials.
Raw boto3 is not supported.verify_bundle runs offline
and needs no account, but today you still obtain the key from us — which is not the same as
independent verification, and is not claimed as such.evidence-samples/ holds two signed bundles, a tampered copy of each, and the key that checks
them. No account, no network. The key is sample-public-key.txt in that directory — a separate,
sample-only key, not the one a production deployment publishes at
/.well-known/pramana-evidence-public-key:
$ pip install 'pramana-verify>=0.0.6'
$ pramana-verify evidence-samples/production-run.json \
--pubkey evidence-samples/sample-public-key.txt
OK — 2 event(s), merkle_root=6ec957f1ec1443e56c01bab5440df06cfbdd6bbd67c9e8c35398d02d1a840a3a
$ pramana-verify evidence-samples/production-run.TAMPERED.json \
--pubkey evidence-samples/sample-public-key.txt
TAMPERED / INVALID:
- payload 535f17dac0ea...: content does not hash to its reference — this recorded prompt or response was tampered with
evidence-samples/FORMAT.md is the field-by-field specification. Those files are signed with a
sample key, not the key that signs real bundles.