resume-kit-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_versionsB | List resume versions with their title and applied date, and the content directory in use. |
| show_versionD | The resolved resume as plain text (what the PDF will say). |
| check_factsC | Run the fact guardrails (forbidden claims, required facts) on one version or all of them. |
| build_versionC | Render .docx and .pdf (default ~/Downloads), check the page target, report overflow text. |
| score_versionA | Score the built resume against job postings (file paths; default: the version's posting) with shortlist-ai. Returns per-job score, must-haves met, gaps, and per-requirement verdicts with quotes. gap_notes marks gaps that a guardrail says are real, which must not be papered over. |
| application_answersB | Standard answers for application forms: contact, work_authorization, experience_years, screening, salary, defaults, eeo. Omit section for everything. |
| ats_playbookC | Quirks, shared rules, and JavaScript helpers for an applicant tracking system (greenhouse, ashby, taleo, workday, linkedin, eightfold) or a job-page host. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 7 tools
Most tools target clearly distinct actions: list_versions (enumerate), show_version (preview text), build_version (render files), check_facts (guardrails), score_version (job matching), application_answers (form data), ats_playbook (reference). There is mild conceptual overlap between show_version/build_version (both produce the resume) and between check_facts/score_version (both validate against requirements), but the descriptions distinguish internal guardrails from external scoring well enough.
Five of seven tools follow a clean verb_noun pattern (list_versions, show_version, check_facts, build_version, score_version). The remaining two (application_answers, ats_playbook) are noun phrases rather than verb-led, a minor deviation that still reads clearly.
Seven tools is well-scoped for a resume-tailoring workflow, and each tool maps to a distinct step (list, preview, validate, build, score, form answers, ATS guidance). No redundant or filler tools.
The surface covers the consume/validate/build/score lifecycle plus application-form and ATS support, which is strong for the stated purpose. The main gap is authoring: there is no create/update/delete for versions or content, so resume editing must happen outside the server (implied by the 'content directory' model), a minor workaround.