This server has well-structured tool schemas and parameter typing, but descriptions are verbose/untargeted for LLM consumption, and critical pattern gaps exist around output documentation, error handling, and parameter constraints. The two tools expose raw API complexity rather than abstracting it into chat-friendly interfaces. Neither tool documents output structure, breaking the 'Document the output schema' critical check. Error handling is minimal, no recovery guidance, no classification of retryable vs fatal errors.
Get detailed information about a specific job Args: job_id: The unique identifier of the job
Search for jobs using the HireBase API Args: query: Full text search query and_keywords: Keywords that must all appear in results or_keywords: Keywords where at least one must appear not_keywords: Keywords that must not appear title: Job titles to search for category: Job categories to filter by country: Countries to filter by city: Cities to filter by location_type: Location types (Remote, In-Person, Hybrid) company: Companies to filter by salary_from: Minimum salary salary_to: Maximum salary salary_currency: Salary currency (e.g. USD) years_from: Minimum years of experience years_to: Maximum years of experience visa: Whether job offers visa sponsorship limit: Maximum number of results to return
No output schema documented for either tool. LLMs cannot plan downstream calls or extract data without knowing what fields to expect. search_jobs and get_job both lack response structure documentation.
Parameter descriptions embed example values (e.g. 'Salary currency (e.g. USD)' in search_jobs). LLMs latch onto examples and pass them literally in real calls. Replace with enum constraints or formal format declarations.
Constrained parameters lack enums. 'location_type' accepts [Remote, In-Person, Hybrid] but is defined as string array with no enum constraint. LLMs will hallucinate invalid values like 'remote-work' or 'on-site'.
No error handling guidance in tool descriptions. If API authentication fails, returns are not documented. If job_id is invalid, no recovery hint provided.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 54 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 11 | - | v1 |
Tool descriptions are 80-150+ characters, approaching the upper bound (1024 chars). For search_jobs, the description is bloated with parameter listings that duplicate the schema. Trim to ~50-120 chars with actionable context.
No pagination guidance in search_jobs schema. 'limit' defaults to 10, but no mention of offset/cursor support, max result counts, or when to paginate. Rubric requires page/offset + limit + total count for list-returning tools.
API key credential passed via environment variable (HIREBASE_API_KEY), secure. However, no tool description warns users about authentication prerequisites or failure modes (missing key, invalid key, rate limits).
Parameter type ambiguity: 'salary_currency' accepts free-form strings instead of an enum of supported currencies. Rubric forbids free-form when 'a known set of values' exists. This invites hallucinated currencies like 'BTC' or 'EUR-EQUIVALENT'.