What can you do with this server?

The job-search-mcp server is a personal job-search assistant that searches real job boards, scores jobs for your fit, and lets you triage them in an interactive ranked board — all from an MCP client like Claude Desktop. * Search for jobs: Query live boards including LinkedIn, Greenhouse, Lever, Ashby, Workday, SmartRecruiters, Hacker News, RemoteOK, and Remotive, with filters for location, seniority, job type, remote preference, salary, recency, and applicant count. * Save your profile: Paste your resume to extract and store your name, skills, target roles, location, years of experience, remote preference, and blocked companies — used to personalize search and scoring. * Score jobs for fit: Automatically or manually assign each job a 0–100 fit score with a one-line reason, calibrated against your profile. * Display an interactive board: Render a ranked, clickable job board with score, reason, and Apply/Skip buttons per card, or switch to the saved/applied tracker view. * Triage individually: Mark a single job as saved, applied, dismissed, or discovered, with optional notes. * Bulk triage: Dismiss, save, or apply to many jobs at once by score threshold (e.g., dismiss everything under 60) or by source. * Review the board: List all current jobs — scored and unscored — with IDs and descriptions, or view your saved/applied tracker as text. * Re-score the board: Wipe existing scores and re-evaluate every job from scratch, optionally including saved/applied jobs. * Clear jobs: Remove unscored leftovers or wipe the entire board without affecting your applied/dismissed history. * Data persistence: Triage decisions are stored locally; dismissed jobs won't reappear for six months. * Optional LinkedIn Premium integration: Connect via cookies for richer data, with a guest-mode fallback.

Which integrations are available for this server?

Searches and evaluates job listings from Greenhouse's ATS, providing fit scores and triage capabilities.

How do I use job-search-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@job-search-mcp find senior backend engineer jobs in California" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

de en es ja ko ru zh

job-search-mcp

by Servation

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

job-search-mcp

A personal job-search assistant for Claude Desktop. You ask Claude to find jobs; it searches the real job boards, scores each one 0–100 for how well it fits you, and shows them on a ranked board you can triage with one click. Everything runs locally — no API keys, no accounts required.

It's an MCP App: a small server Claude Desktop talks to, plus an inline board that renders right in the chat.

Scope: it's tuned for US software-engineering roles (the built-in sources and role filters target US tech employers). Other fields or regions will return sparse results.
Works in: built and tested for Claude Desktop. It should also work in other MCP clients that both run a local (stdio) server and render MCP App UIs, such as VS Code (Copilot), Cursor, or Goose (untested). Remote-only clients (ChatGPT, Claude on web/mobile) can't launch a local server, so they won't work.

What it does

Searches real job boards — LinkedIn plus 8 ATS/job sources (Greenhouse, Lever, Ashby, Workday, SmartRecruiters, Hacker News, RemoteOK, Remotive), using your target roles and location.
Scores each job for you — Claude reads the full description and gives it a 0–100 fit score with a one-line reason, weighing your skills, years of experience, seniority fit, and the role.
Lets you triage fast — Apply / Skip on each card, or in bulk ("dismiss everything under 60").
Remembers — keeps a running shortlist, a tracker of what you've applied to, and won't show you the same job twice (for 6 months).

Related MCP server: Jobless MCP

Setup

1. Tell Claude Desktop about it. Open your config file:

Windows: %APPDATA%\Claude\claude_desktop_config.json
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

Add this under "mcpServers" — npx fetches the published package for you, no cloning or building required:

{
  "mcpServers": {
    "job-search": {
      "command": "npx",
      "args": ["-y", "@servation/job-search-mcp"]
    }
  }
}

2. Fully quit and reopen Claude Desktop (on Windows, quit it from the system tray — closing the window isn't enough). That's it.

npm install
npm run build

Then point the config at this folder's dist/main.js instead:

{
  "mcpServers": {
    "job-search": {
      "command": "node",
      "args": ["D:\\job-search-mcp\\dist\\main.js"]
    }
  }
}

How to use it

Just talk to Claude. For example:

"Save my profile" — paste your resume first; Claude pulls out your skills, roles, years, and location so searches and scoring are tailored to you.
"Find backend engineer jobs in California, senior level, posted this week."
"Find low-applicant jobs" — adds LinkedIn's early-applicant filter.
"Dismiss everything under 60."
"Show what I've applied to."
"Re-score the board."

A typical first run: save your profile → "find jobs" → Claude scores them and shows the ranked board → you Apply/Skip.

The board

The board is a running shortlist. A job stays on it until you Apply (moves to your tracker) or Skip (hidden for good). New searches automatically skip jobs already on the board, in your tracker, dismissed, or shown in the last 6 months — so you never see the same listing twice in a row.

Click Applied or Skip on a card, or ask Claude to do it. Triaged in the widget, it sticks.

Tools (for reference)

You rarely call these by name — Claude picks the right one — but here's what's under the hood:

Tool	What it does
`find_jobs`	Search the boards for your roles/location (with optional filters: seniority, type, recency, remote, salary, applicants, source).
`evaluate_jobs`	Claude scores the found jobs 0–100 for fit (runs automatically after a search).
`show_board`	Display the ranked board (or your `saved` tracker).
`set_status`	Apply / Skip / save a single job (also the card buttons).
`bulk_status`	Triage many at once by score or source, e.g. dismiss everything under 60.
`whats_promising`	List the current board as text (all scored jobs + anything still unscored).
`review_saved`	Your tracker — jobs you've saved or applied to.
`rescore_board`	Re-score every job on the board from scratch.
`clear_jobs`	Declutter: clear unscored leftovers or the whole board (never touches applied/dismissed).
`save_profile`	Save your resume profile (drives search + scoring).

Where your data lives

One JSON file on your machine — no cloud, nothing sent anywhere except the job boards you search:

Installed: ~/.job-search-mcp/jobs.json
Running from source: ./data/jobs.json
Override with the JOB_SEARCH_MCP_DATA environment variable.

Optional: LinkedIn Premium mode

By default LinkedIn uses its public guest endpoints: no login and no account-login risk, and you already get full job descriptions. Note that automated access still runs from your own IP and is against LinkedIn's User Agreement even in guest mode, so use it at your discretion. If you want richer/Premium data, you can use your logged-in account by adding an env block to the server config:

"job-search": {
  "command": "npx",
  "args": ["-y", "@servation/job-search-mcp"],
  "env": {
    "LINKEDIN_LI_AT": "<your li_at cookie>",
    "LINKEDIN_JSESSIONID": "ajax:1234567890123456789"
  }
}

Get both cookies from a logged-in linkedin.com tab → DevTools → Application → Cookies.

⚠️ Heads up: this is against LinkedIn's Terms of Service and can get your account flagged or restricted. The cookies also expire about monthly and LinkedIn's internal endpoints change without notice. If anything fails it falls back to guest mode automatically. Leave the env block out to stay fully safe (guest-only).

How scoring works

Claude (the host model) does the scoring directly — it reads each description and judges fit, which is well-calibrated. A deterministic formula (computeMatchScore in scoring.ts) is kept as a fallback for anyone running a weaker local model that tends to over-rank everything; it's not active by default.

Development

npm run typecheck    # type-check UI + server + harness
npm run build        # build the UI bundle (vite single-file) + compile the server (tsc)
npm run serve:stdio  # run the server from source (tsx) for local testing
npm run harness      # work on the review UI without Claude Desktop (see harness/)
npm run canary       # check every job source is still returning postings

The server is stdio-only (main.ts → server.ts); the UI is a React app bundled to a single inlined HTML file (src/mcp-app.tsx → dist/mcp-app.html) that the server serves as a ui:// resource.

Working on the UI, use harness/. It is a local stand-in for Claude Desktop that renders the widget against a synthetic job store and a real ui/* bridge. Opening dist/mcp-app.html in a browser tab just gets you "Connecting…", and the things most likely to break (link opening, theming, the post-mount refresh) are all host-mediated, so they only show up with a host on the other end.

If a job source goes dark, npm run canary tells you which one. Company slugs rot often, so the fix usually belongs in the remote slug registry that updateCompanyDirectoriesFromRegistry() re-reads at runtime, rather than in a new release.

Available Tools

10 tools

bulk_statusBulk TriageA

Triage MANY board jobs at once by score and/or source — e.g. dismiss every scored job under 60. Applies status to all scanned (board) jobs matching the filters; the server selects them, so you do NOT need the individual job ids. below_score/above_score match SCORED jobs only (use clear_jobs for un-evaluated ones). Provide at least one filter. Returns text; call show_board afterward to display.

ParametersJSON Schema

Name	Required	Description
`notes`	No	Optional note to attach to every matched job.
`source`	No	Restrict to one source.
`status`	Yes	Status to apply to every match.
`above_score`	No	Match scored jobs with matchScore AT OR ABOVE this.
`below_score`	No	Match scored jobs with matchScore BELOW this (e.g. 60).

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses key behavioral traits: it applies status to all scanned board jobs matching filters, server selects jobs (no need for IDs), returns text, and recommends post-call action (call show_board). No annotations exist to contradict.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences with no wasted words. First sentence gives purpose and example, second explains mechanism, third clarifies scope and provides follow-up instruction. Efficient and well-organized.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a bulk operation with 5 params, no output schema, and no annotations, the description covers essential behavioral aspects (selection, return format, post-call step). Could mention error handling or rate limits, but not required for basic usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% (baseline 3). Description adds value by clarifying that `below_score`/`above_score` match only SCORED jobs (linking to `clear_jobs`), and implies that at least one filter is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with a specific verb ('Triage') and resource ('board jobs'), and gives an example ('dismiss every scored job under 60'). It distinguishes itself from sibling 'clear_jobs' by noting the scoping to scored jobs only.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use (bulk triage by score/source) and when to use alternatives ('use clear_jobs for un-evaluated ones'). Also provides a usage constraint: 'Provide at least one filter'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

clear_jobsClear JobsA

Clear jobs from the review board. which='unscored' (default) removes only the not-yet-evaluated leftovers; which='all' clears the whole board. Saved/applied jobs (the tracker) and dismissed jobs are NOT affected — dismissed jobs still won't be re-sourced. Returns text; call show_board to display.

ParametersJSON Schema

Name	Required	Description	Default
`which`	No	'unscored' (default) clears un-evaluated jobs; 'all' clears the whole board.

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It discloses that saved/applied and dismissed jobs are not affected, and that dismissed jobs remain dismissed. The return type ('text') is mentioned. It could add details on reversibility or permissions but is fairly transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three concise sentences with no wasted words. It is front-loaded with the core action and provides necessary details efficiently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity, the description covers primary behavior, return type, and exclusions. It is mostly complete but could mention error scenarios or permissions for full completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema coverage is 100% with enum descriptions. The description adds minimal extra context ('not-yet-evaluated leftovers' vs 'un-evaluated in schema). Baseline 3 is appropriate as it doesn't significantly enhance parameter meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool clears jobs from the review board, distinguishing between 'unscored' (only un-evaluated jobs) and 'all' (entire board). This differentiates it from siblings like 'evaluate_jobs' or 'bulk_status'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description details when to use each 'which' option and notes that dismissed jobs are unaffected, providing implicit guidance. However, it does not explicitly compare this tool to siblings like 'set_status' or 'rescore_board' for alternative actions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

evaluate_jobsEvaluate JobsA

Score one or more sourced jobs for THIS candidate (holistic). YOU assign each job a 0-100 fit score directly, using the candidate summary (shown in find_jobs / whats_promising) and the job description. Weigh the must-have requirements, the candidate's actual skills and years of experience (a role demanding far more seniority/years than the candidate has should score LOWER), domain fit, and standout strengths. Calibrate and use the FULL range — do not bunch everything at 80+: 80-100 = strong fit and realistic; 60-79 = good with real gaps; 40-59 = partial/stretch (e.g. wrong level); below 40 = poor or wrong field. Pass { job_id, score, reason } per job. Use the EXACT bracketed ids; do not invent them. Score every job in one call. Returns text; call show_board afterward to display the ranked board.

ParametersJSON Schema

Name	Required	Description	Default
`evaluations`	Yes	One entry per job to score.

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided; description discloses the scoring behavior, range usage, and return type ('Returns text'). However, does not explicitly state if it modifies state or requires permissions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Moderate length but well-structured with clear instructions, front-loaded purpose, and every sentence adds value. Slightly wordy but necessary for complex scoring guidelines.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers the scoring criteria, calibration, and post-call step. Lacks explicit return format details, but overall complete given the complexity and no output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with good field descriptions. Description adds contextual meaning about scoring logic, calibration, and post-call actions, going beyond schema details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it scores one or more sourced jobs for a candidate, assigning 0-100 fit scores. Distinct from siblings like find_jobs (finding) and show_board (displaying).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says to use after finding jobs ('sourced jobs'), instructs to score all jobs in one call, and recommends calling show_board afterward. Also provides calibration advice.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

find_jobsFind JobsA

Source live jobs (LinkedIn + Greenhouse, Lever, Ashby, Workday, SmartRecruiters, Hacker News, RemoteOK, Remotive), dedup them, and return them as text with full descriptions. Uses the saved profile's roles/location by default; pass query/location/filters to override. This returns UNSCORED jobs and does NOT show a card UI — immediately score all of them with evaluate_jobs (a 0-100 fit score + reason each), then show_board once, to present the single ranked board. Do not just list them back.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Max jobs to return/persist this run (default 15).
`query`	No	Role/keyword filter, e.g. 'backend java spring'. Overrides the profile's target roles.
`remote`	No	Workplace type (LinkedIn); also sets remote preference.
`sort_by`	No	LinkedIn result ordering.
`sources`	No	Restrict to these sources (default: all).
`job_type`	No	Employment type (LinkedIn).
`location`	No	Location filter, e.g. 'California' or 'Remote'. Overrides the profile's search location.
`max_years`	No	Candidate's years of experience for this search (overrides the saved profile); also defaults the seniority filter.
`salary_min`	No	Minimum annual salary filter (LinkedIn), e.g. 100000.
`date_posted`	No	Recency filter (LinkedIn).
`verify_urls`	No	If true, network-verify each job URL (slower). Default false.
`max_applicants`	No	Surface low-applicant LinkedIn jobs (uses LinkedIn's early-applicant filter, ~under 25). Exact applicant-count filtering requires the LinkedIn cookie.
`experience_level`	No	Seniority filter (LinkedIn).

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description covers key behaviors: dedup, returns text, no card UI, uses saved profile by default. It mentions verify_urls performance implication but lacks details on rate limits or auth. Overall transparent enough for agent decision-making.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise—two sentences plus a workflow directive. It front-loads the purpose and packs necessary guidance without fluff. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 13 parameters, no output schema, and multiple siblings, the description adequately explains the tool's output format (text), the workflow, and default behavior. Could mention the default limit value (15) but schema covers it. Overall complete for practical use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so parameters are well-documented there. The tool description adds context about defaults and overrides, but this is minimal extra value. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it sources live jobs from multiple platforms, deduplicates them, returns text with full descriptions, and distinguishes its role from sibling tools like evaluate_jobs and show_board. It specifies the action and resource precisely.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit workflow instructions: the tool returns unscored jobs, and the agent must then call evaluate_jobs and show_board. It also explains how to override default profile settings. This clearly tells when and how to use the tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

rescore_boardRe-score BoardA

Re-score the WHOLE board from scratch — every job, INCLUDING ones that already have a score. Use this when the user asks to 'rescore'/'re-evaluate' the board or after the scoring approach changed. Returns all board jobs with their ids + descriptions; call evaluate_jobs with a FRESH { job_id, score, reason } for EACH (do not skip already-scored ones), then call show_board. Set include_saved=true to also re-score the saved/applied tracker.

ParametersJSON Schema

Name	Required	Description	Default
`include_saved`	No	Also re-score the saved/applied tracker jobs (default false).

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description fully discloses that it rescore from scratch, includes already scored jobs, returns job ids+descriptions, and requires subsequent actions. It also explains the include_saved parameter behavior transparently.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise (3 sentences) and front-loaded with the main action. However, it could be slightly more structured (e.g., separate sections) but each sentence adds necessary value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's composite nature (involves a whole-board rescore, returns data, and requires follow-up calls), the description covers the action, trigger conditions, return format, and required subsequent steps (evaluate_jobs and show_board). No output schema needed because return is clearly described.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% for the single parameter. The description adds meaning by explaining the effect of setting include_saved=true to also re-score the saved/applied tracker, which goes slightly beyond the schema comment.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action 're-score the whole board from scratch' and specifies the resource 'board'. It distinguishes from sibling tools like evaluate_jobs by noting it rescore every job including already scored ones, and sets context for when to use it.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says when to use: 'when the user asks to rescore/evaluate the board or after the scoring approach changed.' It also provides direct guidance: 'call evaluate_jobs with FRESH... then call show_board,' and warns not to skip already scored jobs.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

review_savedReview Saved JobsA

List the tracker as text: jobs marked saved (interested) or applied, with their status, score, and notes. Use this to see what you're tracking or have applied to. To DISPLAY the tracker widget, call show_board with view='saved'.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It accurately portrays a read-only listing behavior without mentioning destructive or side effects. It could briefly note that the output is plain text, but overall transparency is high.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, each purposeful. The first sentence defines the output, the second states usage, the third points to an alternative. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters or output schema, the description covers the key aspects: what is listed (saved/applied jobs), the fields included (status, score, notes), and the differentiation from show_board. It could mention ordering or limits, but is sufficient for a simple list tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, and schema coverage is 100% (vacuously). Per calibration, baseline is 4. The description does not need to add parameter info.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists jobs marked as saved or applied with their status, score, and notes. It specifies the resource ('tracker') and action ('list'), and distinguishes from the sibling tool show_board, which displays a widget.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly tells when to use this tool ('to see what you're tracking or have applied to') and when not to, by directing to an alternative ('To DISPLAY the tracker widget, call show_board with view='saved'').

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

save_profileSave Resume ProfileA

Extract the candidate's profile from their resume text (which the user pastes in chat) and save it. Pull: full name; core technical skills; suggested target roles; preferred/search location; total years of professional experience (integer); and pass the resume text as rawText. The profile is used by find_jobs (target roles + location) and by scoring (years of experience drives the experience penalty), so set yearsOfExperience accurately. Merges with any existing profile.

ParametersJSON Schema

Name	Required	Description
`name`	No	Candidate's full name.
`skills`	No	Core technical skills.
`rawText`	No	The full resume text, stored for reference.
`targetRoles`	No	Suggested target job titles.
`prefersRemote`	No	Whether the candidate prefers remote.
`searchLocation`	No	Preferred location, e.g. 'California' or 'Remote'.
`blockedCompanies`	No	Companies to exclude from sourcing.
`yearsOfExperience`	No	Total years of professional experience (integer).

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description covers the core behavior: extraction, saving, merging, and downstream impact. It does not disclose rate limits or auth needs, but the simple save operation is sufficiently transparent for an AI agent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is four sentences with no wasted words. The first sentence immediately states the core action, and subsequent sentences add necessary context efficiently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations and no output schema, the description adequately covers purpose, behavior, and linkage to other tools. It could mention what happens with missing fields or the return value, but overall it is sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds meaning beyond the input schema by explaining how yearsOfExperience drives the experience penalty and that the tool merges with existing profiles. It omits two parameters (prefersRemote, blockedCompanies) from the explanation, but schema coverage is high at 100%.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool extracts a candidate's profile from resume text, saves it, and lists the specific fields pulled. It also explains the profile's downstream use by find_jobs and scoring, distinguishing it from sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains that the profile is used for job finding and scoring, implying when to use. It mentions merging behavior, but does not explicitly exclude alternative tools or provide when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

set_statusSet Job StatusA

Triage a job by id: 'saved' (interested/tracking), 'applied' (also stamps the date), 'dismissed' (skip), or 'discovered' (undo back to the board). Moves it between the scanned/saved/dismissed lists and persists. Optionally attach notes. Called by the review UI; also usable directly.

ParametersJSON Schema

Name	Required	Description
`notes`	No	Optional notes to attach to the job.
`job_id`	Yes	The job's id.
`status`	Yes	New triage status.

Output Schema

ParametersJSON Schema

Name	Required	Description
`jobs`	Yes
`view`	No
`count`	Yes
`scored`	Yes
`profile`	Yes

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses the effects of each status (e.g., 'applied' stamps date, 'discovered' undoes to board) and that the tool persists changes. With no annotations, these details are essential and well-covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences front-load the purpose and progressively add details: status list, behavior, notes, and usage context. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema, the description covers all necessary context: parameter semantics, behavioral side effects, and typical usage (review UI). It is fully sufficient for an agent to select and invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is 100%, the description adds significant value by explaining the meaning and behavioral impact of each status enum value and the optional notes parameter, going beyond the schema's simple type definitions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: triage a job by setting its status to one of four enumerated values, each with a specific meaning. It distinguishes from sibling tools like bulk_status by focusing on a single job.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It indicates the tool is called by the review UI and usable directly, but does not explicitly specify when to use it versus alternatives like bulk_status. No when-not-to-use guidance is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

show_boardShow BoardA

Display the job board (or the saved/applied tracker) as an interactive widget. Call this ONCE, at the end of a request, after doing the work (find_jobs/evaluate_jobs/bulk_status/clear_jobs/whats_promising are text-only and do NOT render). view='board' (default) shows the ranked board; view='saved' shows the tracker.

ParametersJSON Schema

Name	Required	Description	Default
`view`	No	'board' (default) = the ranked board; 'saved' = the applied/saved tracker.

Output Schema

ParametersJSON Schema

Name	Required	Description
`jobs`	Yes
`view`	No
`count`	Yes
`scored`	Yes
`profile`	Yes

TDQS

A4.7/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses it renders interactive widget, no side effects implied. With no annotations, description carries burden; could mention idempotency but not required for display tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with action and context. No extraneous words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Handles single parameter, output schema exists, description covers usage and view options. Complete for its simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage 100%. Description adds clarity on default view and what each view shows beyond enum values.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it displays a board/tracker as interactive widget. Distinguishes from siblings by noting text-only tools do NOT render.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says call once at end of request after other work. Specifies views and default. Contrasts with text-only siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

whats_promisingWhat's PromisingA

List the current job board as text: every scored job (with its id) and any UNSCORED jobs with their ids + descriptions so you can evaluate them. To score the unscored ones, call evaluate_jobs with the EXACT bracketed ids shown. Use this to review jobs already found (find_jobs only returns brand-new ones). To re-score jobs that ALREADY have a score, use rescore_board instead. To DISPLAY the board widget to the user, call show_board (this returns text for you to act on).

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Max unscored jobs to surface for evaluation (default 15).

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Despite no annotations, the description discloses that the tool returns text with job details and provides instructions for scoring. It implies a read-only operation, which is consistent. Could be slightly more explicit about side effects, but the context suggests no mutation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single paragraph that efficiently covers purpose, usage, and alternatives. It is front-loaded with the main action. Every sentence adds value, though slightly verbose; still very effective.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and one optional parameter, the description fully explains what the tool returns (textual listing of jobs) and how to use it in the broader workflow (evaluating, rescoring, displaying). It covers all necessary context for an agent to use it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The only parameter 'limit' is fully described in the input schema (max unscored jobs, default 15). The description does not add extra meaning beyond the schema, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists the current job board with scored and unscored jobs. It uses specific verb 'list' and resource 'job board', and distinguishes from siblings like find_jobs (brand-new jobs) and rescore_board (rescoring already scored jobs).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use: 'Use this to review jobs already found (find_jobs only returns brand-new ones).' Also specifies alternatives: rescore_board for re-scoring, show_board for displaying to user, evaluate_jobs for scoring unscored jobs.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

10 tool updatesv0.1.1Jul 1, 2026
- First observedbulk_status
- First observedclear_jobs
- First observedevaluate_jobs
- First observedfind_jobs
- First observedrescore_board
- First observedreview_saved
- First observedsave_profile
- First observedset_status
- First observedshow_board
- First observedwhats_promising

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.5/5.0

Scored 2026-07-01 03:35 across 10 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: bulk_status for bulk triage, clear_jobs for clearing, evaluate_jobs for scoring single jobs, find_jobs for sourcing, rescore_board for re-evaluating all, review_saved for tracker text, save_profile for profile, set_status for individual triage, show_board for display, and whats_promising for listing. No overlap.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., bulk_status, evaluate_jobs, save_profile). The only minor deviation is 'whats_promising' using a contraction, but it still follows the pattern and is easily readable.

Tool Count5/5

10 tools is well within the ideal 3-15 range for a focused job search server. Each tool addresses a necessary function without bloat, and the count feels natural for the domain.

Completeness4/5

The tool set covers the core workflow: sourcing (find_jobs), scoring (evaluate_jobs, rescore_board), triaging (bulk_status, set_status, clear_jobs), tracking (review_saved), display (show_board), and profile management (save_profile). Minor gaps like no explicit profile update tool exist, but save_profile merges, so it's almost complete.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

FoundRole — AI Job Search & Application Tracker MCP for Claude & ChatGPT AOAuth
io.github.foundrole
AI job search MCP — fact-checked jobs, application tracker, alerts. ChatGPT, Claude, Cursor.
Search
2
Trackly CLIOAuth
io.github.trackly-app
Job search for Claude, ChatGPT, Cursor. 250K+ jobs, 5,400+ companies. OAuth or stdio.
Search Research & Data
23
gemsift-mcp
io.github.erashev-fedor
AI resume triage for recruiters. Query your candidate pool from Claude or ChatGPT.
Search CRM AI & Machine Learning
2
HuntBoard A
ai.huntboard
Search real, recent job postings from company career pages and ATS boards, scored for fit.
Browser Automation Web Scraping
11

Related MCP Servers

JobSpy MCP Server
Web Scraping Search
chinpeerapat
A
license
Not graded
quality
A
maintenance
Enables job search and scraping across multiple job boards (LinkedIn, Indeed, Glassdoor, etc.) with advanced filtering, directly from Claude Desktop or other MCP clients.
Updated a month ago (2026-08-20 10:23 UTC)
6
MIT
Jobless MCP
Search App Automation
bendza
A
license
Not graded
quality
B
maintenance
Personalized job search inside Claude. Get ranked job matches based on your actual skills, not keywords.
Updated 4 months ago (2026-05-22 18:01 UTC)
2
MIT
JobPilot MCP
Browser Automation Search App Automation
TheCodeDaniel
F
license
A
quality
D
maintenance
Transforms Claude into an AI job-hunting assistant that searches remote job boards, scores roles against your CV, generates tailored cover letters, and logs everything to a Notion tracker.
Updated 6 months ago (2026-03-25 11:49 UTC)
11
-
job-search-mcp
Search Web Scraping
jppoamaral
A
license
Not graded
quality
C
maintenance
Enables searching and evaluating job postings from LinkedIn and freehire.me directly through Claude Desktop. Provides tools to search jobs, fetch full posting details, and assess candidate fit using eligibility scans and a scoring rubric.
Updated 2 months ago (2026-08-02 21:12 UTC)
MIT