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

With no annotations, the description carries the full burden and does well: it discloses Ed25519 signing, hash-chaining, three fixed outcomes, no forced guess, and the free tier. However, it doesn't mention the public reputation-ledger side effect (only in schema) and lists 'multi-exchange price consensus' as a ground-truth source that is unsupported by the resolver enum, creating a mild inconsistency.

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 front-loaded sentences with no waste. The main action and return value lead, and the signing/hash-chaining and free-tier notes are useful context that earns their place.

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 lacking an output schema, it clearly states the possible return values and key behavioral guarantees. It could add handling for invalid resolvers or the public-ledger effect, but for a 3-parameter tool the description is substantially 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 100%, so the baseline is 3. The description adds no parameter-level insight beyond the schema; the claim example already lives in the schema, and the resolver list mismatch introduces confusion rather than clarity.

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?

States a specific action (submits a claim) and a specific return (signed verdict), and enumerates external ground-truth sources. It does not explicitly differentiate from sibling verify_receipt, but the scope is clearly claim veridication against real-world evidence.

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?

No guidance on when to use this tool vs siblings like verify_receipt, file_dispute, or screen_entity. It implies claims need external ground truth but provides no exclusions, prerequisites, or alternative routing.

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 discloses the paid nature, the exact price, the payment method, the signing mechanism, and the behavior when payment is absent. It does not describe rate limits or failure modes beyond the payment requirement, but the disclosed behaviors are substantial and specific.

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 compact and information-dense, with every sentence earning its place. It front-loads the core purpose, then adds validation metrics, payment terms, and the no-payment behavior in a logical order.

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 paid single-ticker scoring tool with no output schema, the description covers the essential operational details: what it computes, how it is validated, what it costs, how to pay, and what happens without payment. It does not describe the response format, but the absence of an output schema and the clear payment behavior make the description reasonably 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 description coverage is 100%, so the schema already documents both parameters. The description adds context for 'ticker' by giving an example and for 'agent' by explaining it appears on a public reputation ledger, which is useful but not a major addition 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 description states a specific verb ('computes'), a specific resource ('Altman Z-score from live SEC XBRL filings'), and a clear scope ('for a single equity ticker'). It also distinguishes itself from siblings by emphasizing the paid, signed distress-foresight score rather than a generic screen or verification tool.

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 clearly explains the payment requirement and the consequence of calling without payment, which is essential usage guidance. It does not explicitly name alternative tools for when not to use this one, but the sibling list and the phrase 'single equity ticker' imply the scope boundary.

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 burden. It discloses that this is an independent re-run rather than a re-vote, that an upheld dispute overturns the verdict and queues a slashable payout against the notary's bond, and that unpaid calls return only the payment requirement. This is strong behavioral disclosure for a paid, consequence-bearing mutation tool.

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 dense sentences with no repetition or filler. It front-loads the core action, then layers mechanics, consequences, cost, and the no-payment response behavior efficiently.

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 annotations and no output schema, the description covers most essential context: cost, payment protocol, re-resolution semantics, and outcome of an upheld dispute. It explicitly describes the unpaid-call response but does not state what a successful paid call returns, which is a minor gap.

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?

Both parameters are fully described in the schema (100% coverage), so the baseline applies. The description adds no new parameter-level detail beyond what the schema already states; the 48-hour constraint and public-ledger visibility are already present in the schema descriptions.

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 a specific verb ('Files') and a clear resource ('a bonded dispute against a verdict receipt'), then explains its unique mechanics: re-resolution against the identical resolver spec, not a re-vote. This clearly distinguishes it from sibling tools like verify_receipt or claim_verdict.

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 context for use is clear: to dispute a verdict receipt under 48 hours old, with an attached x402 payment. It notes there is no free tier and explains the unpaid-call behavior, but it does not explicitly compare to sibling tools or state when not to use it.

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 it does this well: it discloses the exact cost, the payment chain and protocol, the absence of a free tier, the behavior when payment is missing, the Ed25519 signature, and the source_as_of freshness timestamp. This is far beyond a minimal description.

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 three tightly packed sentences: purpose, cost/payment protocol, and unpaid behavior. It is front-loaded with the core purpose and contains no filler or redundant restatements of the tool name.

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 two-parameter paid screening tool, the description covers purpose, cost, payment requirement, unpaid response behavior, response freshness, and signing. It does not detail the exact success verdict shape, and there is no output schema, but enough is provided for an agent to invoke the tool correctly.

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 100%, and both parameters are already well described in the input schema: 'agent' identifies the caller and 'entity' is the legal name to screen. The description does not add meaning beyond what the schema already provides, so the baseline of 3 is appropriate.

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 a specific action ('matches a legal name') against a specific resource (the OFAC Specially Designated Nationals list). This distinguishes it from siblings like file_dispute and verify_receipt, 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 gives clear invocation context: this is a paid tool with no free tier, and a call without an attached x402 payment will return the payment requirement instead of a verdict. It does not explicitly name alternatives or state when not to use it, but the payment prerequisite is clearly communicated.

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 burden. It explicitly states the operation is read-only, free, and requires no auth, which is essential behavioral context. It also discloses what verification entails (hash chain and signature). It does not describe the return format, but that is a minor gap for such a simple tool.

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, dense sentence that front-loads the core purpose, then adds the verification details and operational traits. Every clause earns its place with no filler 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 one-parameter, read-only verification tool, the description covers purpose, verification mechanism, and operational constraints. It lacks an explicit statement of what the tool returns, but the absence of an output schema and the verb 'confirms' make the intended result reasonably inferable.

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 100%, and the parameter schema already explains that hash is the receipt_hash returned by claim_verdict or commit. The description adds only 'by its hash,' which reinforces but does not meaningfully extend the schema's parameter documentation. Baseline 3 is appropriate.

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 ('verifies') with a specific resource ('StillOS notary receipt') and names the exact mechanism (hash chain integrity + Ed25519 signature validity). This clearly distinguishes it from siblings like claim_verdict or file_dispute, which perform different actions.

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 makes the use case clear: verify any notary receipt independently by its hash. It also references receipts returned by claim_verdict or commit in the parameter schema, grounding when the tool is relevant. It does not explicitly list exclusions or alternatives, but the context is sufficient for a single-purpose verification tool.

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