This server has critical gaps across nearly all definition quality dimensions. Examined source code shows: (1) No visible input/output schemas in the TypeScript files provided, tool registration appears to call register* functions but actual schema objects are not shown, making it impossible to verify parameter types, constraints, or output documentation. (2) Tool descriptions are present but minimal (10 - 40 chars), well below the 194-char baseline for production tools. E.g., 'Retrieve information about a specific company' (42 chars) lacks context on when to call vs. search_jobs, what fields are returned, or prerequisites. (3) Parameters are not visible in the snippet provided, so type definitions, enums, descriptions, and constraints cannot be verified. (4) No evidence of error handling patterns, recovery guidance, or structured output schemas. (5) Tool composition is sound (12 single-purpose tools with clear verb_noun names), but lacks the depth needed for safe, repeatable agent invocations.
Tools (12)
check-job-statusread only37/100
Check the current status of a job posting
generate-resumeswrite33/100
Generate or manage resumes for job applications
get-col-inforead only37/100
Retrieve cost-of-living information for locations
get-company-inforead only38/100
Retrieve information about a specific company
get-job-detailsread only38/100
Retrieve detailed information about a specific job
get-matchesread only37/100
Retrieve matched jobs above the preference threshold
No visible input/output schemas in source code. Tool registration functions (registerRunSetup, etc.) are called in index.ts but the actual schema definitions are not shown. Cannot verify parameter types, constraints, enums, or return types.
Tool descriptions are too short (10 - 40 chars vs. 194-char baseline). E.g., 'Retrieve information about a specific company' (42 chars) does not explain when to use vs. search_jobs, what fields are returned, or dependencies on run-setup.
Expand tool descriptions to 100 - 200 chars with WHAT, WHEN, and prerequisite context. E.g., 'Search jobs by title, description, or company. Returns jobs ranked by match score. Call after save-preferences to filter against user criteria. Use instead of list-company-jobs to search across all companies.'
Add parameter annotations for all inputs. E.g., 'query_string: Search term(s) (3 - 200 chars). Matches job title, description, required skills. Prefix with company name to filter: "acme software engineer" searches only Acme.' 'limit: Number of results (1 - 50, default 20).'
For list_* and search_* tools that return multiple items, enforce pagination: require limit (default 20, max 50), accept offset or cursor, return total_count and has_more bool. Cap results to prevent LLM context explosion.
Add error recovery guidance. E.g., for get-matches returning empty list: 'No jobs match current preferences. Try: (1) lower salary_floor via save-preferences, (2) search-jobs with broader criteria, (3) check if setup-polling has completed an initial poll.'
Document tool dependencies explicitly. Add a README or in-code comment: 'Workflow: run-setup → save-preferences → (setup-polling or search-jobs) → get-matches → get-job-details → get-resume-context → generate-resumes.' Add notes to each tool saying what preconditions must be met.
Score history
Overall score trend
↓ 8 points across a rubric change (v1 → v2)
32/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-22
F
32
2026-07-28+
v2
2026-03-09
F
40
-
v1
Tool for initial setup of the job search system
save-preferenceswrite33/100
Save user job search preferences
search-jobsread only40/100
Search across job titles, descriptions, and company IDs
No error handling patterns visible. Tools like search-jobs may return 0 results, but description does not guide LLM on recovery (e.g., 'Try broadening search criteria' or call a discovery tool). Destructive tools (save-preferences, generate-resumes) have WRITE risk but no dry-run, confirmation, or rollback guidance.
Composition: get-matches, get-job-details, and get-resume-context suggest a workflow dependency (e.g., user must run setup, save preferences, then retrieve matches), but tool descriptions do not document these prerequisites or guide the LLM through the sequence. Agents may call tools in wrong order.
Cost-of-living feature (get-col-info, col-lookup.ts) is well-engineered internally but tool description is 40 chars. Does not explain when LLMs should call it (e.g., after get-job-details to contextualize salary) or how it relates to the scoring system mentioned in comments.
Polling mechanism (setup-polling tool) has side effects but no documentation of what runs in the background, how to monitor it, or how to cancel it. Agents may invoke multiple polling tasks unknowingly, creating duplicate work.
setup-polling
For destructive tools (save-preferences overwrites old prefs, generate-resumes may modify files), add a dry-run parameter or return a confirmation summary before executing. E.g., 'Would overwrite existing preferences for user_id=X. Current prefs: [list]. Confirm with confirm=true to proceed.'
Add 'searchable' annotations to tools. Mark search-jobs, list-company-jobs as discovery tools; mark get-matches as a ranked/filtered result tool. Help LLM understand when to explore vs. retrieve.
Document the cost-of-living integration. In get-job-details, note: 'Includes COL context if location matches RPP data. Multiplier adjusts user salary floor for purchasing power comparison.' Link to col-lookup.ts so LLM understands the feature.
Add output schema examples to descriptions. E.g., get-job-details: 'Returns {id, title, company, location, salary_min, salary_max, description, col_context, match_score}. See col-lookup.ts for COL field structure.'
Validate and document polling behavior. What is the poll frequency? Can users cancel mid-poll? What happens if setup-polling is called twice? Document in setup-polling description and return structured status.
For save-preferences, document what fields are supported (salary_floor, locations, job_titles, skills?) and what happens to old preferences. Return a confirmation object showing old vs. new values for agent auditability.