MCP server for job market data: search live postings, get salary and demand aggregates, and see how long each listing has been open.
Four well-structured tools with complete JSON schemas, clear descriptions (150 - 250 chars), and proper parameter typing. All tools declare tool annotations (readOnlyHint, idempotentHint, openWorldHint). Naming follows verb_noun convention (search_jobs, get_job). Schemas use additionalProperties: false to prevent hallucinated parameters. However, output schemas are not documented, LLMs cannot predict response structure. Error handling is absent from tool definitions. Parameter descriptions are good but lack format/constraint examples (e.g., 'city name as employers write it' could specify case sensitivity or accent handling). No batch variants despite agents likely calling search_jobs in loops.
Full detail for a single posting by its id, including the description and the application link.
Counts, salary percentiles by currency, remote share, top employers, seniority and employment-type mix, city and source split for any slice of postings. Accepts the same filters as search_jobs. Use this instead of paging through results when the question is about the market rather than about individual roles.
Age profile of a slice of postings: median days since publication, share posted in the last week, and share still open after sixty days. A listing that has been open for months is the most commonly cited sign that a role is not being actively filled — this reports the numbers rather than guessing.
Search live job postings read directly from ten applicant tracking systems (Workday, SmartRecruiters, Greenhouse, Workable, Lever, Ashby, Recruitee, Teamtailor, Breezy, Personio). Returns title, employer where the ATS publishes it, location, employment type, advertised salary where disclosed, posting date and the employer's own apply link where the source carries one.
Output schemas not documented. LLMs cannot predict response structure (fields, types, pagination). Forces agents to guess or fail on unexpected formats.
No error handling guidance in tool definitions. If API returns 422 (invalid filter), 404 (job not found), or 429 (rate limit), LLM has no recovery path documented.
Parameter descriptions lack format constraints. 'city' says 'as employers write it' but does not specify case sensitivity, accent handling, or valid examples beyond Berlin/New York. 'country' accepts both ISO codes and English names but does not list valid English names.
No batch variants. Agents calling search_jobs in a loop (e.g., for 10 job titles) make 10 sequential calls instead of one batch call. Wastes tokens and latency.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 70 | 2026-07-28+ | v2 |
Pagination guidance incomplete. search_jobs accepts 'page' and 'limit' but does not document total count or next_cursor in response. LLM cannot determine if more results exist without trial.