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

Without annotations, the description discloses what the tool returns, including failure details. It implies a read-only check ('returns') and mentions flexibility in accepting proofs from any solver. It does not explicitly state side effects or limitations, but for a check operation this is sufficient.

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

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

The description is two sentences, front-loaded with the main action, and contains no redundant information.

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

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

It covers the core behavior (check, input formats, output on success/failure) concisely. It lacks details on error handling or return format, but given the tool's simplicity and no output schema, it's largely complete.

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

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

Schema coverage is 0%, so the description must explain the parameters. It implies two file paths (CNF and DRAT) through the description but does not explicitly name the parameters. The meaning of 'RUP' and 'lemma' may be unclear to non-experts. Sufficient but not fully explicit.

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

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

The description clearly identifies the operation: checking a DRAT refutation against a CNF in DIMACS form. It distinguishes itself from sibling tools (e.g., explain_certificate, verify_certificate) by focusing on RUP lemma verification with specific failure details.

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

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

It provides context on when to use (for any DRAT proof from any solver) and what it verifies (RUP lemmas). It does not explicitly mention alternatives or when not to use it, but the scope is evident from the description.

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

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

No annotations are provided, so the description carries the full behavioral disclosure burden. It partially succeeds by stating the return behavior: 'Returns matched=false with the two digests if they diverge.' This gives insight into the tool's output and failure mode. It does not state whether the tool has side effects, but 'check' strongly implies a read-only operation, and the core verification behavior is transparent enough.

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

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

The description is concise and front-loaded, with three short sentences that each add value: what the tool does, what it detects, and what it returns. There is no redundant phrasing or filler.

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

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

Given no output schema, no annotations, and three parameters with nested objects, the description is minimally viable: it clearly states the purpose and the divergent return case. However, it omits parameter semantics, the matched=true return case, and does not provide enough context for an agent to confidently decide between passing a seal object vs a seal_path. It is acceptable but has clear gaps.

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

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

Schema description coverage is 0%, so the description must compensate for the schema's lack of explanations. It mentions 'acceptance specification' and 'seal' generally, but does not clarify the roles of the three parameters (seal, spec, seal_path), which are required vs optional, or how seal_path relates to the seal object. The parameter semantics are severely under-specified.

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

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

The description uses a specific verb+resource construction ('Check that an acceptance specification still matches its seal') and clearly distinguishes itself from siblings like seal_criteria and verify_certificate by focusing on detecting post-sealing changes. It also names the concrete detection scope ('criteria that were changed after sealing'), so there is no ambiguity about the tool's function.

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

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

The usage context is implied through 'Detects criteria that were changed after sealing,' suggesting this is for verifying that a spec has not been modified since it was sealed. However, there is no explicit 'use this when...' statement, no mention of when not to use it, and no alternatives are named among the sibling tools.

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

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

With no annotations provided, the description carries the full burden and does well: it states 'Computes nothing new; it re-presents the arithmetic the verdict already rests on,' disclosing the read-only, non-mutating nature. It could add more about output formatting or errors, but the key behavioral trait is covered.

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

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

Three dense sentences, front-loaded with the core verb ('Explain WHY a certificate reached its verdict'). Every sentence adds value: purpose, usage trigger, and a transparency note. No wasted words.

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

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

Given only two parameters and no output schema, the description is largely complete: it covers purpose, usage timing, and behavioral transparency. The only gap is the unmentioned `bundle_dir` parameter meaning, which is inferable from context but not explicit.

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

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

The schema describes `limit` but not `bundle_dir`. The description indirectly implies bundle_dir is the certificate directory but doesn't explicitly define it. This partial compensation for the 50% schema coverage is adequate but not thorough.

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

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

The description clearly states the tool explains why a certificate reached its verdict, listing specific outputs (safe/unsafe/straddling loci, margins, shortfalls). It also distinguishes from siblings by referencing verify_certificate and REJECT/REFUTED verdicts, making it unique among tools like explain_defect.

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

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

The description explicitly states when to use it: 'Use this after verify_certificate returns REFUTED or a certificate records a REJECT.' It also explains the benefit ('turns an opaque refusal into a specific, actionable list'), leaving no ambiguity about its appropriate context.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It clarifies this is an explanation (non-mutating), details the type of information returned, and documents the effect of omitting the key. It does not describe error handling or return structure, but the core behavior is transparent.

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

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

Two well-structured sentences: the first states the core purpose and output, the second provides a distinct call mode. No wasted words, and key information is front-loaded.

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

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

For a simple tool with one optional parameter and no output schema, this description is sufficient. It states the purpose, the nature of its output, and a special usage mode. It could be enhanced by describing the response format, but the current description covers the essential context.

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

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

Schema coverage is 0%, so the description must illuminate the 'key' parameter. It indicates that providing a key selects a specific defect class and that omitting it lists all defects, which gives meaningful usage context. However, it does not specify the expected format or domain of the key.

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

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

The description uses a specific verb ('explain') with a defined resource ('certificate defect class from the atlas taxonomy') and explicitly describes what the explanation covers ('why the forgery looks valid, and which check catches it'). This clearly distinguishes it from sibling tools like explain_certificate.

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

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

The description provides clear context: this tool is for defect classes in the atlas taxonomy, and it documents the special behavior of calling with no key to list all defects. It does not explicitly mention alternatives or when not to use, but the purpose statement gives enough context to infer appropriate usage.

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

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

With no annotations, the description carries full burden. It discloses the counterexample behavior, receipt output, and size limitations, which are meaningful behavioral traits beyond just 'prove'. It does not mention side effects, but none are apparent for a demonstration prover.

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

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

Three sentences, each with distinct value: action, input/output format, and limitations. No wasted words, and the core purpose is front-loaded.

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

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

For a 4-param tool with no output schema, the description covers key behavioral aspects: equivalence proof, counterexample, receipt, and scope limitation. It does not specify receipt contents, but sibling tools like verify_receipt handle that aspect, so this is acceptable.

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

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

Input schema covers 75% of parameters with descriptions. The description adds context about circuits being gate lists over named signals, which applies to both circuit_a and circuit_b, but does not elaborate on out_path or parameter-specific details beyond what the schema already provides.

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

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

The description uses a specific verb ('prove') and resource ('two small combinational circuits') and clearly distinguishes from sibling certificate-verification tools by stating the core equivalence-checking behavior. It also mentions the counterexample output, which further clarifies the scope.

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

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

Explicitly states size limitation ('Small instances only') and that it is a demonstration prover, not for production. This gives clear guidance on when to use it, though it does not explicitly name alternative tools for larger instances.

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

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

No annotations are provided, so the description must disclose behaviors. It does specify the output (detection, precision, atlas_score, and forgeries that got through), which is useful. But it does not disclose side effects, execution behavior, permissions, or prerequisites, leaving the transparency incomplete for a tool that likely executes a command.

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

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

The description consists of two efficient sentences. The first states the action and target, the second lists the return values. No fluff or redundancy; it is well-structured and front-loaded.

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

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

For a tool with 2 parameters and no output schema, the description is nearly complete: it conveys the purpose, the input (implicitly via 'verifier command' and 'atlas'), and the exact output metrics. It only lacks explicit parameter enumeration and usage scenarios, which are minor gaps.

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

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

The schema covers 50% of parameters: 'command' is described as argv with {path} placeholder, while 'atlas_dir' has no description. The tool description contextually links atlas_dir to the certificate failure atlas but does not explicitly explain its format or role. It adds some context but does not fully compensate for the uncovered parameter.

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

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

The description uses the specific verb 'Score' against a concrete resource (the certificate failure atlas), and explicitly lists the calculated metrics (detection, precision, atlas_score). This clearly distinguishes the tool from sibling verification/explanation tools by indicating an evaluation/benchmarking purpose.

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

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

Usage is implied by 'Score a verifier command against the certificate failure atlas', which suggests using this when evaluating a verifier. However, there is no explicit statement of when to use this tool versus siblings like verify_certificate or check_drat, nor any exclusions or prerequisites.

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

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

With no annotations provided, the description carries the full burden. It discloses key behavioral traits: it returns a digest that commits to criteria without revealing them, and it enforces immutability ('cannot be adjusted afterward'). While it does not cover failure modes or required permissions, it provides substantial behavioral context for a sealing operation.

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

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

The description is two sentences, efficient and front-loaded. The first sentence states the core action and purpose, the second sentence explains the return value and timing. Every sentence earns its place with no redundancy.

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

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

The description explains the core concept and timing well, but is incomplete in crucial areas. It does not explain the return digest format or the parameters, especially the nested spec object and optional note/out_path. For a tool with no annotations, output schema, or parameter descriptions, this leaves the agent with insufficient information for correct invocation.

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

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

The description provides zero information about the parameters. The schema lists three parameters (spec, note, out_path) with no descriptions, and the description mentions none of them. With 0% schema description coverage, the description fails to compensate, leaving the agent without guidance on what to pass for each parameter.

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

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

The description clearly states the tool's action ('Seal an acceptance specification') and its specific purpose (to prevent adjustment after measuring). It also distinguishes itself from sibling tools by emphasizing the pre-measurement timing and the commitment aspect, which is unique among the listed siblings focused on verification and explanation.

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

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

The description provides explicit timing guidance: 'Call this before running an experiment, not after.' This clearly indicates when to use the tool and when not to. However, it does not explicitly mention alternative tools or provide comparative use cases, which would elevate it to a 5.

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

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

With no annotations, the description carries the full burden and does so thoroughly. It discloses the re-derivation approach, integrity checking, the four possible verdicts, the abstention logic when expected_sha256 is missing, and the crucial semantic distinction that UNVERIFIED means 'cannot tell' rather than 'bad'. This goes well beyond a minimal behavioral summary.

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

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

The description is four sentences long, each earning its place. It front-loads the purpose, then efficiently covers the method, return values, and the critical caveat about UNVERIFIED. There is no fluff or repetition.

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

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

For a tool with no output schema, the description lists all verdict values, explains the abstention case, and clarifies how to interpret UNVERIFIED. It is quite complete, though a minor gap exists: the description does not reconcile the existence of accept_without_anchor with the absolute statement that without expected_sha256 the verdict is UNVERIFIED.

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

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

Schema coverage is 75% (three of four parameters have descriptions), and the description adds significant meaning to expected_sha256 by explaining that it is an out-of-band trust anchor and why it is necessary to prevent forgeries. However, allow_empty has no schema description and is not mentioned in the description, and the interaction between accept_without_anchor and the stated 'without expected_sha256 the verdict is UNVERIFIED' rule is left ambiguous.

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

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

The description opens with 'Verify a manufacturing certificate bundle,' which is a specific verb and resource. It goes further to explain the verification method—'re-derives the admission verdict from the certificate's own numbers rather than reading it, and checks integrity'—which clearly distinguishes this from simply reading the stored verdict and from sibling tools like verify_receipt or explain_certificate.

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

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

The description provides clear usage context: it stresses that without an out-of-band expected_sha256 the tool abstains with UNVERIFIED, and it explicitly warns not to report UNVERIFIED as pass or fail. This is strong guidance for when the tool's output is trustworthy, though it does not name alternative tools for specific scenarios.

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

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

With no annotations, the description carries the full burden. It discloses that the DRAT check is re-run, the counterexample is re-simulated, and the hash chain is recomputed, emphasizing that the verdict is re-derived rather than read from the receipt. This builds trust without needing annotations.

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

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

Three concise sentences front-load the purpose, then add process details, and finally emphasize the trust model. No filler or redundancy.

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

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

The tool has one parameter and no output schema, but the description does not state what the tool returns (e.g., a verdict) or how the result is presented. It also lacks guidance on how this differs from sibling tools, leaving some gaps given the complex domain of proof verification.

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

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

Schema coverage is 0% and the only parameter, receipt_path, is not explained in the description. The description refers to 'the receipt' but never clarifies what the path should point to or any constraints, leaving the parameter semantics to the name alone.

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

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

The description opens with 'Verify a logic-equivalence receipt,' which is a specific verb and resource. It clearly distinguishes from siblings like verify_certificate by focusing on receipts, and adds details about re-running DRAT proof checks and recomputing hash chains.

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

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

The description implies when to use the tool (when you have a receipt to verify) but does not explicitly contrast it with alternatives like check_drat or verify_certificate. No when-not-to-use guidance is provided.

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