job-search-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| QDRANT_URL | Yes | Qdrant vector store connection URL (Cloud or self-hosted) | |
| NOTION_API_KEY | Yes | Notion API key for the tracking store | |
| QDRANT_API_KEY | No | Qdrant API key for authentication | |
| TRACKING_SCHEMA_PATH | No | Path to the tracking_schema.yaml file | tracking_schema.yaml |
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 |
|---|---|
| match_jobA | Retrieve resume/experience evidence relevant to a job description. Args: job_description: The full text of the job description to match against. source_url: Optional URL the job description was pulled from, for reference. Returns a heuristic retrieval_score (top-match cosine similarity) and the retrieved resume chunks with their individual similarity scores. Does not synthesize strengths/gaps/notes — reason over the retrieved evidence yourself, applying the job-fit://rubric resource linked in this result. |
| push_to_trackerA | Write an evaluate_fit result to the configured tracking store (Notion). Args: job_id: The Notion page ID of the job you already track. Updates that existing row in place — never creates a new row. verdict: The full evaluate_fit output (see docs/evaluate_fit_schema.md). dry_run: If true, returns the mapped Notion properties payload without writing anything, so you can review it first. Only the fields your tracking_schema.yaml marks tool-populated are touched — every other, manual field on the row (company, comp range, source, work arrangement, etc.) is left as-is. See docs/adr/0011-configurable-tracking-field-schema.md. A misconfigured tool-populated field (an unrecognized derived_from,
or — on a real write, not dry_run — a notion.property that doesn't
exist on your database) is skipped rather than failing the whole
write; check |
| list_applicationsA | List tracked jobs from the configured tracking store (Notion). Args: status: If given, only return rows whose Status matches exactly (e.g. "Not yet applied", "Applied"). Case-sensitive — must match the tracking store's status value exactly. Omit to return every tracked row. Each entry has job_id plus whatever tool-populated fields your tracking_schema.yaml declares (see docs/adr/0011-configurable-tracking-field-schema.md) — typically status, fit_rating, and notes. Statuses beyond "Not yet applied" (Applied, Recruiter screen, ...) are manual edits made in Notion, not something this server drives. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| job-fit-rubric | 5-layer rubric (hard gates, domain match, scope match, preference/logistics, red flags) for turning match_job's retrieved evidence into a fit bucket. retrieval_score alone is not a reliable fit signal — apply this instead. |
TDQS
Scored across 3 tools
The three tools have clearly distinct purposes: match_job retrieves evidence, push_to_tracker writes results, and list_applications reads tracked jobs. There's no real overlap between them. The only minor confusion is that push_to_tracker's write and list_applications's read both touch the same Notion store, but their actions are opposite and clear.
All three names follow a clear verb_noun pattern: match_job, push_to_tracker, list_applications. Each uses an imperative verb followed by the target. Minor inconsistency: 'push_to_tracker' is a multi-word noun phrase while 'match_job' and 'list_applications' are more compact, but the pattern is consistent enough.
Three tools is on the low side but reasonable for a focused job-search workflow. The surface covers matching, tracking, and listing, which are the core operations. One could argue a remove/cleanup tool is missing, but the scope of an MCP for job search is narrow enough that 3 tools feels appropriately scoped, not thin.
The server covers the core workflow: match a job, push the evaluation to the tracker, and list tracked applications. However, there are notable gaps — no way to create a new job row (push_to_tracker explicitly requires an existing job_id and never creates a row), no update/retract on previous evaluations, and no removal of stale entries. The create-to-track action is a significant missing lifecycle step for a job-search tracking workflow.