Three tools with basic verb-noun naming (search_jobs, get_job_details, search_locations). Descriptions present but generic (10-50 chars, below 194-char baseline). Input schemas visible with types and defaults, but parameter descriptions are minimal. Output schemas undocumented, LLMs cannot predict response structure. No error recovery guidance. No pagination despite search returning lists. No tool annotations. Composition is reasonable (three distinct concerns), but parameter naming lacks type suffixes (job_id is good; keyword could be location_keyword for clarity).

• Document output schemas for all three tools. Example: search_jobs returns {query: {keywords, location}, count: int, jobs: [{id, title, company, location, url, post_date, reference_id}]}. This enables LLMs to chain calls and extract fields.
• Expand parameter descriptions with format, range, and constraints. E.g., 'limit: Maximum number of results (1 - 100, default 10)' and 'job_id: LinkedIn job ID (numeric or URN format urn:li:job:XXXXXXX)'.
• Add pagination support: accept 'offset' or 'cursor' parameter and return 'next_cursor' or 'has_more' flag. Cap default limit at 20 - 50 to avoid context bloat.
• Improve error messages with recovery guidance. E.g., 'Location not found. Try search_locations() with a partial keyword.' or 'API rate limit exceeded. Retry in 60 seconds.'
• Enhance tool descriptions to 100 - 150 chars. Example: 'Search LinkedIn jobs by keywords and location. Returns job listings with title, company, URL, and posting date. Use search_locations() first if you only have a location name.'

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

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