pdf-mcp provides 18 tools with consistent naming (verb_noun pattern: extract_*, to_*, from_*, chunk_*) and reasonable descriptions (avg ~80 chars). However, parameter descriptions are sparse or missing entirely. Most tools lack documented output schemas. Input schemas are present but incomplete, many parameters lack type constraints (e.g., page_nums is 'array' with no item type; fmt in to_images has no enum). Error handling is absent from visible code. Security considerations (path traversal, file access validation) are not evident. Composition is good: tools are single-responsibility and chainable. Naming is clear and action-oriented, but parameter documentation falls short of production baseline (94% of A+ tools have full param descriptions; this server ~40%).

• Add full parameter descriptions to all tools. For each param, state: what it controls, valid range/format, and what happens if omitted. Example: 'page_nums: List of 0-indexed page numbers to extract. If omitted, extracts all pages. Example: [0, 2, 5].'
• Document output schemas for every tool. Define return type as JSON Schema with field names, types, and descriptions. Example for extract_metadata: {type: 'object', properties: {title: {type: 'string'}, author: {type: 'string'}, pages: {type: 'integer'}}}.
• Add input validation and error handling. Validate file paths (no traversal), check file existence, validate numeric ranges (page_nums >= 0), and return actionable errors. Example: 'File not found: /path/to/file.pdf. Check the path and try again.'
• Constrain 'fmt' parameter in to_images with an enum: ['png', 'jpg', 'jpeg', 'bmp', 'tiff']. Add 'dpi' range constraint (e.g., 72 - 600). Document defaults.
• Add security note to tool descriptions for file I/O tools: 'Paths are validated against traversal attacks. Relative paths are resolved from the server's working directory.'

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry