MCP server for CZ job portal search — live scraping, boolean matching, EROI analysis
MCP-Jobs has 7 tools with clear naming (verb_noun pattern) and reasonable descriptions (avg ~150 chars). However, critical gaps exist: input schemas are present but lack detailed parameter descriptions for most tools. search_from_config and search_from_yaml accept only a single string parameter with minimal guidance on YAML structure. search_jobs_v2 has better schema detail but lacks enum constraints on portal/query arrays. Output schemas are undocumented, LLMs cannot predict what search_status returns or how to chain results. Error handling is minimal; no recovery guidance. The async job pattern (submit + poll) is sound but underdocumented for LLM reasoning.
Retrieve a stored search result resource by query_id.
Check server health and version.
List all available job portals and their aliases.
Run the full search pipeline from a YAML config file path. Category bulk scrape + boolean filter + location/salary filter. ASYNC: starts the job in background and returns job_id immediately — poll with search_status(job_id) for the result.
Run the full search pipeline from inline YAML content (no file needed). Accepts the same YAML structure as config.yaml.example. Category bulk scrape + boolean filter + location/salary filter. ASYNC: starts the job in background and returns job_id immediately — poll with search_status(job_id) for the result.
Advanced search with portal selection, boolean matching, and EROI analysis. ASYNC: starts the job in background and returns job_id immediately — poll with search_status(job_id) for the result.
Output schemas undocumented. search_status, search_from_config, search_from_yaml, and search_jobs_v2 return complex result objects but LLMs cannot predict field names, types, or structure. This breaks downstream tool chaining and forces agents to guess.
Parameter descriptions insufficient. search_from_config and search_from_yaml accept 'config_path' and 'yaml_content' but do not document required YAML structure, valid keys, or constraints. LLMs cannot construct valid YAML without examples or schema.
Enum constraints missing. search_jobs_v2 'portals' and 'queries' parameters accept arrays but do not declare valid values as enums. LLMs will hallucinate invalid portal names (e.g. 'linkedin', 'indeed') instead of using the 7 supported portals.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 53 | <=2025-11-25 | v2 |
Check status of a background search job started by search_from_config, search_from_yaml or search_jobs_v2. Returns job_id, status (pending/running/done/error) and the full result when done.
Async job pattern underdocumented. search_from_config, search_from_yaml, and search_jobs_v2 return immediately with job_id but do not explain polling behavior, timeout expectations, or when to give up. LLMs may not understand they must call search_status repeatedly.
No error recovery guidance. Tools return generic error strings (e.g. 'Pipeline error: ...') without actionable next steps. LLMs cannot determine if the error is retryable, user-fixable, or fatal.