Server has 4 tools with complete input schemas and basic descriptions. However, descriptions are generic and lack actionable context for LLM selection. Parameter descriptions are minimal (e.g., 'Path to the PDF file' for pdf_path). No output schemas documented. Error handling is absent from visible code. Tool names follow verb_noun convention but lack specificity about side effects. No tool annotations (readOnlyHint/destructiveHint) despite clear WRITE vs READ_ONLY risk profiles.

• Add output schemas to all tools. Document what fields are returned (e.g., pdf_info returns {page_count: int, file_size: int, created_date: string}). This enables LLMs to chain tools and extract data.
• Expand tool descriptions to 100-200 chars. Include WHEN to use each tool and what it returns. Example: 'Convert PDF pages to PNG or JPG images. Returns array of output file paths. Use pdf_split first to extract a page range, then pdf_to_images to render it.'
• Add tool annotations via mark3labs/mcp-go. Set readOnlyHint=true for pdf_info; destructiveHint=true for pdf_to_images, pdf_compress, pdf_split (they write files).
• Document parameter constraints in descriptions. Add min/max for dpi (e.g., '50-600'), clarify path format (absolute or relative), and explain page numbering (1-indexed vs 0-indexed inconsistency: 'start_page: 1-indexed, 0 means first page' is confusing).
• Implement structured error responses. Return {error: string, code: string, retryable: bool, suggestion: string}. Example: 'File not found at /path/to/file.pdf. Check the path and try again.' instead of a raw error.

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

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