Skip to main content
Glama

Verify a run's sealed table

verify_run
Read-onlyIdempotent

Checks the table one succeeded run sealed against its own manifest. Without deep it reads the manifest, checks it hashes to the digest it was sealed with and names this run's table version, and checks every part the run sealed is among the parts the run lists; no part is fetched. With deep: true it also re-hashes every part this run sealed against the digest the manifest states. Example: "run_id": "…", "deep": true. deep reads at most $MAX_DEEP_PARTSparts and $MAX_DEEP_BYTESbytes inside one call; a larger run is checked shallowly and says so, and mr-data verify RUN --deep from a terminal checks the rest. Parts earlier runs sealed are those runs' to verify. Returns {run_id, table_id, table_version_id, status, layout_format_version, manifest_digest, part_count, row_count, total_bytes, parts_read, deep, findings, parts_unchecked?}. status is table_verified (everything asked was checked and agrees), table_disagrees (findings says what) or table_partially_verified (nothing disagrees, but the deep check was skipped or some parts could not be read: say so, never report it as verified). Read-only, and it charges nothing: no byte leaves in the answer.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
deepNo
run_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare read-only, idempotent, non-destructive behavior, but the description adds substantial operational context: shallow checks fetch nothing, deep re-hashes sealed parts, limits are enforced, and partial results must not be reported as verified. It also states that the call charges nothing, which is valuable behavioral detail beyond annotations.

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

Conciseness4/5

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

The description is front-loaded with the core operation and then layers on deep behavior, limits, statuses, and return fields. It is dense but mostly earns its length; the inline example and long return-field list make it slightly heavier than necessary.

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?

There is no output schema and schema coverage is 0%, but the description enumerates the returned fields and defines the possible statuses, including the critical warning not to report partial verification as verified. It also covers limits and caveats, making it complete enough for correct invocation and interpretation.

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

Parameters4/5

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

Schema description coverage is 0%, so the description must carry parameter meaning. It thoroughly explains `deep`, including its effect, limits, and partial-result implications, and it illustrates `run_id`; however, `run_id` is only shown in an example rather than explicitly described beyond being the run identifier.

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

Purpose5/5

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

The description states a specific verb and resource: it checks a succeeded run's sealed table against its manifest. It clearly distinguishes the shallow default from the deep mode, so an agent can identify the operation without opening the schema.

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 explains when shallow is used and what `deep: true` adds, including call-size limits, partial verification behavior, and that earlier runs' parts are for those runs to verify. It does not explicitly name sibling alternatives such as get_run or query_run, so it falls short of full when-to-use/when-not guidance.

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