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

With no annotations, the description carries the full burden and largely succeeds: it lists the report sections, defines DANGLING-DOC and ORPHANED, and notes CLI parity. It does not explicitly state that the operation is read-only or describe error/auth behavior, but 'report' strongly implies a non-mutating check.

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 compact, front-loaded paragraphs: the first defines the report and its categories, the second explains the sole parameter. Every sentence adds information, and the CLI-parity note is a useful behavioral guarantee rather than 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?

The tool is a simple one-optional-parameter report with an output schema, and the description covers the input semantics and report contents well. The only notable gap is the lack of explicit routing guidance versus sibling tools; otherwise the description is complete enough for an agent to invoke it 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?

The schema gives client no description at all (0% coverage), so the description fully compensates by defining it as the owner slug, marking it optional, and specifying both effects: narrowing documents and adding the INCOMPLETE section. This is exactly the semantic enrichment the schema lacks.

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 'Integrity/freshness report' and then enumerates concrete report sections, making the tool's job unmistakable. It is clearly distinguished from the fact-lookup siblings (list_facts, get_fact, search) and needs no inference to understand what it produces.

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 explains the optional client parameter and its effect, but it never explicitly tells an agent when to prefer this tool over list_facts, get_fact, search, or precedents. Usage context is implied by the report nature, but no direct alternatives or exclusions are given.

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 burden, and it does add genuinely useful context by explaining the bitemporal semantics of at and world_at, including an example phrase like 'per what the bank knew on 15 June, what held in May.' However, it does not disclose what happens when at or world_at are omitted (both are nullable with defaults), how missing facts are handled, or any access/error behavior. This is useful but incomplete.

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 output scope and then adds a compact explanation of bitemporality, which is necessary complexity. Every sentence earns its place, though the second paragraph is dense enough that an example input/output pair would have made it clearer without much extra length.

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 there is no output schema and no annotations, the description needs to cover both call semantics and return contract; it covers the return fields and the time-axis model well. It stops short of explaining the default behavior when at and world_at are null, how qname selects the fact uniquely, or what happens when no fact exists, leaving an agent to make reasonable guesses. It is adequate but has clear gaps.

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

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

Schema description coverage is 0%, so the description must compensate, and it does so significantly for the two time parameters. It defines at as transaction time over valid_from/valid_to and world_at as world time over world_valid_from/world_valid_to, giving an agent meaning far beyond the bare schema titles. qname is left implicit by its name, and the null-default behavior is not explained, but the parameter semantics provided are strong where schema coverage is weakest.

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 single fact with full provenance,' which clearly identifies the resource returned and its scope. It lacks an explicit verb like 'retrieve' or 'look up,' and it does not differentiate get_fact from siblings such as list_facts or search, but the 'single fact' framing is specific enough for an agent to infer the core purpose.

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

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

There is no guidance on when to use get_fact versus list_facts, search, precedents, or check. The bitemporal explanation implies when time parameters matter, but the description never states the selection condition (for example, 'use this when you know the qname and need one fact with provenance'). The agent is left to infer usage from the tool name and sibling names.

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 burden of behavioral disclosure. 'List' strongly implies a read-only, non-destructive operation initiated, and the client/status filter is disclosed. However, the description does not mention pagination, ordering, permissions, or any other behavioral guarantees, which keeps it at a moderate score.

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: one clear sentence for the operation, followed by two concise parameter definitions. Every line serves a purpose, with no redundant filler or restatement 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 simple list tool with only two parameters and an output schema, the description is largely complete: it identifies the resource, the required scoping, and the optional filter. It loses one point because it does not clarify when to choose this over sibling tools, but no return-value explanation is needed given the output schema.

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 fully compensates by explaining 'client' as an owner slug with an example, and 'status' as an optional field with an explicit allowed-value list. This adds meaningful semantics that the input schema alone does not provide.

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 ('List') and resource ('the bank's facts and documents') plus the client scoping, making the tool's core purpose clear. It does not explicitly differentiate itself from siblings like get_fact or search, so it loses one point, but the listing operation is distinct enough to be recognizable.

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 explains the parameters but gives no guidance on when to use this tool versus get_fact, search, precedents, or check. There is no mention of when the list behavior is preferable, no exclusions, and no alternatives, so the agent must infer usage entirely from the tool's name and 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?

With no annotations provided, the description carries the full burden. It discloses the semantic closeness behavior and the dual output (decisions and open questions), but does not mention potential side effects, rate limits, or what happens when no precedents exist. Adequate for a read-only tool, but not comprehensive.

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, extremely concise, and front-loads the core purpose before usage guidance. No unnecessary words, and it reads naturally.

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 purpose and when to use it, but omits parameter semantics and the output format. Given no output schema, the agent is left without enough context to correctly invoke the tool with appropriate parameters or interpret results.

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

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

The description provides zero explanation of the query, k, or client parameters. Schema coverage is 0%, so the agent has to infer from parameter names alone. This is a critical gap for a tool with 3 parameters, especially since query is required.

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 returns semantically closest earlier rulings and open structural questions, and frames it as a lookup for prior decisions. It distinguishes from siblings implicitly by focusing on precedent reuse, though it doesn't explicitly name alternatives.

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 instructs to run this before settling a new dilemma and to reuse the rationale if a similar one exists. This gives clear contextual guidance, though it doesn't explicitly mention when not to use or name sibling alternatives.

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 behavioral disclosure. It adds one genuinely useful behavioral trait: the model warm-up performance note ('the first call after the server starts is slower, every later one is instant'). This helps an agent set expectations for latency. However, it does not disclose the return format, error behavior, or result limits beyond the k parameter. Partial but non-trivial 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 compact at roughly 40 words and front-loads the core purpose. However, the flow is disjointed — it jumps from purpose to an implementation pipeline ('mmlw -> reranker') to a parameter explanation to a performance note. The '(mmlw -> reranker)' fragment is cryptic jargon that earns little value for an agent, and the mixing of parameter docs and behavioral notes in one block hurts scanability.

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 4 parameters, 0% schema coverage, and no output schema, the description is incomplete. It clarifies client but leaves query semantics, k's effect on result count, rerank's behavior, and the response shape unaddressed. An agent cannot fully predict how results will be structured or how filtering interacts with the client parameter. Significant gaps remain for a moderately complex search 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?

Schema description coverage is 0%, so the description must compensate. It adds real meaning to the client parameter ('owner slug, or empty for everyone plus global'), which is not derivable from the schema alone. But k, query, and rerank are left entirely to the schema, which at 0% coverage provides no descriptions. The description partially compensates but leaves three of four parameters undocumented.

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 verb and resource: 'Semantic search over facts/documents'. This clearly differentiates from siblings like list_facts, get_fact, and check — search is a similarity lookup rather than retrieval of a specific item. However, it doesn't explicitly name any sibling or say what it is not, and the '(mmlw -> reranker)' implementation detail adds noise without clarifying purpose.

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

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

The phrase 'Semantic search over facts/documents' implies the tool is for similarity-based retrieval, which suggests when an agent would prefer it over list_facts or get_fact. But there is no explicit when-to-use versus when-not-to-use guidance, no alternatives named, and no exclusion conditions stated. The usage context is implied rather than stated.

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