Zero-Trust Physics

Verify solution

verify_solution

Read-onlyIdempotent

Verifies the seal of a solution. Short form, which needs only what is short: request is the solve request as it was sent (the answer's inputs), and solution_seal is the seal its answer gave. The request is solved again, under a physics permit and the limits and refusals of solve, and the answer is holds, cause ("solution_seal" when the seal given is not the seal the request solves to), recomputed_solution_seal and recomputed_receipt_sha384 when it holds (else no seal: solve gives the true one), compared, and text_not_compared: no answer text the agent holds is compared. Long form: the whole solve answer sent back as it came, without request. Its solution seal is recomputed from its exact hex values and the part that fails is named, then its request is solved again under a physics permit and the engine's answer compared with it, value by value and byte for byte, receipt included: holds is true only when every byte is the engine's, values_hold when every value is, else cause names the part, solution_seal (the request solves to another seal), answer_text (with differs_at, the first field that differs) or engine_version (an answer of another version). A chained solve: its whole answer with from beside it; the upstream run is computed again and the chain held too (cause chain), with recomputed_chain_seal. Alone it is refused (AnswerCarriesNoRequest). Nothing is stored, so each form answers the same on every connection. On this open connection one address holds at most 1 physics permit at a time, and long work (a solve, a plan of runs or of solves, a run of more than 10000 steps, or a verification that computes one again) runs 1 at a time. A call that finds no permit or no place is answered "Too many concurrent physics tasks." and nothing waits: the same call sent later is answered once one is free. An answer is waited for 60 seconds, and long work is stopped there.

Input Schema

Name	Required	Description
`from`	No	Beside the whole answer of a chained solve: the from solve took (request, run_seal, coupling). The upstream run is computed again and held to its seal, each handed value to it, and the request solved again with it; the answer alone is refused (AnswerCarriesNoRequest).
`inputs`	No	The inputs of the solve answer, sent back as returned: the request that was solved. It is hashed, and solved again under a physics permit and the limits of solve.
`reject`	No
`result`	No
`outcome`	No
`request`	No	With solution_seal alone: the solve request as it was sent (the answer's inputs). It is solved again, under a physics permit and the limits of solve, and its seal is compared with solution_seal. Its fields are solve's. Worked example of the short form, as the whole arguments: {"request":{"solver":"atom_dft","parameters":{"atomic_number":10}},"solution_seal":"<the solution_seal of its solve answer, 96 lowercase hex digits>"}.
`invariants`	No
`iterations`	No
`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.
`seal_parts`	No
`seen_nonces`	No	Nonces of signatures already seen: one of them again is SignatureNonceReplayed.
`field_sha384`	No
`solution_seal`	No	The solution_seal of the solve answer: with request, or as part of the whole answer.
`engine_version`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 22, 2026

changedInput schema / description

Previous value: -"Either request and solution_seal alone, the short form: the request is solved again and its seal compared with solution_seal. Or the whole solve answer sent back as it came, without request, the long form: inputs, engine_version, outcome, iterations, reject, result, invariants, field_sha384, seal_parts and solution_seal are then all required. The solution seal is recomputed from its exact hex values and the part that fails is named; then its request is solved again under a physics permit and the limits of solve, and the engine's whole answer to it compared with the answer sent, value by value and then byte for byte, the receipt included, so an answer that holds is every byte the engine's. A seal has no key: an answer whose values were rewritten with its seal parts, seal and receipt worked out again holds every seal, and only the solve shows it is not the engine's (cause solution_seal). The long form's answer carries holds, true when the answer sent is every byte the engine's, and values_hold beside it, true when every value of it is the engine's answer to its request computed again, whatever its spelling: each number by its 64-bit value, strings, flags and null exactly, keys and their order, the receipt string among them. A copy whose numbers a client wrote again in its own spelling (0.0001 for 1.0e-4, 12 for 12.0) has holds false and values_hold true, and differs_at names the first place its text differs. An answer the engine signed (signature, ML-DSA-87 over its receipt, with issued_at, expires_at and nonce) has its signature checked first, against public_key or else this engine's own key: one that does not hold is cause signature, named (SignatureDoesNotVerify, SignatureExpired, SignatureNonceReplayed, SignatureKeyMismatch, ReceiptDoesNotMatch, SignatureAbsent when public_key is given and there is none), and nothing is computed."New value: +"Either request and solution_seal alone, the short form: the request is solved again and its seal compared with solution_seal. Or the whole solve answer sent back as it came, without request, the long form: inputs, engine_version, outcome, iterations, reject, result, invariants, field_sha384, seal_parts and solution_seal are then all required. The solution seal is recomputed from its exact hex values and the part that fails is named; then its request is solved again under a physics permit and the limits of solve, and the engine's whole answer to it compared with the answer sent, value by value and then byte for byte, the receipt included, so an answer that holds is every byte the engine's. A seal has no key: an answer whose values were rewritten with its seal parts, seal and receipt worked out again holds every seal, and only the solve shows it is not the engine's (cause solution_seal). The long form's answer carries holds, true when the answer sent is every byte the engine's, and values_hold beside it, true when every value of it is the engine's answer to its request computed again, whatever its spelling: each number by its 64-bit value, strings, flags and null exactly, keys and their order, the receipt string among them. A copy whose numbers a client wrote again in its own spelling (0.0001 for 1.0e-4, 12 for 12.0) has holds false and values_hold true, and differs_at names the first place its text differs. An answer the engine signed (signature, ML-DSA-87 over its receipt, with issued_at, expires_at and nonce) has its signature verified first, against public_key or else this engine's own key: one that does not hold is cause signature, named (SignatureDoesNotVerify, SignatureExpired, SignatureNonceReplayed, SignatureKeyMismatch, ReceiptDoesNotMatch, SignatureAbsent when public_key is given and there is none), and nothing is computed. A signed answer a client wrote again in its own spacing or key order has its signature verified over the receipt it carries; where that receipt does not cover the bytes sent, signature names ReceiptDoesNotMatch with written_again, and the answer is computed again: holds, values_hold and differs_at say what changed."

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."

Changed10 schema fields changedOct 19, 2026

changedInput schema / description

Previous value: -"Either request and solution_seal alone, the short form: the request is solved again and its seal compared with solution_seal. Or the whole solve answer sent back as it came, without request, the long form: inputs, engine_version, outcome, iterations, reject, result, invariants, field_sha256, seal_parts and solution_seal are then all required. The solution seal is recomputed from its exact hex values and the part that fails is named; then its request is solved again under a physics permit and the limits of solve, and the engine's whole answer to it compared with the answer sent, value by value and then byte for byte, the receipt included, so an answer that holds is every byte the engine's. A seal has no key: an answer whose values were rewritten with its seal parts, seal and receipt worked out again holds every seal, and only the solve shows it is not the engine's (cause solution_seal). The long form's answer carries holds, true when the answer sent is every byte the engine's, and values_hold beside it, true when every value of it is the engine's answer to its request computed again, whatever its spelling: each number by its 64-bit value, strings, flags and null exactly, keys and their order, the receipt string among them. A copy whose numbers a client wrote again in its own spelling (0.0001 for 1.0e-4, 12 for 12.0) has holds false and values_hold true, and differs_at names the first place its text differs."New value: +"Either request and solution_seal alone, the short form: the request is solved again and its seal compared with solution_seal. Or the whole solve answer sent back as it came, without request, the long form: inputs, engine_version, outcome, iterations, reject, result, invariants, field_sha384, seal_parts and solution_seal are then all required. The solution seal is recomputed from its exact hex values and the part that fails is named; then its request is solved again under a physics permit and the limits of solve, and the engine's whole answer to it compared with the answer sent, value by value and then byte for byte, the receipt included, so an answer that holds is every byte the engine's. A seal has no key: an answer whose values were rewritten with its seal parts, seal and receipt worked out again holds every seal, and only the solve shows it is not the engine's (cause solution_seal). The long form's answer carries holds, true when the answer sent is every byte the engine's, and values_hold beside it, true when every value of it is the engine's answer to its request computed again, whatever its spelling: each number by its 64-bit value, strings, flags and null exactly, keys and their order, the receipt string among them. A copy whose numbers a client wrote again in its own spelling (0.0001 for 1.0e-4, 12 for 12.0) has holds false and values_hold true, and differs_at names the first place its text differs. An answer the engine signed (signature, ML-DSA-87 over its receipt, with issued_at, expires_at and nonce) has its signature checked first, against public_key or else this engine's own key: one that does not hold is cause signature, named (SignatureDoesNotVerify, SignatureExpired, SignatureNonceReplayed, SignatureKeyMismatch, ReceiptDoesNotMatch, SignatureAbsent when public_key is given and there is none), and nothing is computed."

removedInput schema / properties / field_sha256

Removed value: -{
-  "type": [
-    "string",
-    "null"
-  ]
-}

addedInput schema / properties / field_sha384

Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}

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 / request / description

Previous value: -"With solution_seal alone: the solve request as it was sent (the answer's inputs). It is solved again, under a physics permit and the limits of solve, and its seal is compared with solution_seal. Its fields are solve's. Worked example of the short form, as the whole arguments: {\"request\":{\"solver\":\"atom_dft\",\"parameters\":{\"atomic_number\":10}},\"solution_seal\":\"<the solution_seal of its solve answer, 64 lowercase hex digits>\"}."New value: +"With solution_seal alone: the solve request as it was sent (the answer's inputs). It is solved again, under a physics permit and the limits of solve, and its seal is compared with solution_seal. Its fields are solve's. Worked example of the short form, as the whole arguments: {\"request\":{\"solver\":\"atom_dft\",\"parameters\":{\"atomic_number\":10}},\"solution_seal\":\"<the solution_seal of its solve answer, 96 lowercase hex digits>\"}."

removedInput schema / properties / seal_parts / properties / field_sha256
```
Removed value: -{
-  "type": "string"
-}
```
addedInput schema / properties / seal_parts / properties / field_sha384
```
Added value: +{
+  "type": "string"
+}
```

changedInput schema / properties / seal_parts / required

Previous value: -[
-  "inputs",
-  "engine_version",
-  "result",
-  "invariants",
-  "field_sha256",
-  "outcome"
-]New value: +[
+  "inputs",
+  "engine_version",
+  "result",
+  "invariants",
+  "field_sha384",
+  "outcome"
+]

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"
+}

changedInput schema / properties / solution_seal / pattern

Previous value: -"^[0-9a-f]{64}$"New value: +"^[0-9a-f]{96}$"

Changed1 schema field changedOct 19, 2026

addedInput schema / properties / from

Added value: +{
+  "description": "Beside the whole answer of a chained solve: the from solve took (request, run_seal, coupling). The upstream run is computed again and held to its seal, each handed value to it, and the request solved again with it; the answer alone is refused (AnswerCarriesNoRequest).",
+  "type": "object"
+}

Changed2 schema fields changedOct 15, 2026

changedInput schema / description

Previous value: -"Either request and solution_seal alone, the short form: the request is solved again and its seal compared with solution_seal. Or the whole solve answer sent back, without request: inputs, engine_version, outcome, iterations, reject, result, invariants, field_sha256, seal_parts and solution_seal are then all required, the solution seal is recomputed and the part that fails is named, with no physics run."New value: +"Either request and solution_seal alone, the short form: the request is solved again and its seal compared with solution_seal. Or the whole solve answer sent back as it came, without request, the long form: inputs, engine_version, outcome, iterations, reject, result, invariants, field_sha256, seal_parts and solution_seal are then all required. The solution seal is recomputed from its exact hex values and the part that fails is named; then its request is solved again under a physics permit and the limits of solve, and the engine's whole answer to it compared with the answer sent, value by value and then byte for byte, the receipt included, so an answer that holds is every byte the engine's. A seal has no key: an answer whose values were rewritten with its seal parts, seal and receipt worked out again holds every seal, and only the solve shows it is not the engine's (cause solution_seal). The long form's answer carries holds, true when the answer sent is every byte the engine's, and values_hold beside it, true when every value of it is the engine's answer to its request computed again, whatever its spelling: each number by its 64-bit value, strings, flags and null exactly, keys and their order, the receipt string among them. A copy whose numbers a client wrote again in its own spelling (0.0001 for 1.0e-4, 12 for 12.0) has holds false and values_hold true, and differs_at names the first place its text differs."

changedInput schema / properties / inputs / description

Previous value: -"The inputs of the solve answer, sent back as returned: the request that was solved. It is hashed, not solved."New value: +"The inputs of the solve answer, sent back as returned: the request that was solved. It is hashed, and solved again under a physics permit and the limits of solve."

Changed1 schema field changedOct 15, 2026

changedInput schema / properties / request / description

Previous value: -"With solution_seal alone: the solve request as it was sent (the answer's inputs). It is solved again, under a physics permit and the limits of solve, and its seal is compared with solution_seal. Its fields are solve's."New value: +"With solution_seal alone: the solve request as it was sent (the answer's inputs). It is solved again, under a physics permit and the limits of solve, and its seal is compared with solution_seal. Its fields are solve's. Worked example of the short form, as the whole arguments: {\"request\":{\"solver\":\"atom_dft\",\"parameters\":{\"atomic_number\":10}},\"solution_seal\":\"<the solution_seal of its solve answer, 64 lowercase hex digits>\"}."

First observedOct 13, 2026

TDQS

A3.8/5.0

Behavior5/5

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

Beyond the readOnly and idempotent annotations, the description discloses substantial operational behavior: nothing is stored, each address holds at most one physics permit at a time, long work runs one at a time, calls may be refused with 'Too many concurrent physics tasks.', and answers are waited for 60 seconds. It also explains signature verification order and the named failure causes. These are exactly the kind of behavioral traits annotations do not cover.

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 description is extremely long and dominated by run-on sentences, making it hard to parse despite the underlying complexity. The key information is present but not cleanly structured or front-loaded; concurrency and timeout details are mixed into the same dense paragraph as seal and signature verification logic.

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

Completeness5/5

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

With no output schema and a complex 14-parameter input, the description carries the full burden and largely meets it. It explains the return values holds, values_hold, differs_at, cause, recomputed_solution_seal, recomputed_receipt_sha384, signature failure causes, and the concurrency/timeout behavior, so an agent has enough context to call and interpret the tool.

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 only 43% across 14 parameters, so the description must compensate. It does add useful semantics for request (with a worked example), solution_seal, from, public_key, seen_nonces, and the long-form required fields, but it leaves several top-level parameters such as reject, result, outcome, invariants, iterations, and field_sha384 without individual meaning beyond being parts of the answer.

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 first sentence states a specific verb and resource: 'Verifies the seal of a solution.' It then distinguishes the short form from the long form and the chained-solve form, so an agent can tell what operation it performs. However, it never names or differentiates itself from sibling verification tools such as verify_receipt or verify_step.

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

Usage Guidelines3/5

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

The description clearly explains which form to use for which payload shape: request plus solution_seal for the short form, the whole solve answer without request for the long form, and a whole answer with from for a chained solve. It also states that the answer alone is refused. But it gives no guidance on when to choose this tool over the other verify_* siblings.

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?