Server has 6 well-named tools with complete input schemas and descriptions. All tools follow verb_noun naming (pdf_info, pdf_extract_text, pdf_merge, pdf_split, pdf_rotate, pdf_add_watermark). Descriptions are present and adequate (60-120 chars), exceeding the 10-char minimum. All parameters have type definitions and descriptions. However, output schemas are not formally documented, responses are JSON-stringified text blocks rather than structured objects with declared fields. Error handling is minimal; no recovery guidance or actionable error messages. Parameter constraints (e.g., angle enum for pdf_rotate, opacity 0-1 range) are described but not enforced via schema validation. No pagination, no per-item success/failure tracking for batch operations. Risk annotations (READ_ONLY, WRITE) are present but not exposed as tool annotations in the MCP schema.

• Define explicit output schemas for each tool. Instead of returning JSON-stringified text, return structured objects: {success: boolean, output: string, totalPages: number, ...}. Document field types and meanings.
• Add input validation and actionable error messages. Validate angle in [90, 180, 270], opacity in [0, 1], page numbers within bounds. Return 'Invalid angle: got 45, must be one of: 90, 180, 270' instead of stack traces.
• Convert parameter constraints to schema enums and bounds. pdf_rotate angle: {type: 'integer', enum: [90, 180, 270]}; pdf_add_watermark opacity: {type: 'number', minimum: 0, maximum: 1}.
• Implement page range extraction in pdf_extract_text or remove the non-functional parameters. If pdf-parse does not support ranges, document this limitation and either implement it with pdf-lib or remove startPage/endPage.
• Add tool annotations to the MCP schema. Use readOnlyHint: true for pdf_info and pdf_extract_text; destructiveHint: true for pdf_merge, pdf_split, pdf_rotate, pdf_add_watermark to signal side effects.