NumProof

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

With no annotations, description fully responsible for behavioral disclosure. It lists what the tool checks but does not state whether it is read-only, what the output format is, required permissions, or side effects.

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?

Single sentence, front-loaded with specific items, no superfluous words. However, it could be expanded to include usage guidance without losing conciseness.

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 only one parameter with no format hints, the description leaves significant gaps in understanding output, error conditions, and prerequisites.

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%, and description only says 'rows' without specifying expected structure (e.g., array of arrays or objects). The description adds no meaningful detail beyond the parameter name.

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?

Description lists specific auditing operations (footing, balance-sheet ties, common margins, cell provenance) on spreadsheet-like rows, clearly distinguishing from siblings like diff_rows (comparison) and verify_claim (claim verification).

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?

Implied usage from the description (audit rows for these checks), but no explicit guidance on when to use vs. alternatives like diff_rows or verify_claim, nor any exclusions.

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?

Without annotations, the description carries full burden but only mentions 'with provenance' without explaining behavioral implications. No side effects, auth needs, or return format are disclosed, leaving significant gaps.

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 short at two sentences, but it sacrifices essential details for brevity. It front-loads the action but lacks structure and completeness.

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 three parameters, no output schema, and no annotations, the description is insufficient. It does not explain return values, parameter formats, or how to choose between rules and rule_pack, leaving the agent with incomplete guidance.

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 description adds minimal meaning. It labels 'rules' and 'rule_pack' as alternatives but does not describe their format or structure, and 'rows' is only vaguely described as 'spreadsheet-like'. The description fails to compensate for the lack of parameter details.

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 evaluates threshold/covenant rules over spreadsheet-like rows, using a specific verb and resource. It distinguishes from sibling tools like audit_rows or diff_rows by focusing on rule evaluation, though it does not explicitly differentiate them.

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 advises using either 'rules' or 'rule_pack', providing a clear usage hint. However, it lacks guidance on when to use this tool versus siblings or context on prerequisites and exclusions.

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 must disclose behavior. It only states 'compare' but does not clarify if the operation is read-only, if it requires permissions, or any side effects. The term 'provenance' is underdefined.

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 a single short sentence, which is concise but severely under-specified. It lacks structure and fails to convey essential information for an AI agent to use the tool effectively.

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?

Despite the tool having two required array parameters and no output schema, the description is extremely incomplete. It does not explain return values, behavior on different inputs, or any handling of edge cases. The mention of 'provenance' is not clarified.

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 input schema has two array parameters with 0% description coverage. The description does not mention the parameters at all, failing to explain their meaning, format, or how to use them. The agent gets no help beyond the schema.

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 verb 'compare' and resource 'report versions' are clear. The mention of 'numeric row labels' specifies what is compared. However, 'provenance' is vague and could be elaborated. It distinguishes from sibling tools like audit_rows or verify_claim.

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 no guidance on when to use this tool versus alternatives. It does not mention prerequisites, when not to use it, or any context for selecting this tool over siblings.

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 must disclose behavioral traits. It states the tool returns VERIFY/REFUTE/ABSTAIN and a counterexample if false, indicating it is a read-only analysis tool. However, it does not disclose potential limitations, error handling, or whether it is destructive, leaving some gaps in transparency.

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 extremely concise, consisting of two sentences. The first sentence defines purpose and output, and the second provides usage context. No unnecessary information is included, making it efficient 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?

Given the tool's simplicity (one parameter, no annotations, no output schema), the description is fairly complete. It explains what the tool does, when to use it, and the general output format. However, lacking details on return value structure or error cases prevents a perfect score.

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 only parameter is 'claim', a string with no description in the schema. The tool description does not add meaning beyond the schema, such as expected format, length, or examples. Schema coverage is 0%, and the description fails to compensate, resulting in weak parameter semantics.

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 purpose: to verify a math/finance claim. It specifies the output labels (VERIFY/REFUTE/ABSTAIN) and mentions providing a counterexample when false. This distinguishes it from its siblings (audit_rows, covenant_rules, diff_rows), which serve different purposes.

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 says to use the tool before trusting AI-produced numbers, sums, percentages, or formulas. This provides clear context for when to use it. However, it does not mention when not to use it or suggest alternatives, so it lacks explicit exclusions.

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