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

Annotations declare readOnlyHint=true and openWorldHint=false, which the description does not contradict — text extraction is consistent with read-only. Beyond the annotations, the description adds genuinely useful behavior: it discloses the OCR limitation (scanned/image-only PDFs return little or no text) and that results are returned inline. This enriches the safety and outcome expectations beyond structured data.

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 sentences with zero filler: purpose and use cases lead, input format follows, and the OCR caveat closes. Every sentence earns its place, and the most decision-relevant information (purpose, not-OCR warning) is front-loaded before implementation 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?

For a single-parameter extraction tool whose annotations already carry the read-only safety profile, the description covers input (file_id or base64), output (inline text), and the key failure mode (scanned PDFs). Minor gaps like response size limits and encoding specifics are absent, but nothing an agent needs to call 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 100%, so the schema already documents the single 'pdf' parameter (file_id or base64). The description restates the input options and adds the return-format detail (text inline), but that concerns output rather than parameter meaning. Per the rubric, high schema coverage warrants a baseline of 3, and the marginal added value is modest.

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 pair ('Extract the text content of a PDF') plus concrete use cases (RAG, summarization, search). It also distinguishes itself from siblings by declaring it returns text inline and is not OCR, which separates it from read_pdf_form (form fields), extract_data (structured data), and docx_to_text (different format) without opening schemas.

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 clear context for use (RAG, summarization, search) and states the accepted inputs (file_id from a prior tool or base64). The 'Not OCR' caveat is an implicit when-not-to-use signal for scanned PDFs, but it never names a specific alternative tool, so the routing guidance is clear but not exhaustive.

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