JobScout demonstrates solid definition quality with all 5 tools properly registered, described, and schematized. Tool names follow verb_noun convention (list, search, classify, deduplicate, briefing). Descriptions are substantive (100-250 chars) and include security/trust warnings where appropriate. Input schemas use Zod with proper type constraints. However, output schemas are not formally documented in the tool registration, only visible in code comments. Tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present and correct. Parameter descriptions are clear but could be more prescriptive about constraints (e.g., exact character limits for job title/company fields are in schema but not always in description text). Error handling is basic, no recovery guidance or categorization.

• Add explicit output schema documentation to each tool registration. E.g., for jobscout_search_jobs, document: 'Returns {jobs: [{id, title, company, location, source, url, ...}], failures: [{provider, error}], total_count}'.
• Enhance error messages with recovery guidance. Replace 'Invalid query' with 'Invalid query: must be 1-500 chars. Try: "python engineer remote" or "data scientist San Francisco"'.
• Document the 'sources' parameter in jobscout_search_jobs with: 'Specific providers to query. Call jobscout_list_sources to see available options. If omitted, searches all enabled providers.'
• Add result limit guidance to jobscout_search_jobs description: 'Default limit is 20. Maximum 100. Results are deduplicated across providers. Pagination via offset parameter (if needed).'
• Formalize the 'normalized job record' structure in a shared schema definition and reference it in parameter descriptions for classify_jobs, deduplicate, and briefing tools.

Inferred effective spec: 2025-06-18+.

• Relies on Stateful initialize / Mcp-Session-Id (removed; protocol is stateless) - make each request self-contained