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

Annotations already declare this as a safe, idempotent, closed-world read, so the safety profile is covered. The description adds the pagination cap of 100 pages, which is genuinely useful operational context, but says nothing about error behavior, whether text-layer availability is reported per page or per document, or the cost of the call.

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 sentences with the payload (what you get) front-loaded ahead of the operational constraint. No filler, though the second sentence is a bare fragment that could more explicitly tie the 100-page cap to the limit parameter.

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 no output schema, the description carries the burden of describing return values; it lists the three data points but not their shape (per-page vs. aggregate, units, types). Combined with 0% parameter coverage and no output schema, an agent can guess the intent but not the exact calling contract.

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 all three parameters and largely fails. "Paginated" loosely gestures at start_page/limit and the 100-page ceiling contradicts the schema default of limit=50 without explaining the relationship, and the required "file" parameter is never described (path? URL? format?).

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?

Names the specific resource (a PDF document) and the exact data returned: page count, page sizes, and text-layer availability. It is clearly distinguishable from siblings like page_text or page_render, though it never states an explicit verb (inspect/retrieve) or that it operates on a single file.

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?

"Paginated, maximum 100 pages" hints at how to iterate, but there is no statement of when to call this versus list_documents or search_text, no prerequisites, and no note about what happens for non-PDF or missing files. Usage must be inferred from the sibling names alone.

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?

Annotations already cover read-only, idempotent, non-destructive, non-open-world behavior, so the description only needs supplementary context — and it delivers it: multi-root results are prefixed root1/, root2/, and filenames must be reused verbatim. It omits pagination/limit behavior, keeping it from a 5.

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 short sentences, front-loaded with the core action, and every clause carries an actionable detail (prefix rules, verbatim reuse). No waste.

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 no output schema, the description usefully characterizes the return (filenames plus root mappings) and how to consume it. The only gap is the undocumented limit parameter, which is minor for a simple listing 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?

There is one parameter (limit) with 0% schema description coverage, and the description never mentions it or explains what limiting does. With low coverage the description is expected to compensate, and it does not.

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 ('List PDF filenames and root mappings'), which cleanly separates it from siblings like search_text and page_text. It does not explicitly name a sibling or contrast itself with document_info, 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?

'Pass the returned filename unchanged to other tools' implies this is a discovery step feeding the other tools, but it never states when to use this versus document_info or the alternatives. Usage is implied rather than spelled out.

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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds real behavioral value: it returns an inline PNG plus metadata and re-renders from source rather than upscaling a thumbnail. Return format is disclosed despite the absent output 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?

Front-loaded with the core action and return type, then dense factual detail with no filler. Every sentence (coordinate system, example, dpi range, search-hit guidance) 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 a read-only tool with no output schema, the description covers return type, coordinate semantics, dpi bounds, and a use case, which is sufficient to invoke it correctly. Minor gaps around file/page expectations remain but are low risk.

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 carry the load, and it does for the ambiguous parameters: bbox is defined as [x0,y0,x1,y1] normalized 0..1 with top-left origin of the full page, plus a concrete example, and dpi is bounded to 36..600. Only file and page are left implicit, which are largely self-evident.

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 (re-render), resource (PDF region), and output (inline PNG and metadata). This clearly distinguishes it from the sibling page_render, which renders a full page, while page_crop targets a region.

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?

Tells the agent when this applies: 'Expand search hit bbox to include surrounding wires/components,' linking it to a search workflow. The note 'Not an upscale of a thumbnail' clarifies it re-renders from source, but no sibling is explicitly named as the alternative.

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?

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely useful non-annotation behavior: it 'never silently resizes' and enforces hard limits (12 MP / 6000 px / 8 MB PNG). It does not say what happens when a request exceeds those limits (error vs. clamp), which is the one remaining behavioral gap.

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 short lines, front-loaded with the core purpose, then guidance, then hard limits. Every sentence carries distinct information and none is redundant with 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?

No output schema exists, but the description states the return shape ('inline PNG plus metadata'), the size/pixel limits, and a routing recommendation, which is most of what an agent needs. The only shortfall is undefined behavior on limit violations and undocumented file/page parameters.

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 carries the burden. It meaningfully constrains dpi with a recommended 120-180 range, but says nothing about 'file' or 'page' semantics. Two of three parameters are therefore undocumented anywhere, so it only partially compensates 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?

States a specific verb and resource ('Return full page as inline PNG plus metadata'), and explicitly contrasts itself with the sibling page_crop for the small-label case. An agent can distinguish it from page_crop and page_text without opening a schema.

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?

Gives an explicit starting recommendation ('Start at 120-180 dpi for an overview') and names both the alternative tool and the condition that selects it ('For small labels, use page_crop'). This is when-to-use plus when-to-use-something-else, with nothing left to inference.

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?

Annotations already cover the safety profile (readOnlyHint, idempotentHint, non-destructive, closed-world). The description adds genuinely useful context: extraction is text-only with no OCR, and results are paginated. However, the pagination reference uses a field name that doesn't exist in the schema, which weakens the added value.

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 sentences with no filler, and the core capability is front-loaded ahead of the pagination and OCR caveats.

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 no output schema and 0% schema coverage, the agent must infer the return shape, bbox coordinate format, and max_chars truncation behavior. The description covers the essential extraction scope and the no-OCR limitation, but leaves meaningful gaps for a five-parameter 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% across five parameters, so the description must carry the burden. It partially does: 'normalized crop' hints that bbox coordinates are normalized, and 'paginate' maps loosely to offset/max_chars. But file, page, offset, and max_chars remain semantically 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 ('Extract text from one PDF page or normalized crop'), clearly contrasting with page_render and page_crop in the sibling set. Scope ('one PDF page') is explicit, though it never names its siblings directly.

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?

'Paginate with next_offset; no OCR' implies the usage pattern and a key limitation, but there is no explicit when-to-use or when-to-prefer-an-alternative guidance against siblings like search_text or page_render. The pagination hint is also ambiguous because it references 'next_offset', which does not match any schema parameter.

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?

Annotations already declare readOnly, idempotent, non-destructive behavior, so the safety profile is covered. The description adds genuinely useful behavior beyond that: a 200-page-per-call search ceiling and the fact that returned bboxes are normalized and may need expansion before cropping.

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 short sentences with the core action and return value front-loaded, then the operational constraint, then the exclusion. No filler or repetition; 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?

With no output schema, the description usefully discloses the return shape (page plus normalized bbox), and annotations cover the safety profile. However, for a five-parameter tool with zero schema documentation, an agent still lacks the parameter semantics needed to call it precisely.

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% across five parameters (file, query, limit, start_page, end_page), so the description carries the full burden and largely fails: it never explains what 'limit' caps (hits vs pages), what start_page/end_page do, or the format expected for 'file'. Only an oblique hint about a 200-page ceiling is offered.

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 ('Find literal PDF text') with concrete examples (part numbers, net names) and names its return payload (page and normalized bbox). It distinguishes itself from semantic search and OCR, but does not differentiate from the page_text sibling that presumably also extracts text.

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?

Gives a clear when-not ('This is not semantic search or OCR') and a workflow directive ('expand hit bboxes before cropping surrounding circuitry'), which positions it relative to page_crop. It stops short of naming an alternative tool for full-page text extraction (e.g. page_text).

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