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

Annotations already provide idempotentHint=true and readOnlyHint=false, and the description adds no behavioral context beyond the core operation. It does not mention output side effects, task submission, or what happens to the original file, so it adds little beyond the structured annotations.

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 one short, front-loaded sentence with no filler. Every word contributes to the meaning, and the core operation is immediately clear.

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 a fully described schema, an output schema, and idempotency annotations, the one-line description covers the essentials of invoking the tool. However, it does not mention the task-based workflow suggested by sibling tools like get_pdf_task and list_pdf_tasks, leaving some operational context implicit.

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%, with all three parameters already described clearly, including the 1–50 range for pages_per_file and the purpose of idempotency_key. The phrase 'by page count' loosely reinforces pages_per_file but does not add meaningful semantics beyond the 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-resource pair ('Split ... PDF') and the splitting criterion ('by page count'), making the operation unambiguous. It distinguishes itself from siblings like merge_pdfs and images_to_pdf without requiring the 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 implies the use case—splitting a single PDF into chunks of a given page count—but never explicitly says when to choose this over alternatives like merge_pdfs or convert tools. There is no when-not-to-use guidance, so it earns only implied-usage credit.

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