Four tools with clear, well-written descriptions (avg 150 chars, within baseline 194). All have input schemas with type definitions and parameter descriptions. Naming follows verb_noun convention (tailor_resume, score_fit, extract_keywords, ping). However, output schemas are not documented in the visible code, tool implementations reference schema objects (TailoringResultSchema, ScoreResultSchema, ExtractResultSchema) but their structure is not shown. Error handling is minimal; no recovery guidance or actionable error messages visible. Parameters lack constraints (enums, ranges, format specs). No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite all being read-only operations.

• Document output schemas for tailor_resume, score_fit, and extract_keywords. Show the structure of TailoringResult, ScoreResult, and ExtractResult (fields, types, examples) so LLMs know what to expect.
• Add readOnlyHint: true to all four tools in the tool registration to signal they are safe to call without side effects.
• Add format and length constraints to 'resume' and 'job_description' parameters. E.g., 'resume: string (1 - 50,000 chars, plain text or Markdown)' and 'job_description: string (1 - 20,000 chars)'.
• Implement structured error handling with recovery guidance. E.g., if the LLM API fails, return 'LLM service unavailable. Retry in 30 seconds or try a simpler resume/job description.' instead of a raw error.
• Clarify tool selection in descriptions. Add to score_fit: 'Use this first to triage roles (1 - 5 scale). Then call tailor_resume for detailed rewriting of matching roles.' Add to tailor_resume: 'Use after score_fit returns a high fit score (4 - 5) to generate a tailored resume.'

Inferred effective spec: 2025-06-18+.

• Relies on Sampling (deprecated) - integrate directly with the LLM provider API