pdf-mcp

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

No annotations provided, so description carries full burden. Discloses critical behavioral details: 1-indexed page numbering, inclusive ranges, end_page defaults to start_page, cropping logic for headers/footers, and distinguishes four output formats (including implementation detail PyMuPDF4LLM). Minor gap: no mention of error handling for missing files or invalid page ranges.

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 purpose statement followed by structured Args documentation. Every sentence provides necessary detail given zero schema coverage. Format explanations are particularly dense and useful. Slightly verbose structure (Args header style) but appropriate for the information density required.

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 existence of output schema (has_output_schema: true), description appropriately avoids duplicating return value specification while still explaining format variations. Complete parameter documentation compensates for empty schema descriptions. Minor gap: no mention of performance characteristics for large page ranges.

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%, requiring heavy description compensation. Args section thoroughly documents all 5 parameters: filename (path), start_page/end_page (indexing semantics), format (detailed enum explanations for all four options including structured vs plain output), and include_headers_footers (cropping behavior). Excellent semantic coverage given schema limitations.

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?

Opening sentence 'Extract text content from one or more PDF pages' provides specific verb (Extract), resource (text content), and scope (PDF pages). Implicitly distinguishes from sibling get_page_image (images vs text) and search_text (extraction vs search).

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?

No explicit guidance on when to use this tool versus siblings like search_text (which finds specific text) or get_table_of_contents. No prerequisites mentioned (file existence, PDF validity) or when to prefer text vs markdown formats.

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