The server defines a single tool 'parse-resume' with reasonable naming and a complete input schema. The tool description is present but generic, and parameter descriptions are adequate but lack depth. The output schema is inferred from the code (JSON-stringified parsed resume) but not explicitly documented. Error handling exists but is minimal. The implementation uses the MCP SDK correctly and defines the tool via z.string() and z.object() schemas, which are properly visible in the source code.

• Document the output schema explicitly. Define the structure of the parsed resume (sections, fields, confidence scores, extracted entities) so LLMs know what to expect. Include examples of the top-level fields and their types.
• Expand the tool description to 100 - 200 characters. Explain: what resume formats are accepted (PDF-extracted text? plain text?), what 'standardization' does (normalizes job titles to a canonical taxonomy?), what confidence scoring measures, and when each option is useful.
• Add an enum constraint to 'sectionPriorities'. List the valid section names ('work_experience', 'education', 'skills', etc.) so LLMs can autocomplete and avoid typos.
• Enhance parameter descriptions with defaults and constraints. E.g., 'confidenceThreshold (0-1, default 0.3): Only extract entities above this confidence score. Use 0.5+ for stricter extraction.' This guides LLM decision-making.
• Implement structured error responses. When parsing fails, return {isError: true, message: 'Resume format unsupported. Accepted formats: plain text, PDF-extracted text.', retryable: false}. When a field fails validation, return the invalid value and the constraint violated.
• Add a 'format' parameter (enum: 'plain_text', 'pdf_text', 'markdown') to declare the input format explicitly. This prevents ambiguity and enables format-specific parsing strategies.