A Model Context Protocol server that enables searching for jobs across various platforms
Single tool 'search_jobs' has a detailed schema with 21 parameters, but critical gaps undermine quality. Description is adequate (89 chars) but lacks WHEN/WHY guidance. Parameter descriptions are present but inconsistent in depth, some are clear ('Comma-separated list of job sites'), others vague ('Controls verbosity'). No output schema documented. Parameter naming is inconsistent: 'siteNames' (camelCase union), 'searchTerm' (camelCase string), 'jobType' (camelCase enum), mixing conventions. No error handling guidance. Tool does not declare what it returns or how results are structured. Missing idempotency/safety markers.
Search for jobs across various job listing websites
No output schema documented. LLM cannot predict result structure, field names, or types. Breaks downstream tool chaining and forces parsing guesswork.
Parameter naming inconsistency: 'siteNames' (union, camelCase), 'searchTerm' (camelCase), 'jobType' (camelCase enum), 'countryIndeed' (camelCase). Mixing conventions confuses LLM parameter selection. Should standardize to snake_case (site_names, search_term, job_type, country_indeed).
Tool description lacks WHEN/WHY context. States WHAT ('Search for jobs') but not WHEN to call it vs alternatives or what prerequisites exist. LLM cannot determine if this is the right tool for a user intent.
Parameter 'verbose' description 'Controls verbosity (0=errors only, 1=errors+warnings, 2=all logs)' is vague about what this controls in the response. Does it affect output size? Response structure? Unclear to LLM.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 37 | <=2025-11-25 | v2 |
No error handling guidance. Tool accepts 21 parameters with complex interdependencies (e.g., 'googleSearchTerm' only valid for google site, 'linkedinCompanyIds' only for linkedin) but provides no recovery hints if invalid combinations are passed.