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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=true, so the tool is not destructive and can be run multiple times. The description adds that it drops metadata and unused objects, which is useful context for users concerned about privacy or potential loss. It doesn't mention any side effects like quality trade-offs, but the annotations cover 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 sentence that is informative and front-loaded with the action and result. It avoids unnecessary details and gets straight to the point. However, it could be slightly more structured by separating the primary action from the side effects, but it's efficient.

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 moderately complex tool with 3 parameters and nested objects, the description covers the main behavior. The output schema is absent, but the description doesn't need to explain return values. It could mention potential limitations (e.g., no reduction for already-compressed PDFs) but overall it's sufficient for an agent 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 coverage is 100%, so parameters are fully explained in the schema. The description adds context beyond schemas by mentioning 'dropping metadata', which aligns with the 'strip_metadata' parameter, and 'keeping text sharp', which hints at quality control. This adds value without repeating schema details.

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 verb 'Reduce' and the resource 'PDF file size' with a specific method (rebuilding compactly, dropping unused objects/metadata). It distinguishes itself from sibling tools like merge_pdfs or rotate_pdf by focusing on compression.

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 for reducing file size, and the tool fits within a suite of PDF manipulation tools. It doesn't explicitly state when not to use it (e.g., vs. repair_pdf) but the context is clear enough. No exclusions are mentioned, but the purpose is distinct.

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