Zero-Trust Physics

Verify receipt

verify_receipt

Read-onlyIdempotent

Verifies the receipt at the end of one response against the text before it. It takes no physics permit. The receipt covers every byte of the response before it, the decimal values included, and shows who produced the response or when in no way: it has no key. matches true proves only that those bytes are unchanged since the receipt was written; anyone can write a matching receipt for any text, so it is not a verification of the answer. A response that names an engine_version has it said beside matches, with whether it is this engine's; origin needs engine_version_is_this_engines true and a replay. match_proves says this in each answer. The receipt covers the request as it was written, number spellings included, while a seal covers its values: a request sent with 310 and the same request sent with 310.0 give different receipts and the same seal, so a receipt that differs between two such answers is not a sign of tampering. Replaying the request through run_trajectory, solve or compute_step shows the engine produced it; verify_tape, verify_solution and verify_dataset with the request and its seal do that replay and compare the seals.

Input Schema

Name	Required	Description
`public_key`	No	The base64 of the ML-DSA-87 public key (2,592 bytes) to verify the answer's signature with; without it, this engine's own.
`seen_nonces`	No	Nonces of signatures already seen: one of them again is SignatureNonceReplayed.
`response_text`	Yes	The exact text of a response as it was received, ending with the receipt, and the engine's signature after it when it carries one.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 22, 2026

changedInput schema / description

Previous value: -"The text of one response from compute_step, run_trajectory or solve, or the head of a dataset written as its JSON text. A signature after the receipt is checked against public_key or else this engine's own key, and reported under signature."New value: +"The text of one response from compute_step, run_trajectory or solve, or the head of a dataset written as its JSON text. A signature after the receipt is verified against public_key or else this engine's own key, and reported under signature."

changedInput schema / properties / public_key / description

Previous value: -"The base64 of the ML-DSA-87 public key (2,592 bytes) to check the answer's signature with; without it, this engine's own."New value: +"The base64 of the ML-DSA-87 public key (2,592 bytes) to verify the answer's signature with; without it, this engine's own."

Changed4 schema fields changedOct 19, 2026

changedInput schema / description

Previous value: -"The text of one response from compute_step, run_trajectory or solve, or the head of a dataset written as its JSON text."New value: +"The text of one response from compute_step, run_trajectory or solve, or the head of a dataset written as its JSON text. A signature after the receipt is checked against public_key or else this engine's own key, and reported under signature."

addedInput schema / properties / public_key

Added value: +{
+  "description": "The base64 of the ML-DSA-87 public key (2,592 bytes) to check the answer's signature with; without it, this engine's own.",
+  "type": "string"
+}

changedInput schema / properties / response_text / description

Previous value: -"The exact text of a response as it was received, ending with the receipt."New value: +"The exact text of a response as it was received, ending with the receipt, and the engine's signature after it when it carries one."

addedInput schema / properties / seen_nonces

Added value: +{
+  "description": "Nonces of signatures already seen: one of them again is SignatureNonceReplayed.",
+  "items": {
+    "pattern": "^[0-9a-f]{64}$",
+    "type": "string"
+  },
+  "type": "array"
+}

Changed1 schema field changedOct 15, 2026

changedInput schema / description

Previous value: -"The text of one response from verify_step, run_trajectory or solve, or the head of a dataset written as its JSON text."New value: +"The text of one response from compute_step, run_trajectory or solve, or the head of a dataset written as its JSON text."

First observedOct 13, 2026

TDQS

A3.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare a read-only, idempotent, closed operation, and the description adds meaningful behavior: no key or identity/time attestation, receipt coverage over raw bytes including number spellings (310 vs 310.0), nonce replay detection, and fallback to the engine's own key. It is rich but disorganized, and the central caveat is buried rather than front-loaded.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded, but the body is long, convoluted, and full of oblique phrasing ('has it said beside matches', 'in no way: it has no key'). Several sentences repeat the same integrity-not-authenticity caveat, and the reader must work to extract the actionable rules.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 3-parameter verification tool with a fully documented schema and no output schema, the description covers the important edge cases: signature verification versus engine key, nonce replay, engine_version reporting, and the difference between receipt bytes and seal values. It is complete enough to call correctly, despite the turgid prose.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all three parameters are already documented. The description adds some interpretive nuance (that the receipt covers exact request spellings, that public_key falls back to the engine's own), but it does not systematically explain the parameters beyond what the schema provides, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence gives a specific verb and object: verifying the receipt at the end of a response against the preceding text. It also names the replay-oriented siblings (verify_tape, verify_solution, verify_dataset) and explains how this differs, though the surrounding prose ('takes no physics permit') muddies the signal.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly limits what a successful match means ('matches true proves only that those bytes are unchanged') and points to run_trajectory/solve/compute_step plus the verify_* tools for replay-based provenance. That is real when-to-use / when-not-to-use guidance, though it is delivered indirectly and never as a clean rule.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Zero-Trust Physics tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?