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

With no annotations, the description carries the full transparency burden, but it only says that availability is 'reported.' It does not disclose whether checks are executed, whether the operation is read-only, or how failures are reported, even though the output schema may document return fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single short sentence that front-loads the verb and names the key subjects. There is no filler or repetition, and every word contributes to the core message.

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 a zero-parameter tool with an output schema, the description conveys the core reporting function, but it omits any context about when to run doctor and how it relates to the sibling tools. It is minimally viable but leaves the agent to infer the operational 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 input schema has zero properties, so there are no parameter semantics to explain. According to the rubric baseline for 0 parameters, this is adequate without additional parameter detail in 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 uses the verb 'Report' and lists specific subjects (parser, SQLite/FTS, optional OCR availability), indicating a diagnostic status tool. It is clearly distinct from sibling tools that ingest, search, get, list, or render documents, though the phrase is elliptical.

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 for when to use doctor versus the ingestion/search/get/list/render siblings. There are no preconditions, recommendations, or exclusions, leaving the agent to infer that it is a health-check tool only from the name.

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 fails to state whether the operation is read-only, what permissions are needed, what happens if the document is not found, or any potential side effects. It only mentions the return content, leaving important behavioral traits undisclosed.

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 sentence, front-loaded with the verb, and contains no redundant words. It is concise and to the point, earning a high score for structure and brevity.

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 with one parameter and an output schema, which reduces the need to explain return values. However, the lack of annotations and minimal description leaves gaps in usage guidance and behavioral context. It is adequate for a basic getter but not fully complete for an agent making an informed decision.

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 no description for document_id (0% coverage), so the description must compensate. It does clarify that the parameter identifies which document's summary and source paths to return, but it does not explain the format or origin of the document_id, nor its relationship to other tools. This adds some semantic value but not comprehensive guidance.

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 'Return' and clearly identifies the resource: 'one document manifest summary and all source paths seen for it.' This distinguishes it from sibling tools like list_documents (which lists documents) and get_evidence (which presumably retrieves evidence), making its purpose unambiguous.

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 on when to use this tool versus alternatives such as list_documents or get_evidence. The description implies usage for retrieving a single document's details, but does not mention context, exclusions, or why one would choose it over a sibling 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?

No annotations are provided, so the description must disclose behavioral traits itself. It reveals a key behavior—the total character budget—but does not explain what happens when the budget is exceeded (truncation, omission, or error), nor any other side effects, ordering, or required permissions. The budget disclosure is useful but incomplete for a tool with no annotation support.

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, tightly-worded sentence that front-loads the action and resource, and includes the distinctive budget constraint. Every word earns its place; there is no redundancy or 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 simple 2-parameter tool with an output schema, the description covers the core purpose and the budget constraint, which is essential. However, it lacks usage context (e.g., when to prefer this over search_evidence) and does not clarify behavior under budget limits. Given no annotations and sparse schema, the description is adequate but leaves notable 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?

With 0% schema description coverage, the description adds meaning by mapping 'evidence blocks' to evidence_ids and 'total character budget' to max_chars. This clarifies the purpose of both parameters, especially max_chars, which the schema only labels generically. It does not specify units or edge-case behavior, but it significantly compensates for 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 states a specific verb ('Read') and resource ('exact evidence blocks') qualified by 'by stable ID', clearly distinguishing it from sibling search_evidence. It also introduces a unique constraint ('under a total character budget') that defines its scope precisely.

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 'exact evidence blocks by stable ID' implies this is for direct retrieval when IDs are known, as opposed to search_evidence or ingest_document. While it does not explicitly state when not to use it or name alternatives, the wording provides clear contextual cues for appropriate use.

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 disclosure burden. It discloses that the operation persists data, that cache identity includes source SHA-256, parser configuration, OCR provider, languages, and engine versions, and that force creates an explicit new revision. This goes beyond the schema and informs the agent about side effects and revisioning, though it does not detail failure modes 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: three sentences total, front-loaded with the primary purpose, followed by cache identity details and force guidance. Every sentence contributes value without redundancy or 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?

Given the 4-parameter complexity, no annotations, and an output schema (which removes the need to describe return values), the description is fairly complete. It covers the main behavior, cache identity, and force semantics. It omits edge cases like duplicate imports or error handling, but the provided context is sufficient for an agent to invoke the tool reasonably 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 has 0% description coverage, so the description must compensate. It explains that cache identity derives from source SHA-256 (linked to path), OCR provider (ocr_mode), and languages, and explicitly clarifies force's role for new revisions. However, it does not explain ocr_mode's enum values or the languages format (e.g., ISO codes), leaving some parameter semantics implicit. It adds meaningful guidance but not full 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 states a specific verb ('Import') and resource ('local document'), and clarifies the key action: 'persist its structured evidence'. This clearly distinguishes it from sibling tools like search_evidence, get_evidence, and render_crop, which are all retrieval or manipulation tools rather than ingestion.

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 implies the primary use case: importing a local document once for evidence persistence, and explicitly warns that 'force' should only be used to create a new revision. It does not name alternative tools, but the contrast with retrieval-focused siblings is contextually clear. It lacks explicit 'do not use when' exclusions, but the 'once' and 'revision' guidance provides solid usage boundaries.

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?

The description discloses the key behavior of not returning document bodies and scopes results to 'recently indexed' versions. With no annotations, the read-only nature is implied but not explicitly stated; however, for a listing tool this is adequate.

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, direct sentence with no filler, front-loading the verb and resource and adding a useful qualifier.

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 the output schema covers return values, but the lack of parameter explanation and explicit sibling differentiation leaves clear gaps, making it merely 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?

The sole parameter `limit` is completely undocumented in both the schema and description. The description does not mention how `limit` affects results, leaving the agent to infer its meaning from the tool name.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'List' and resource 'recently indexed document versions', and explicitly notes it avoids returning bodies, which distinguishes it from siblings like get_document or search_evidence.

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

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

The description implies usage when a recent list of documents is needed but does not explicitly state when to prefer this over search_evidence or get_document, nor any exclusions.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It adds valuable details beyond the schema by stating that coordinates use PDF points (72 per inch) and that the tool returns a path and metadata, never image bytes. This clarifies the output format and coordinate system, though it omits potential side effects 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 three focused sentences. The first states the purpose, the second provides coordinate units, and the third clarifies the output format. Every sentence earns its place with no redundant details.

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 has 7 parameters and an output schema, and the description covers the core rendering purpose, coordinate units, and output behavior. It does not mention when to use the tool or any side effects, which is a minor gap, but the existing information is adequate for a moderately complex render 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. It adds meaning to the coordinate parameters (x0, y0, x1, y1) by specifying PDF points, but does not explain document_id, page, or dpi further. The parameter names are relatively self-explanatory, but the description only partially fills the 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 starts with a specific verb 'Render' and identifies a precise resource: 'one PDF evidence rectangle to a local PNG artifact.' This clearly distinguishes it from sibling tools like search_evidence or get_document, which handle different operations.

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 about when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or when this rendering operation is preferred over other evidence-related tools. The sibling list provides context but the description itself offers no usage direction.

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

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

With no annotations, the description must disclose behavioral traits, but it only mentions 'persistent' and 'bounded' without clarifying read-only nature, result ordering, or any side effects. It does not address permissions or safety.

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, concise sentence with no wasted words, front-loading the core action and resource. It is appropriately sized for the limited content it conveys.

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 4 parameters with no schema descriptions, no annotations, and an output schema, the description is too sparse. It does not explain search behavior, parameter roles, or result format, making it insufficient for robust tool use.

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 any of the four parameters (limit, query, max_chars, document_id). It fails entirely to add meaning 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 clearly states the tool's function: it searches a persistent local index and returns a bounded set of citations. This distinguishes it from sibling tools like get_evidence and get_document, which imply direct retrieval rather than search.

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

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

The description provides no guidance on when to use this tool versus alternatives such as get_evidence or list_documents. It only states what the tool does, leaving the agent without context for tool selection.

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