fincon

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

With no annotations provided, the description carries the behavioral disclosure burden. It states that the tool records acceptance under the caller's name, that it writes something, and that it shares refusal conditions with propose_reclassification. It also discloses a meaningful constraint: derived codes cannot be overwritten by a proposed code. It does not cover output shape or permission requirements, but the core side effects and failure conditions are 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?

The description is front-loaded with the primary purpose and is reasonably compact. The extra sentences about same checker, refusals, and derived-code priority add real decision value rather than filler. The metaphorical phrasing 'a guess does not outrank arithmetic' is slightly less direct than the rest, but it does not undermine clarity.

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 tool's role, side effects, and refusal behavior, which covers the core decision of when to use it. However, missing parameter-level guidance for required fields like rationale and run_id leaves an agent to guess at argument semantics. An output schema exists, which reduces the need to describe return values, but the overall definition is only minimally complete for a four-parameter write operation.

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 documenting the four required parameters. It references 'code' and 'exception' contextually, but it does not explain run_id, exception_id, code, or rationale meaning, format, or relationships. The rationale parameter is entirely undiscussed, which is a significant gap for a required field.

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 and resource: 'Accept a proposed code for an exception, under your name.' It also explicitly distinguishes itself from propose_reclassification by naming that sibling and explaining the difference in side effects, so an agent can tell the two apart clearly.

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 situates this tool as the counterpart to propose_reclassification: that tool only asks and writes nothing, while this tool records acceptance. It also says the same checker and same refusals apply, giving an agent useful conditions for when acceptance may fail. It does not explicitly state prerequisites such as 'call propose_reclassification first,' but the intended workflow is strongly implied.

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 burden and does well: it discloses that the output is self-contained, lists what is included, and notes that verification does not depend on internal systems. It does not mention side effects or pagination behavior, but 'export' plus the self-containment statement make the key traits clear.

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 and front-loaded with the value proposition; the second sentence efficiently lists contents and verification behavior. It is concise, though somewhat cryptic and jargon-heavy ('re-derive a close', 'adapter spec ids') which prevents a perfect score.

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 output schema exists, so return-value coverage is not the primary gap. However, the description leaves parameter semantics unaddressed and only implicitly states when to invoke the tool, so an agent would need to infer or guess on run_id and pagination. Acceptable but not 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 0%, and the description provides no explanation of run_id, limit, or offset. An agent must infer that run_id selects the close to audit and that limit/offset paginate results, which is a significant gap the description does not compensate for.

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 identifies the tool as returning a complete audit package for re-deriving a close, and it enumerates concrete contents (proofs, rule versions, approvers, source hashes, adapter spec ids). It is not a tautology and is distinguishable from siblings like get_proof and verify_proof, though it never uses an explicit verb such as 'exports' or 'returns'.

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 phrase 'nothing that requires us' and the assertion that the four how_to_verify steps touch neither our database nor our network give a clear context: use this tool when an independently verifiable, self-contained audit artifact is needed. It does not explicitly name sibling alternatives or exclusions, so it falls short of 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 strongly. It discloses that the operation moves money, removes the item from the worklist, writes double entry, attributes the action to the user, and lists specific refusal conditions including ceiling, budget, taxonomy, and duplicate disposition scenarios.

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 well-structured, front-loaded with the core action, and uses a bolded refusals section to make important constraints scannable. Some rhetorical phrasing such as "none of it from you" adds flavor but not essential information, keeping it from a perfect score.

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 covers the operation's side effects, refusal policy, and the one disposition-specific parameter. It does not explain return values, but an output schema exists. For a financially significant mutation, the provided context is strong, though auth prerequisites or reversibility would improve completeness further.

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 compensate. It adds meaning for disposition by listing valid values and for due_on by specifying format and that it applies only to chase. However, run_id, exception_id, rationale, and owner receive no semantic explanation beyond their names.

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 and resource—"End an exception in a journal entry"—and enumerates the four dispositions. This clearly distinguishes it from read-style siblings like get_worklist, explain_exception, and fetch_records, while also signaling it is a mutating close-out operation.

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 context for when to use the tool: to finalize an exception with a disposition. It does not name sibling alternatives or provide explicit when-not-to-use guidance, but the refusals section and phrase "the item leaves the worklist" make the intended workflow evident.

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 carry the full burden, and it does disclose an important behavioral nuance: E14 unexplained means no strategy matched, and the tool intentionally leaves classification open rather than guessing. It also indicates the tool surfaces evidence, records, and allowed actions. However, it does not state whether the operation is read-only, has side effects, or requires permissions, leaving those to inference from the tool's name and context.

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 and front-loads the core definition in the first sentence. The E14 explanation adds useful intent context about why unexplained exceptions are left open, so it earns its place rather than being pure padding. While the poetic closing line is stylistically extra, it does reinforce a key behavioral trait without bloating the description.

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 output schema covers the return structure, and the behavioral note addresses the main edge case, but the description lacks parameter semantics and usage guidance for choosing between siblings. It relies heavily on domain assumptions about runs, exceptions, and E14 without explaining the inputs. An agent can call the tool only if it already understands the domain and how run_id and exception_id relate.

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 the description never mentions run_id or exception_id. It does not explain what these identifiers refer to, how they relate, or what values are expected. The parameter names are somewhat self-explanatory, but the description adds no semantic meaning beyond the raw schema, which itself has no 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 states 'One exception with its evidence, its records and what it is allowed to do,' which clearly conveys that the tool returns a single exception enriched with supporting material and permitted actions. It is distinguishable from siblings like get_proof and fetch_records, which focus on narrower pieces of evidence. However, it lacks an explicit verb like 'Returns' or 'Explains,' so the exact operation is implied rather than directly stated.

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 domain context about E14 unexplained but gives no explicit guidance on when to use this tool versus siblings such as get_proof, fetch_records, or get_worklist. No conditions, exclusions, or alternative-selection criteria are offered. The only implied use case is 'need details of one exception,' which is not enough to route an agent reliably.

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 behavioral burden. It hints at pagination or batching ('a budget at a time') and notes that the records are 'we handed you,' but it fails to disclose read-only status, authentication requirements, side effects, or result semantics. It is more editorial than informative.

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 text is brief, but brevity is not clarity. The first sentence is an incomplete noun phrase, and the second sentence is a philosophical aside about verification that does not earn its place in a tool definition. The structure is not front-loaded with a clear purpose.

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?

Although an output schema exists, the tool cannot be correctly invoked based on this description: none of the parameters are explained, no usage guidance is given, and the description actively discourages use. For a four-parameter tool with no annotations, this is critically incomplete.

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 four parameters, but it does not. It never explains `source_set`, `limit`, `offset`, or even `loop` beyond the vague phrase 'a loop reads'; 'budget at a time' is the only indirect reference to pagination.

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 first sentence, "The records a loop reads, a budget at a time," is a fragment that vaguely conveys record-fetching for a loop, but there is no explicit verb such as 'retrieves' or 'returns.' The second sentence actively calls the tool 'worth skipping,' further muddying what the tool is actually for and how it differs from siblings.

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 no clear when-to-use guidance and does not name or contrast any sibling tools. It only says it is 'for completeness' and 'worth skipping' for verification, which is an exclusion rather than actionable direction for selecting this tool.

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 burden and does add useful semantics: naming a code grants nothing, only a promoted code may direct a posting, and approvals are re-checked against the policy in force. However, it does not state read-only behavior, permission requirements, or edge-case behavior.

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, all contributing meaningful domain context, with the core subject front-loaded in the first sentence. It is somewhat dense but not wasteful.

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?

An output schema exists, so return values do not need to be spelled out, and the description covers non-obvious domain rules. Still, it lacks explicit usage guidance, operational side-effect or permission notes, making it only moderately complete for an unannotated tool.

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 single 'loop' parameter is only implicitly described as the loop whose authority is being inspected. With 0% schema description coverage, the description partially compensates by indicating that the parameter identifies a loop, but it omits format, accepted values, and any relation to loop identifiers from sibling tools.

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 identifies the resource as 'policy, vocabulary and promoted rules governing a loop' plus signer information, and the tool name supplies the 'get' verb. It is clear about the subject but does not explicitly distinguish itself from siblings like get_proof or get_contracts.

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 is given about when to use this tool versus alternatives such as get_proof, get_close, or get_worklist. The description provides domain context but no conditions, prerequisites, or explicit 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 carries full behavioral burden. It discloses the unusual 'absent rather than zero' semantics for blocking recall and explains why (production lacks labelled pairs), preventing a misinterpretation. It also clarifies that the detail parameter is a projection that changes response size, not content. No contradictions.

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 somewhat long but every sentence adds value: the blocking-recall caveat is critical for accuracy, and the detail explanation is essential for correct invocation. It is front-loaded with the core purpose and then elaborates on key nuances, avoiding fluff.

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 provides all necessary details for correct invocation: what the return contains, the behavior of the detail parameter, and the alternative tool for proofs. An output schema exists, so return structure is already defined elsewhere. No critical information is missing.

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. It thoroughly explains the detail parameter's effect (summary vs. full, ~59 KB) and that it is a projection. run_id is not described but its name is self-explanatory and it is a required identifier, which is acceptable given the context.

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 the tool returns 'a recorded close, rebuilt from its decision log' and enumerates the specific data it conveys: match rate with tier splits, proof-tier split, blocked/waiting-on-human items, the authority it ran under, and whether the signature held. It explicitly names get_proof as the sibling for reading individual proofs, which differentiates it from that alternative.

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 explicit guidance on the detail parameter, explaining that summary is the default and that get_proof should be used to fetch a specific proof, thereby directing the agent when to use this tool versus that sibling. It does not specify when to use this over other siblings like list_runs, but the core purpose is clear enough 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 provided, the description carries the behavioral disclosure burden. It adds meaningful context: the contracts are public, semver'd, and immutable in the sense that a field change becomes a version bump rather than an edit. However, it does not explicitly state that the tool is read-only or describe what a caller receives, leaving some behavior to inference from the name.

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 and front-loaded with the core resource: the JSON Schema for public shapes. The ADR-002 rationale earns its place by explaining why versioning is strict, which helps an agent understand the compatibility contract without adding noise.

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 zero-parameter tool with an output schema, the description is largely sufficient. It tells the agent what domain shapes are covered and why the versioning behavior matters. Minor ambiguity remains around whether the tool returns the current schema set or a specific version, but the low complexity and presence of an output schema keep this from being a significant 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?

The tool has zero parameters and the schema coverage is effectively complete, so there is nothing the description needs to explain about inputs. The baseline of 4 applies because no parameter documentation burden exists.

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 identifies a specific resource — the public, semver'd JSON Schema contracts for Record, Proof, Policy, and Event — and explains their purpose. The active verb is only implied by the tool name 'get_contracts', and it does not explicitly differentiate this from sibling tools like get_events or get_proof, though the content makes the distinction fairly clear.

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 use case is implied: another system can build on these published contracts. However, there is no explicit statement of when to use this tool versus alternatives, no exclusions, and no mention of prerequisites. It gives context but stops short of actionable routing guidance.

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 behavioral burden, and it delivers: it explains append-only semantics, how edits/reorder/truncation are detected, the custody limitation, and the paging/total semantics. It gives a concrete size example and clarifies that 'total' distinguishes a full log from a partial page. This is strong, non-obvious behavioral disclosure.

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 around 100 words and each sentence adds substance, with the core concept front-loaded. The opening is a noun phrase rather than a clear verb-led statement, and some phrasing is ornate, but there is little wasted text.

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 behavioral and pagination context is valuable, but the tool has three parameters, one required, with zero schema documentation and no usage guidance. An agent still lacks the information needed to call it correctly, especially what run_id should be and how limit/offset map to paging.

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, but it never defines run_id, limit, or offset. The paging discussion implies limit/offset exist, and 'total' clarifies an output field, but an agent cannot determine what run_id refers to or how offsets behave from the description.

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 resource as the 'typed decision log' and explains that it returns events in hash-chained order. It references verify_journal, which helps distinguish this from verification tools, though it does not use an explicit verb like 'retrieve' or 'list' and does not differentiate from other list/get siblings such as list_runs or fetch_records.

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?

There is no explicit guidance on when to use get_events versus alternatives. verify_journal is mentioned, but only to explain what happens when the hash chain is broken; the description does not state when to choose get_events over list_runs, audit_export, or other 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, the description carries the behavioral burden. It discloses a non-obvious trait: the subtotals are claims, not verified facts, and may be rejected by verify_proof if they do not reconcile. This goes beyond the schema and helps the agent understand the data's trustworthiness.

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, front-loaded with what the tool returns, and every sentence adds useful context. The wording about claims and verify_proof is distinctive without being verbose.

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 output schema covers return structure, so the description need not repeat it. The tool's workflow position, contents, and data-reliability caveat are all present. It could have mentioned where run_id and match_id originate, but that is a minor gap given the clear identifiers.

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 should compensate. It implies that match_id selects a match and run_id scopes that match, but it does not explicitly explain how the identifiers relate or where they come from. The names are self-evident, but the description adds only marginal direct parameter meaning.

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 ('get') and resource ('one match with its full proof'), and enumerates the contents: every leg, record ids, and subtotal. It also distinguishes itself from verify_proof by positioning itself as the pre-verification read step.

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 frames when to use this tool: 'What a verifier reads before calling verify_proof.' It also contrasts with verify_proof, making the workflow ordering clear. This is strong usage guidance relative to the large sibling set.

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 useful non-obvious behavior: the ranking formula, owner routing, and the note attached to non-ratified codes. However, it does not explicitly state read-only semantics, pagination, or limits, though these are less critical for a get-type 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 compact and front-loaded with the essential ranking and routing facts. The middle sentence 'This is the tail, and the tail is the product' is stylistic rather than actionable, but it does not substantially bloat the definition.

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?

An output schema exists, so return format details are covered elsewhere. Still, run_id is left undocumented, 'owner' is unexplained, and there is no mention of pagination or usage prerequisites. This is adequate for a high-level read tool but leaves operational 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 has one required run_id parameter with 0% description coverage, and the description never mentions run_id, how to obtain it, or what it refers to. The parameter name is mildly self-explanatory, but the description adds no semantic value and does not compensate for the coverage gap.

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 resource as 'the exception queue' and specifies its defining characteristics: ranked by cash impact x age and routed to an owner. This is specific enough to separate it from the per-exception sibling tools, though it relies on the tool name to supply the verb.

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 is given about when to use this tool instead of alternatives such as explain_exception or dispose_exception. The phrase 'the tail is the product' conveys philosophy but not actionable selection criteria or 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 carries the full behavioral burden. It discloses that loops carry policy, taxonomy, strategy order, source files, and promoted rules, and warns that semantic terms like 'side,' 'counterparty,' and 'tolerance' are loop-defined rather than hardcoded. This goes beyond a simple list operation and helps the agent understand why the output matters.

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 concise sentences with no wasted words: it states the resource, summarizes the payload, and gives a clear usage directive. The long second sentence is dense but justified because it enumerates the meaningful contents of each loop.

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 no-parameter listing tool with an output schema present, the description is complete. It tells the agent what the tool returns, why the content matters, and when to use it relative to close operations. Nothing needed for correct invocation is missing.

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 zero parameters, so the baseline is 4. The description adds no parameter-specific information, but none is needed because the tool takes no inputs.

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 identifies the resource as 'the reconciliation loops this controller can close,' which is specific and clearly scoped. It lacks an explicit verb like 'list' or 'returns,' though the tool name supplies the action. It distinguishes the resource from sibling list tools like list_runs and list_source_sets.

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 explicit timing guidance: 'Read it before asking for a close.' This tells an agent when the tool should be invoked relative to close-related operations. It does not name alternative tools or exclusions, but the context is sufficient for a no-parameter list operation.

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 full behavioral burden. It does add meaningful behavioral detail: run ids are deterministically derived from source bytes and the authority in force, and re-closing identical inputs under an unchanged policy reuses the id instead of duplicating the record. However, it does not disclose whether closing is irreversible, what side effects occur, or what the output represents.

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 and free of filler, and the second sentence is informative. However, the first sentence is grammatically awkward ('Closes already recorded, by run id') and structurally front-loads an unclear claim. It is concise but not cleanly structured enough to earn a higher score.

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 parameters and an output schema, the description still fails to state what list_runs actually returns or how it should be invoked. The mismatch between the tool name and the described behavior leaves a critical gap: the agent cannot know whether this tool lists runs, closes runs, or does something else. It also provides no context relative to sibling tools.

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 zero properties, yet the description repeatedly refers to 'run id' and 'identical inputs', implying parameters that do not exist. This confuses invocation rather than clarifying it. The description adds conceptual detail about id derivation, but no usable guidance on what arguments to provide or how to supply them.

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?

Despite using a specific verb ('Closes') and resource ('already recorded'), the description directly contradicts the tool name 'list_runs' and makes no mention of listing. This is misleading: an agent selecting by name would expect a listing behavior, and the description appears to describe a closing operation (likely belonging to the sibling 'run_close').

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 suggests using the tool 'to close already recorded' items, but gives no guidance on when to prefer this tool over alternatives like run_close or get_close. It also fails to explain any exclusions, prerequisites, or conditions. The only implicit context is that it operates on already-recorded runs by run id.

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 burden, and it does disclose important behavior: it lists both complete and incomplete sets, names missing filenames for incomplete ones, and warns that a close over an incomplete period would be refused. It clearly explains that the useful answer for a short month is a list showing the missing file, not an empty list. Some behavioral details (e.g., whether this mutates anything, exact output format) are missing, but the disclosure is informative.

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 front-loads the core purpose in the first sentence, then expands on the important edge-case behavior. It is not bloated. The phrasing is a bit oblique ('Which periods'...' as a fragment) but overall it earns its sentences.

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 gives a good sense of output semantics (complete/incomplete, missing filenames, refusal of close over incomplete data), and there is an output schema present, which may carry return-value details. However, with no annotations, no parameter semantics, and no explicit statement about whether this is a read-only inspection tool (likely, but unstated), an agent has a moderate gap. For a one-parameter list tool with an output schema, this is just adequate.

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 the description never mentions the 'loop' parameter. The only parameter is required, but an agent is given no semantic clue what a 'loop' is in this domain. The description would need to at least tie 'loop' to a period identifier or scope to make the tool callable with confidence.

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 names the resource (source sets for periods) and the key behavior (listing which periods' source files are on disk, complete or not), but it uses the informal phrase "Which periods' source files are on disk" rather than a direct verb like 'List'. The sibling set includes list_runs and list_loops, so the period/source-set scope does help distinguish it. However, the intended operation is somewhat implied rather than crisply stated as 'List the source sets for each period'.

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 second part explains a subtle usage context: incomplete periods are listed with missing filenames, and a close over a half-arrived period is refused, so the tool's output provides the diagnostic answer rather than an empty list. This implicitly tells the agent when to use it (when investigating whether periods' source data is complete, e.g., before closing) and what to expect. It does not explicitly name alternatives or say 'use X instead', but the context is reasonably clear.

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 and succeeds: it explicitly says 'Nothing is written', enumerates the validation checks, discloses the derived-E09 refusal rule, and clarifies that admissible: true means well-formed/permitted, not correct. This is rich behavioral context beyond the schema.

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 front-loaded with the core purpose, then proceeds through side-effect, validation, refusal, and verdict semantics, finally routing to the sibling. Each sentence adds distinct information; the only mildly explanatory backstory ('which is the rule that stopped a model...') earns its place by making the refusal rule meaningful.

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 five required parameters, zero schema descriptions, and no annotations, the description is nearly complete: it covers side effects, validation constraints, verdict meaning, and the next action. It falls just short only in not clarifying run_id's role and leaving evidence string format to inference.

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. It adds meaning for code (must resolve and be assignable), hypothesis (must exist), evidence (must cite a record the exception names), and exception_id (via the exception's label), but run_id is never explained. This is substantial but incomplete compensation.

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 and object — 'Ask whether a proposed code for an exception would be admissible' — and immediately distinguishes itself from the write path by noting 'Nothing is written' and pointing to accept_classification as the action that makes the proposal real. This leaves no ambiguity about what the tool does or how it differs from its siblings.

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 states the tool is a non-mutating check and tells the agent the follow-up operation: 'Making it so is accept_classification', which writes under the credential. It also names when the proposal will be refused (e.g., derived E09 outranks it), giving concrete selection and exclusion criteria.

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 behavioral burden and exceeds it. It reveals that the operation is memory-independent, and it explains the three failure modes (sources_match, refuted, missing_proofs) including that missing_proofs deliberately does not pass.

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 core purpose is front-loaded in the first sentence, and the following paragraphs earn their place by covering provenance and failure-mode semantics. There is no 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?

For a 2-parameter audit-style tool with an output schema, the description provides what an agent needs to call it correctly: what it does, why it is auditor-equivalent, and how to interpret its distinguishable failure outcomes.

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. It contextualizes source_set as source files on disk and run_id as the recorded close, but it never explicitly maps either parameter or gives format/constraint details beyond the bare 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 opens with a specific verb and resource: 'Re-derive a whole recorded close from the source files on disk.' It then names the concrete steps—re-ingesting sources, checking sha256, re-deriving proofs—which clearly separates it from sibling get/verify/run tools.

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 gives clear context: this is the same thing an outside auditor does, done on demand, because nothing is read from process memory. It does not explicitly name when to prefer it over siblings like run_close or verify_proof, nor state exclusion conditions, so it stops short of 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 fully carries the burden, and it does so richly. It discloses that the tool writes postings and a decision log, that decisions are governed by pre-signed bundles, that failed re-derivation causes matches to be dropped with refusals recorded, and that the return value reflects the actual decision-log contents. This is far beyond minimal 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 front-loaded with the purpose, then adds constraints and behavioral guarantees in a logical order. Despite being longer than average, every sentence adds meaningful information; none of it is filler or repetition of the schema.

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 tool with no annotations, the description gives strong behavioral context, return-value provenance, and constraint details. It is slightly incomplete on parameter semantics and does not point to list_loops/list_source_sets for discovering valid inputs, but the existing output schema and the behavioral detail cover most of what an agent needs to use it safely.

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 compensate, but it does not define loop or source_set or explain how valid values are obtained. It says the caller chooses 'which loop and which period,' yet the schema parameter is source_set, not period, which may create ambiguity about what source_set represents. The only helpful semantic point is that there are no other optional parameters.

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 opening line 'Close one period: match, verify, post, record' is a specific verb plus resource and names the full operation pipeline. It distinguishes run_close from siblings like run_match (which only matches) and get_close (which returns a close), so an agent can understand what this tool is for without inspecting other definitions.

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 states the tool's scope: a caller picks 'which loop and which period and nothing else.' It also explicitly excludes other kinds of behavior ('no policy argument, no tolerance, no rule set') and notes that tolerance cannot be widened here. It does not name sibling alternatives, but it gives enough context to know when this tool is appropriate.

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 it delivers: it states no side effects, enumerates what the response contains (proven matches, full proofs, refused items, exceptions), explains that records are not inlined and why, and documents pagination via match_page.next_offset and total. It even discloses that this call is not evidence of honesty.

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 key purpose is front-loaded in the first two sentences, and later paragraphs add genuinely useful behavior and warning context. It is longer than strictly necessary, with some repetition of the no-posting/no-close idea, but each section earns its 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?

Given that the output schema exists and the description covers side-effect profile, response contents, pagination, and alternatives, the tool is largely callable in context. The main gap is the undocumented input parameters, which is reflected in the parameter-semantics score; this keeps it from a perfect completeness 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?

Schema description coverage is 0%, so the description must compensate, but it never explicitly maps loop, source_set, limit, or offset to their meanings. "One period" hints at loop and "source files" hints at source_set, but limit/offset are left wholly to inference, and the pagination discussion is about the output cursor rather than the input parameters.

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 opening line states a specific verb ("Match"), a scoped resource ("one period"), and the deliverable ("return the proofs"), then rules out side effects with "no posting, no ledger, no log." It also names verify_proof as a sibling with a different goal, so the tool is distinguishable from the close/verify family.

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 explicitly frames the use case: "for a caller that wants to check our arithmetic rather than have us close the books." It also gives an alternative and a when-not-to-trust directive: use verify_proof to prove honesty, since run_match's own output is not that proof.

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 behavioral burden and mostly meets it: it discloses that the action is terminal, that refusals apply regardless of caller, and that the action records that an agent supplied the signature. It does not specify error behavior or reversibility, but 'terminal decision' covers the essential risk.

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 core statement is front-loaded and the total length is modest, but the prose is intentionally florid. Phrases like 'the strongest claim here' and 'that is not a hedge against you' add tone rather than necessary operational detail, so not every sentence earns its 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?

The description provides useful behavioral context—preconditions, finality, audit logging—and an output schema covers return values. However, it is thin on parameter semantics and does not describe the exact workflow from receiving a close to accepting it, leaving a capable agent to infer part of the process.

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 the description never mentions run_id or note, let alone what run_id identifies or how note is recorded. The only contextual link is 'the close,' which is too indirect to supply meaning for the parameters.

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 'Accept the close,' a clear verb and resource, and reinforces it with 'terminal decision' to communicate finality. This distinguishes the tool from siblings like run_close or get_close, though it never defines what a 'close' is.

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 gives explicit preconditions: 'read the worklist first' and three binding refusals that an agent cannot bypass. It does not name alternative tools directly, but the worklist instruction clearly points to the get_worklist sibling and the refusals tell the agent when not to sign off.

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 of disclosing behavior. It does this well by explaining that the terminator's counts and decisions are writer claims checked against the stream, and it highlights the subtle truncation caveat. It still does not mention whether the operation is read-only or what happens on invalid chains, 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?

The description is two sentences with no filler. The first sentence front-loads the operation, and the second sentence earns its place by explaining why the terminator exists and why truncation alone is insufficient. Well-structured and efficient.

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 core logic is well explained, and since an output schema exists, the return value does not need to be described. However, the single input run_id is not explained, and there is no guidance on how this tool relates to sibling verification tools, leaving a meaningful contextual gap for an agent deciding how to use it.

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 the description does not mention run_id at all. The only parameter's meaning, format, or relationship to the decision log is left entirely to the schema, which only says it is a required string. The description adds no value beyond the input schema for 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 opens with a specific verb ('Check') and a specific resource ('a decision log's hash chain and its terminator'), which makes the tool's purpose immediately clear. It explains the terminator's role, but it does not explicitly distinguish itself from sibling tools like verify_proof, so it stops short of a 5.

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: the tool should be used when you need to verify a decision log's hash chain and terminator claims. However, there is no explicit 'when to use / when not to use' guidance, and no alternative tools are named, leaving an agent to infer when verify_journal is preferable to siblings such as verify_proof or reverify_close.

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 of behavioral disclosure, and it does so thoroughly. It reveals that the tool is stateless, trusts nothing, reads no stored residual, derives sign convention from policy, refuses proofs above the tolerance ceiling, refutes proofs referencing missing records, and stamps caller-supplied verdicts so they cannot be misattributed.

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 long but information-dense, with the core purpose and key behavioral traits front-loaded in the first line. Every paragraph earns its place: policy selection, trust posture, verdict stamping, and workflow all serve the agent's decision-making without fluff.

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 complex tool with nested objects and a low-schema-coverage input, the description is remarkably complete. It covers what the tool recomputes, how it treats missing records, the policy/loop exclusivity, the verdict's caller-supplied marker, and the intended workflow via audit_export — leaving little for an agent to infer or get wrong.

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 low (25%), so the description must compensate, and it largely does. It explains the meaning and relationship of proof and records ('fetches each record by id... compares against what the proof claims'), and it gives crucial semantics for loop vs. policy, including the exactly-one rule and absence of a default.

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 and resource: 'Re-derive one proof from records you hold.' It then clarifies the verification mechanism — recompute subtotals and residual from fetched records and compare against the proof's claims — which makes the tool's purpose unmistakable and distinguishes it from close-level or journal-level checks among the siblings.

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 gives clear, practical usage context: this is the way to 'check our work without trusting us,' and it tells the caller to pull a proof from audit_export and ingest source files. It also explains the loop-or-policy choice. However, it does not explicitly mention when to prefer an alternative sibling tool or when not to use this tool.

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