job-radar-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| JOB_MCP_DATA_DIR | No | The absolute path to your job-radar vault folder (the data directory the server reads and writes Markdown files in). | ~/job-radar-vault |
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": true
} |
| prompts | {
"listChanged": true
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| record_gapA | Records that a job offer asks for a skill the user does NOT have. If the term is already in the radar its count goes up by one and the source is added; otherwise it is created with count 1. It never duplicates. Call it once per skill the offer asks for that is missing from the user's profile, including terms the user could not define in an interview. Never call it for something already in skills.md. |
| list_gapsA | Returns every gap in the radar sorted by count, highest first: the top entries are what most offers have asked for, and therefore the most urgent to learn. |
| confirm_skillA | Graduation: confirms the user now has a skill that was in the radar. Removes it from gaps.md and adds it to skills.md with its level and evidence. It is the ONLY path from gap to profile. Use it only when the user confirms they have acquired it (certification, project or real experience), never on your own initiative. |
| update_skill_levelA | Changes the level of a term that is ALREADY in skills.md. For something that is not in the profile yet, use confirm_skill. |
| save_offerA | Creates or updates an offer file with its analysis. If the offer already exists ONLY the analysis is replaced: status and interview notes are kept. |
| set_offer_statusA | Moves an offer along its lifecycle and logs the change with a date. Lifecycle: analyzed -> applied -> interview -> offer -> accepted. Side exits from any point: rejected (the company says no) and discarded (the user decides to stop). |
| add_offer_noteA | Adds a dated note to the 'Interview notes' section of an offer: who interviewed the user, what they asked, feedback received, or anything worth rereading before the next round. Notes accumulate, they are never overwritten. |
| render_cvA | Writes output/cv-.html, a version of the CV tailored to one offer: it chooses which projects, which lines of each project, which bullets and which tags go in, and in what order. If not everything fits, trim lines inside each project before dropping a whole project. It CANNOT invent content: everything must already exist in profile/cv-data.json, and the whole call fails if you cite an id or tag that is not there. Only headline, summary and location accept free text, because they are framing. Omit any section to keep it complete as is. Do NOT call it on your own after an analysis: propose the tailoring and wait for the user to ask for it. |
| pingA | Checks that the server is alive and which data folder it is working on. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| analyze_offer | Returns the analysis template filled in with your current skills profile, CV and criteria (including your career goal), ready for you to paste the offer text below. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| skills | What the user ALREADY has, by category, at level [solid] or [partial]. It never contains gaps. |
| gaps | What the market asks for and the user does NOT have, with a count of how many offers asked for it, sorted from most to least urgent. |
| cv | The user's CV in Markdown: experience and projects with their context and stack. It is the source of concrete evidence to cite when analysing an offer. |
| cv-data | The CV content split into ids: every bullet, tag and project on its own. It is the only thing render_cv can choose from, so read it to see what is available before tailoring a CV. |
| criteria | The user's career goal, deal-breakers and scoring axes: what makes an offer worth the time. |
| offers | Every analysed offer with its current status, to see the pipeline at a glance. |
TDQS
Scored across 9 tools
Each tool targets a distinct resource+action: skill-gap recording (record_gap), gap graduation (confirm_skill), level edits on existing skills (update_skill_level), offer persistence (save_offer), lifecycle (set_offer_status), notes (add_offer_note), and CV rendering (render_cv). The three skill-related tools are the closest, but their descriptions explicitly disambiguate (missing vs. acquired vs. already-profiled), so misselection is unlikely.
Almost every name follows a clean verb_noun pattern (record_gap, confirm_skill, update_skill_level, list_gaps, save_offer, set_offer_status, add_offer_note, render_cv) with no casing mixups. The lone exception is the health check 'ping', which breaks the pattern but is a conventional outlier, so the set stays highly predictable.
Nine tools is a tight, well-scoped set for a job-search assistant spanning three coherent areas (skills/gaps, offers, CV). Every tool earns its place with no redundant operations, falling squarely in the ideal 3-15 range.
The skill side covers create/graduate/update/list and offers cover save/status/notes, plus CV rendering, but there is no read/list operation for offers (no list_offers or get_offer) and no list_skills, leaving agents without a way to enumerate tracked offers or the full profile. These are notable read-side gaps even though the write workflows are solid.