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

With no annotations, the description carries the burden of explaining behavior. It communicates that the tool performs an audit and lists the anomalies detected, implying a read-only operation, but it doesn't explicitly state that it does not modify data, how failures are surfaced, or what the output contains beyond what the output schema already captures.

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?

A single, front-loaded sentence that states the action, target, and key detection cases with no filler. Every clause contributes to understanding the tool's 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?

The tool is simple and has an output schema, so the description doesn't need to explain return values. However, missing tenant_id semantics and the absence of guidance about when the audit is appropriate leave notable gaps for an agent deciding how to call 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?

Schema description coverage is 0%, and the description does not explain what tenant_id actually does. The mention of 'null tenants' refers to an anomaly type, not the parameter's filtering semantics, so an agent cannot tell whether providing tenant_id scopes the audit or how it changes results.

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 ('Run') and resource ('database consistency audits') and then enumerates what the audit detects. This makes its purpose concrete and clearly distinguishes it from siblings like health_check, which likely targets system health rather than data integrity.

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 guidance on when to run the audit versus alternatives, nor when to omit or provide tenant_id. It implies a data-integrity use case through the listed checks, but leaves the caller to infer the appropriate context and does not mention any exclusions or 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 present, so the description carries the full behavioral burden. It does disclose one meaningful side-effect constraint—'without persisting audit logs'—but it does not explicitly state whether the tool is read-only or whether it executes a live retrieval with its own cost/latency. This is partial transparency, not complete.

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 core purpose in the first sentence and an important no-audit-log caveat in the second. The slight overlap between 'diagnostic tracing and candidate scoring explanations' and the subsequent enumeration of those components is acceptable and 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?

With five parameters, zero schema parameter descriptions, and no annotations, the description is incomplete as an operational contract. The output schema likely covers return structure, but the agent still lacks essential guidance on how mode, tenant_id, and source_type change the behavior of the 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%, yet the description adds no meaning for any of the five parameters. It never explains how mode, top_k, tenant_id, source_type, or query_text affect the diagnostic output; it only describes what is returned, leaving the agent to guess parameter behavior.

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 names a specific verb-resource pair: 'Return diagnostic tracing and candidate scoring explanations for a query.' The second sentence enumerates concrete outputs (candidate counts, per-leg latencies, fusion scores, degradation status), which clearly distinguishes this from sibling tools like retrieve_evidence or health_check.

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 diagnostic framing implies when the tool should be used, but the description never explicitly says 'use this when you need to explain or trace retrieval, not when you need actual evidence.' It gives no alternatives or when-not conditions, so an agent must infer the intended selection.

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?

Tool has no 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?

Tool has no 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?

Tool has no description.

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?

Tool has no 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?

Tool has no description.

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?

Tool has no description.

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

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

With no annotations, the description carries the full burden for behavioral disclosure. It does state that the operation is a fetch (implying read-only) and that results are scoped to tenant, which is useful. However, it does not explain what happens when the chunk_id is not found, whether tenant_id is required for scoping despite its default null, or any permission constraints.

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, compact sentence that front-loads the action and key identifiers. Every phrase contributes meaning, and there is no redundant or filler content. It is an example of efficient, well-structured documentation.

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 presence of an output schema covers return values, so the description does not need to detail them. What is missing is guidance on when to use this tool versus the closely named sibling retrieve_evidence, and any clarification of optional tenant scoping. For a simple get-by-id tool it is mostly adequate, but it leaves minor usage context 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. It does add meaning by clarifying that chunk_id is an integer ID for an evidence chunk and that tenant_id relates to tenant scoping. However, it omits the optional/nullable nature of tenant_id and does not specify how the scoping behaves when tenant_id is null, leaving important semantic details uncovered.

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 ('Fetch') with a clear resource ('specific evidence chunk') and an unambiguous identifier ('integer chunk ID'), plus scoping ('scoped to tenant'). It effectively conveys the core operation, though it does not explicitly name or contrast sibling tools like retrieve_evidence, so differentiation relies on the phrase 'by its integer chunk ID'.

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

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

The description provides no explicit guidance about when to use this tool versus retrieve_evidence or other siblings, and it does not state any exclusions or prerequisites. Usage is only implied: if you have a chunk ID and need that chunk, you might call this. No alternatives or contextual cues 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?

No annotations exist, so the description carries the disclosure burden. It does reveal useful behavior: the result includes counts, sources, and storage status, and scoping is conditional on tenant_id. However, it does not state whether the operation is read-only, what side effects may exist, or whether special permissions are needed.

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 tightly written sentences with zero filler. The core action and return contents are front-loaded, and the scoping note is a separate, clearly stated condition.

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 single-optional-parameter diagnostic tool with an output schema, the description is largely complete: it states what is returned, the main parameter's role, and the scoping behavior. It lacks usage guidance relative to siblings, but that is already penalized in dimension 2.

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 does so by explaining that tenant_id is a scoping filter: 'Scoped to tenant_id when provided.' This adds real meaning beyond the schema's bare type/default, though it could specify how the scope is applied.

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: 'Return diagnostic index breakdown' and enumerates concrete contents (document/chunk counts, sources, storage status). This distinguishes it from siblings like health_check and list_sources, which are broader or differently scoped.

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 choose this tool over siblings. The only additional sentence, 'Scoped to tenant_id when provided,' describes filtering behavior, not usage context or alternatives. An agent is left to infer when this is the right diagnostic 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 behavioral disclosure burden. It openly states that counts are approximate and that the tool reports DB connectivity and runtime configuration, which is useful. It does not explicitly state that the operation is read-only or describe any side effects, though the name and purpose strongly imply a safe, non-mutating probe.

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: the first sentence states the main action, the second details the returned information, and the third gives the intended use case. Every sentence adds value and there is no redundant or filler content.

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 health check with an output schema, the description is complete: it states what the tool does, what it returns, and when to use it. The agent can correctly select and invoke this tool without needing additional context.

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

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

The tool has zero parameters, so the empty input schema fully covers invocation needs and no parameter documentation is required. The description adds no parameter semantics because there are none, and the baseline for zero-parameter tools is appropriately high.

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 a specific action and resource: checking server health and returning runtime configuration. It also frames the tool as a pre-query orientation step, which separates it from retrieval-focused siblings like retrieve_evidence and get_document. However, it does not explicitly differentiate itself from get_index_status, whose name also suggests a status-checking role.

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 says the tool is useful for AI agents to orient themselves before querying, giving a clear context for when to call it. It does not name alternative tools or state exclusions, but for a zero-parameter health check that is a minor gap.

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 behavioral burden. It discloses that the tool returns distinct source_type values with counts and that results are scoped to tenant_id when provided. This is enough for a read-only metadata listing, though it does not cover edge cases like empty results or permission requirements.

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 verb and resource. Every sentence adds necessary context: what is returned, why an agent would call it, how to apply the result, and how the optional parameter behaves.

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 one optional parameter and an output schema, the description is complete. It explains purpose, usage, return content, and parameter behavior, leaving no critical ambiguity for an agent deciding whether and how to call 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%, so the description must compensate. It does by explaining that tenant_id scopes the results when provided, adding behavioral meaning beyond the raw schema. It does not detail the parameter type or omission behavior, but the schema and the phrase 'when provided' make the optionality clear.

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 and resource: it lists ingested source types and document counts for a tenant. It distinguishes itself from retrieval tools by noting the purpose is discovery before querying and names retrieve_evidence as the downstream consumer.

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 when to use the tool: before issuing a query, to discover available content domains. It also tells the agent how to use the returned source_type values with retrieve_evidence. It does not list exclusions or compare against all siblings, but the context is 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 must carry the behavioral disclosure burden. It adds useful behavior-related details about retrieval modes ('hybrid', 'lexical', 'vector') and scoping via tenant_id and source_type. However, it does not explicitly state the operation is read-only, mention auth requirements, or disclose rate limits or side effects, so it is adequate 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 compact and well structured: a one-sentence purpose statement followed by a scannable parameter list. Every line adds useful information and there is no filler or redundancy.

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

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

Given the tool's complexitycars, an output schema exists and parameter semantics are fully documented, so the calling contract is largely complete. The main gap is the absence of guidance on how this tool relates to closely named siblings, but that issue is already reflected in the usage_guidelines score and does not prevent a competent agent from invoking 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?

The input schema has 0% description coverage, so the description must compensate, and it does thoroughly. All six parameters are explained beyond their bare property names: mode's strategies are expanded, tenant_id is described as scoping search to tenant data, trace_id is tied to audit tracing, source_type gets examples, and top_k is described as returning ranked chunks. This is strong parameter documentation.

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 clear action and resource: 'Execute evidence retrieval across indexed content.' However, the sibling set includes get_evidence and explain_retrieval, and the description does not explain how this tool differs from them, so it is clear but lacks sibling differentiation.

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

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

The description provides no guidance on when to use retrieve_evidence versus get_evidence, get_document, or explain_retrieval. It only describes the tool's own operation and parameters, with no context about exclusions, prerequisites, or alternative conditions.

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