Three tools with minimal quality. read_local_pdf and read_pdf_url have bare-minimum descriptions (under 50 chars each) that lack context on when to use them, what they return, or error recovery. Schemas are present but parameters lack descriptions beyond the tool docstring. read_root is a utility endpoint with no clear purpose in a PDF parser. No output schemas documented. Error handling returns unstructured success/error objects without guidance for LLM recovery. No parameter validation, enums, or constraints. Naming is acceptable (verb_noun pattern) but descriptions fail the 20-char minimum quality bar.

• Add parameter descriptions to schema: {"path": {"type": "string", "description": "Absolute or relative file path to a local PDF file (e.g., /home/user/document.pdf). Must be readable by the server process."}}
• Expand tool descriptions to 100-150 chars: 'Extract text and metadata from a local PDF file. Returns text chunks (split by paragraph) and document metadata (title, author, language). Use this when you have a file path; use read_pdf_url for remote PDFs.'
• Document output schema in description: 'Returns {success: bool, data: {chunks: [str], metadata: {title, author, language}}} on success, or {success: false, error: str} on failure.'
• Add error recovery hints: 'If FileNotFoundError, verify the path exists and is readable. If parsing fails, the PDF may be corrupted or encrypted.'
• Remove read_root or repurpose it as a health check with a clear description: 'Health check endpoint. Returns {status: ok} if the PDF parser service is running.'

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

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