Skip to main content
Glama

Verify dataset

verify_dataset
Read-onlyIdempotent

Verifies the seal of a dataset. Short form: request is the run_dataset request as it was sent, and dataset_seal is the seal its answer gave. The plan is run again under run_dataset's permits and limits; the answer is holds, cause ("dataset_seal" when the seal given is not the seal the plan runs to), recomputed_dataset_seal when it holds (else no seal: run_dataset gives the true one), compared, and text_not_compared: no rows the agent holds are compared. A plan of solves is verified by this short form only. Long form: head, rows and frames_hex, the three parts a full answer carries (answer "full"), together, as they came. The rows, the root and the seal are recomputed, and row and fault name the first row changed, swapped, dropped or repeated; then the plan is run again under run_dataset's permits and limits and the engine's answer compared with it, value by value and byte for byte (cause answer_text, with differs_at and row): holds is true only when every byte is the engine's, values_hold when every value is. On this open connection a dataset is returned inline and holds at most 300 runs (OPEN_MAX_DATASET_ROWS), 1000000 steps in all (OPEN_MAX_DATASET_STEPS), 10000 frames and an answer counted from the plan at 4194304 bytes (OPEN_MAX_DATASET_ANSWER_BYTES) and 42500 characters, up to about 150 summary rows; a plan of solves holds the engine's own 64 and at most 15 s of them, or one, at each solver's measured time, which describe_solver states with the count (OPEN_PLAN_SECONDS). 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

NameRequiredDescriptionDefault
headNoWith rows and frames_hex: the head a run_dataset answer carries.
rowsNoWith head and frames_hex: the rows a full run_dataset answer (answer "full") carries.
requestNoWith dataset_seal alone: the run_dataset request as it was sent (the head's request). The plan is run again, under the permits and the limits of run_dataset, and its seal is compared with dataset_seal. Nothing is stored or read from storage, so it works whatever the return mode and on every connection. Its fields are run_dataset's. Worked example of the short form, as the whole arguments: {"request":{"domain":"energy","card":"thermal","plan":{"kind":"list","runs":[{"initial":{"temperature_k":293.15},"dt_s":1.0,"segments":[{"steps":60,"load":{"heat_power_w":5.0,"ambient_k":293.15}}],"record_every":60}]},"store":"none","return":"inline"},"dataset_seal":"<the dataset_seal of its run_dataset answer, 96 lowercase hex digits>"}.
frames_hexNoWith head and rows: the frames a run_dataset answer carries, or null.
public_keyNoThe 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_noncesNoNonces of signatures already seen: one of them again is SignatureNonceReplayed.
dataset_sealNoWith request: the dataset_seal of the run_dataset answer, compared with the seal the plan runs to. Alone: the seal of a dataset stored as files (return "file"), read from the connection's own folder of that name. A dataset returned in the answer is not stored: it is verified with its request, or by its head, rows and frames_hex.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / description
      Previous value: -"One of three forms. request and dataset_seal, the short form: the plan is run again and its seal compared. The three parts a full run_dataset answer carries (head, rows and frames_hex, all three required together, as they came), the long form: the rows, the root and the seal are recomputed from their exact values, then the head's plan is run again under the permits and the limits of run_dataset and the engine's full answer to it compared with the parts sent, value by value and then byte for byte, so a dataset that holds is every byte the engine's. dataset_seal alone: the stored dataset of that seal, its seals recomputed from its files and its plan run again into a folder of its own, the stored files compared with that run's byte for byte. 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. The signature of a dataset follows its head's receipt."New value: +"One of three forms. request and dataset_seal, the short form: the plan is run again and its seal compared. The three parts a full run_dataset answer carries (head, rows and frames_hex, all three required together, as they came), the long form: the rows, the root and the seal are recomputed from their exact values, then the head's plan is run again under the permits and the limits of run_dataset and the engine's full answer to it compared with the parts sent, value by value and then byte for byte, so a dataset that holds is every byte the engine's. dataset_seal alone: the stored dataset of that seal, its seals recomputed from its files and its plan run again into a folder of its own, the stored files compared with that run's byte for byte. 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. The signature of a dataset follows its head's receipt."
    • 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."
  2. Changed5 schema fields changed
    • changedInput schema / description
      Previous value: -"One of three forms. request and dataset_seal, the short form: the plan is run again and its seal compared. The three parts a full run_dataset answer carries (head, rows and frames_hex, all three required together, as they came), the long form: the rows, the root and the seal are recomputed from their exact values, then the head's plan is run again under the permits and the limits of run_dataset and the engine's full answer to it compared with the parts sent, value by value and then byte for byte, so a dataset that holds is every byte the engine's. dataset_seal alone: the stored dataset of that seal, its seals recomputed from its files and its plan run again into a folder of its own, the stored files compared with that run's byte for byte. 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: +"One of three forms. request and dataset_seal, the short form: the plan is run again and its seal compared. The three parts a full run_dataset answer carries (head, rows and frames_hex, all three required together, as they came), the long form: the rows, the root and the seal are recomputed from their exact values, then the head's plan is run again under the permits and the limits of run_dataset and the engine's full answer to it compared with the parts sent, value by value and then byte for byte, so a dataset that holds is every byte the engine's. dataset_seal alone: the stored dataset of that seal, its seals recomputed from its files and its plan run again into a folder of its own, the stored files compared with that run's byte for byte. 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. The signature of a dataset follows its head's receipt."
    • changedInput schema / properties / dataset_seal / pattern
      Previous value: -"^[0-9a-f]{64}$"New value: +"^[0-9a-f]{96}$"
    • 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 dataset_seal alone: the run_dataset request as it was sent (the head's request). The plan is run again, under the permits and the limits of run_dataset, and its seal is compared with dataset_seal. Nothing is stored or read from storage, so it works whatever the return mode and on every connection. Its fields are run_dataset's. Worked example of the short form, as the whole arguments: {\"request\":{\"domain\":\"energy\",\"card\":\"thermal\",\"plan\":{\"kind\":\"list\",\"runs\":[{\"initial\":{\"temperature_k\":293.15},\"dt_s\":1.0,\"segments\":[{\"steps\":60,\"load\":{\"heat_power_w\":5.0,\"ambient_k\":293.15}}],\"record_every\":60}]},\"store\":\"none\",\"return\":\"inline\"},\"dataset_seal\":\"<the dataset_seal of its run_dataset answer, 64 lowercase hex digits>\"}."New value: +"With dataset_seal alone: the run_dataset request as it was sent (the head's request). The plan is run again, under the permits and the limits of run_dataset, and its seal is compared with dataset_seal. Nothing is stored or read from storage, so it works whatever the return mode and on every connection. Its fields are run_dataset's. Worked example of the short form, as the whole arguments: {\"request\":{\"domain\":\"energy\",\"card\":\"thermal\",\"plan\":{\"kind\":\"list\",\"runs\":[{\"initial\":{\"temperature_k\":293.15},\"dt_s\":1.0,\"segments\":[{\"steps\":60,\"load\":{\"heat_power_w\":5.0,\"ambient_k\":293.15}}],\"record_every\":60}]},\"store\":\"none\",\"return\":\"inline\"},\"dataset_seal\":\"<the dataset_seal of its run_dataset answer, 96 lowercase hex digits>\"}."
    • 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"
      +}
  3. Changed2 schema fields changed
    • changedInput schema / description
      Previous value: -"One of three forms. request and dataset_seal, the short form: the plan is run again and its seal compared. The three parts a run_dataset answer carries (head, rows and frames_hex, all three required together): the rows, the root and the seal are recomputed with no physics run. dataset_seal alone: the stored dataset of that seal is checked with no physics run."New value: +"One of three forms. request and dataset_seal, the short form: the plan is run again and its seal compared. The three parts a full run_dataset answer carries (head, rows and frames_hex, all three required together, as they came), the long form: the rows, the root and the seal are recomputed from their exact values, then the head's plan is run again under the permits and the limits of run_dataset and the engine's full answer to it compared with the parts sent, value by value and then byte for byte, so a dataset that holds is every byte the engine's. dataset_seal alone: the stored dataset of that seal, its seals recomputed from its files and its plan run again into a folder of its own, the stored files compared with that run's byte for byte. 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 / dataset_seal / description
      Previous value: -"With request: the dataset_seal of the run_dataset answer, compared with the seal the plan runs to. Alone: the seal of a dataset stored as files (return \"file\"), read from the connection's own folder of that name. A dataset returned in the answer is not stored: it is checked with its request, or by its head, rows and frames_hex."New value: +"With request: the dataset_seal of the run_dataset answer, compared with the seal the plan runs to. Alone: the seal of a dataset stored as files (return \"file\"), read from the connection's own folder of that name. A dataset returned in the answer is not stored: it is verified with its request, or by its head, rows and frames_hex."
  4. Changed3 schema fields changed
    • changedInput schema / description
      Previous value: -"Send one of three forms. request and dataset_seal, the short form: the plan is run again and its seal compared. The three parts a run_dataset answer carries (head, rows and frames_hex, all three required together): the rows, the root and the seal are recomputed with no physics run. dataset_seal alone: the stored dataset of that seal is checked with no physics run."New value: +"One of three forms. request and dataset_seal, the short form: the plan is run again and its seal compared. The three parts a run_dataset answer carries (head, rows and frames_hex, all three required together): the rows, the root and the seal are recomputed with no physics run. dataset_seal alone: the stored dataset of that seal is checked with no physics run."
    • changedInput schema / properties / dataset_seal / description
      Previous value: -"With request: the dataset_seal of the run_dataset answer, compared with the seal the plan runs to. Alone: the seal of a dataset the gateway stored in files (return \"file\"); the gateway reads its own folder of that name. A dataset returned in the answer is not stored: send it with its request, or send its head, rows and frames_hex."New value: +"With request: the dataset_seal of the run_dataset answer, compared with the seal the plan runs to. Alone: the seal of a dataset stored as files (return \"file\"), read from the connection's own folder of that name. A dataset returned in the answer is not stored: it is checked with its request, or by its head, rows and frames_hex."
    • changedInput schema / properties / request / description
      Previous value: -"With dataset_seal alone: the run_dataset request as it was sent (the head's request). The plan is run again, under the permits and the limits of run_dataset, and its seal is compared with dataset_seal. Nothing is stored or read from storage, so it works whatever the return mode and on every connection. Its fields are run_dataset's."New value: +"With dataset_seal alone: the run_dataset request as it was sent (the head's request). The plan is run again, under the permits and the limits of run_dataset, and its seal is compared with dataset_seal. Nothing is stored or read from storage, so it works whatever the return mode and on every connection. Its fields are run_dataset's. Worked example of the short form, as the whole arguments: {\"request\":{\"domain\":\"energy\",\"card\":\"thermal\",\"plan\":{\"kind\":\"list\",\"runs\":[{\"initial\":{\"temperature_k\":293.15},\"dt_s\":1.0,\"segments\":[{\"steps\":60,\"load\":{\"heat_power_w\":5.0,\"ambient_k\":293.15}}],\"record_every\":60}]},\"store\":\"none\",\"return\":\"inline\"},\"dataset_seal\":\"<the dataset_seal of its run_dataset answer, 64 lowercase hex digits>\"}."
  5. First observed

TDQS

A4/5.0
Behavior5/5

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

Beyond the read-only annotations, it discloses concrete limits (OPEN_MAX_DATASET_ROWS, steps, frames, answer bytes), concurrency behavior, the 60-second wait, exact error strings, and signature-verification failure modes. This is a rich behavioral profile that an agent could not infer from annotations alone.

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 dense, with run-on sentences that pack multiple concepts together and repeat schema-level detail. It front-loads the core purpose, but the body is hard to parse and would benefit from much tighter structure.

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?

For a complex verification tool with no output schema, it explains the returned fields (holds, values_hold, differs_at, cause), failure modes, signature behavior, and resource limits. An agent would have enough context to invoke and interpret the tool correctly.

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 the schema already defines each parameter in detail, including a worked example for the short form. The description reinforces form combinations but adds little syntax or semantic detail beyond what the schema provides; baseline 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 first sentence names a specific verb and resource: 'Verifies the seal of a dataset.' The three forms are then enumerated with enough detail to see the scope. However, it never names or contrasts with sibling verify_* tools, so sibling differentiation is left implicit.

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?

The description clearly lays out the three forms and the parameter combinations that select them, including 'A dataset returned in the answer is not stored: it is verified with its request, or by its head, rows and frames_hex.' That is strong when-to-use guidance for the tool's own modes, though it offers no explicit comparison to alternatives like verify_receipt.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources