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

With no annotations, the description carries the full burden. It usefully discloses the write side-effect (each PDF saved as .txt) and the return summary, but says nothing about overwrite behavior, permissions, recursion into subdirectories, or what happens to non-PDF/failed files in the directory.

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 side-effect in two short sentences, followed by a clean Args block. Well organized, 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?

An output schema exists so return-value detail is not required, and the params are fully covered. However, for an unannotated batch mutation tool, the description omits failure/overwrite/permission semantics that an agent would need to invoke 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, and it documents all three parameters: directory purpose, optional output_directory with its default behavior (saved beside the PDFs), and dpi with allowed values (150/200/300/400) and default 300 — detail the schema's bare integer type 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?

States a specific verb+resource+scope: OCR every PDF in a directory, writing .txt results. The batch scope ('todos os PDFs de um diretório') implicitly separates it from the single-file siblings (ocr_pdf, ocr_image), though no sibling is named.

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 by the batch-directory scope, but there is no explicit when-to-use/when-not guidance and no mention of the sibling tools (ocr_pdf, ocr_page, check_legibility) to route the agent. The agent must infer that this is for multi-file batches.

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 disclose meaningful traits: it performs no OCR, analyzes only the native text of the FIRST page (a real scope limitation), and runs in under one second. It omits whether it mutates anything or requires special permissions, but as a pure read/analysis diagnostic that gap is minor.

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-loads the purpose, then the key limitation, then performance, then the argument — every sentence earns its place with no redundancy. Structure is clean, though the args block is slightly verbose for a single 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?

For a one-parameter diagnostic with an output schema (so return values need not be explained), the description covers purpose, scope limitation, performance, and the argument's semantics. Nothing essential to correct invocation is missing, though it could note expected output direction.

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% and the property is just a bare string, but the description compensates by specifying 'Caminho absoluto do arquivo PDF' — the absolute-path requirement is real semantic value the schema does not provide. One well-explained parameter warrants a 4.

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 ('verifica se um PDF tem fontes corrompidas/proprietárias') and explicitly contrasts itself with the OCR siblings by declaring 'Não faz OCR'. An agent can distinguish this diagnostic tool from ocr_pdf/ocr_page/ocr_image/batch_ocr without opening any 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?

The description situates the tool clearly as a pre-OCR diagnostic ('determinar se o documento precisará de OCR'), which tells the agent when it is relevant. However, it never names a specific alternative or states an explicit when-not-to-use rule beyond the implicit 'if you actually need OCR, use a different 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 carries the full behavioral burden. It discloses the OCR engine (Tesseract) and the mode defaults, but says nothing about error/failure behavior for low-legibility images, whether the operation is read-only/side-effect-free, or resource/time constraints — gaps that matter for an OCR 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 purpose is front-loaded in the first line, followed by a short use-case sentence and a clean Args block. The use-case sentence is mildly expendable but structured, and nothing is padded or circular.

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 an output schema present, return values need not be explained, and the parameters are well covered. The remaining gap is sibling disambiguation (single image vs batch vs PDF vs page) and any statement about failure handling, leaving the agent to guess which OCR tool to pick in a five-tool family.

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: image_path is documented with accepted formats and an absolute-path requirement, lang lists valid values (por, eng, por+eng) with its default, and psm decodes the integer enum (3=auto, 6=uniform block, 11=sparse text). This adds meaning the bare schema cannot convey.

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+resource: extract text from an image via OCR (Tesseract), and even enumerates concrete use cases (screenshots, scanned pages, document photos). It does not, however, differentiate itself from the sibling tools (batch_ocr, ocr_page, ocr_pdf), so an agent must infer the boundary from the resource noun alone.

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 'Útil para...' sentence gives implied usage context (screenshots, scanned pages, document photos), which is better than nothing. But it never names alternatives or exclusions, so nothing tells the agent when to prefer batch_ocr (multiple images) or ocr_pdf (PDF input) over this single-image 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 carries the full behavioral burden. It discloses useful operational detail (accepted page-range syntax, DPI choices and default) but says nothing about permissions, local file requirements, cost/time of OCR, or read-only nature, leaving real behavioral gaps.

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?

Purpose is front-loaded in the first sentence, followed by a usage sentence and a clean Args block. Every element is informative, though the structure is conventional rather than tight.

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 need not be explained. For a three-parameter OCR tool, the description covers purpose, usage context, and all parameter syntax adequately; nothing an agent needs to invoke it correctly 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, and it does: it defines pdf_path as an absolute path, enumerates accepted page formats with four concrete examples, and lists the valid DPI values plus the default. This is richer than the bare schema types.

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 specific PDF pages) and immediately scopes it against the whole-document sibling by framing it as page-selective. An agent can tell this apart from ocr_pdf and batch_ocr 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?

Explicitly gives two use cases: large PDFs where only a few pages are needed, and follow-up after running ocr_pdf on a large document. It names the alternative it complements, though it never states when *not* to use it (e.g., for whole documents, prefer ocr_pdf).

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 and does substantial work: it discloses automatic corrupted-font detection, conditional OCR application, the <=30-page threshold, and divergent return behavior (full text vs .txt path + summary). It omits permission/authorization needs, failure behavior, and runtime cost, keeping it short of 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?

The opening sentence leads with the core action, and the small-vs-large behavior follows logically before the Args block. It is slightly list-like in the Args section but every line carries information; no filler 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?

An output schema exists, so return structure needn't be documented, yet the description usefully explains the two return modes. Given no annotations and a mutation-adjacent side effect (writing .txt files), the omission of error handling and file-write implications is a minor gap, but the definition is otherwise complete for calling 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%, so the description must fully document parameters, and it does: pdf_path is specified as an absolute path, dpi is given the allowed enum values (150/200/300/400) and its default, none of which appear in the schema, and save_to_file's override semantics are explained. It fully compensates for the schema 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 states a specific verb and resource ('Extrai texto de um PDF') plus the differentiator that it auto-detects corrupted fonts and applies OCR when needed. It is clear what the tool does, but it never names or distinguishes itself from the sibling tools (ocr_image, batch_ocr, ocr_page), which is required for 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?

The description explains internal OCR-triggering behavior and the small-vs-large PDF branching, which implies when the tool is relevant. However, it gives no explicit guidance on when to choose this over ocr_image or ocr_page, nor any exclusions or prerequisites. Usage 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.