de en es ja ko ru zh

job-search-mcp

Name: job-search-mcp
Author: Servation

by Servation

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

job-search-mcp

Персональный ассистент по поиску работы для Claude Desktop. Вы просите Claude найти вакансии — он ищет по настоящим доскам вакансий, оценивает каждую от 0 до 100 по тому, насколько она вам подходит, и показывает их на ранжированной доске, которой можно управлять в один клик. Всё работает локально — никаких API-ключей и аккаунтов не требуется.

Это MCP-приложение: небольшой сервер, с которым общается Claude Desktop, плюс встроенная доска, отображающаяся прямо в чате.

Область применения: он заточен под инженерные вакансии в сфере ПО в США (встроенные источники и фильтры по ролям ориентированы на американских tech-работодателей). В других областях или регионах результаты будут скудными.
Где работает: создан и протестирован для Claude Desktop. Он также должен работать в других MCP-клиентах, которые одновременно запускают локальный (stdio) сервер и отображают UI MCP-приложений, например VS Code (Copilot), Cursor или Goose (не тестировалось). Клиенты только с удалённым доступом (ChatGPT, Claude в вебе/на мобильных) не могут запустить локальный сервер, поэтому работать не будут.

Что он делает

Ищет по настоящим доскам вакансий — LinkedIn плюс 8 источников вакансий/ATS (Greenhouse, Lever, Ashby, Workday, SmartRecruiters, Hacker News, RemoteOK, Remotive), используя ваши целевые роли и местоположение.
Оценивает каждую вакансию под вас — Claude читает полное описание и ставит оценку соответствия от 0 до 100 с пояснением в одну строку, учитывая ваши навыки, годы опыта, соответствие уровню и роль.
Позволяет быстро разбирать вакансии — Apply / Skip на каждой карточке или массово («отклонить всё ниже 60»).
Запоминает — ведёт постоянно пополняемый шорт-лист, трекер того, куда вы откликнулись, и не покажет одну и ту же вакансию дважды (в течение 6 месяцев).

Related MCP server: Jobless MCP

Установка

1. Добавьте его в Claude Desktop. Откройте файл конфигурации:

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

Добавьте это в раздел "mcpServers" — npx сам загрузит опубликованный пакет, клонирование и сборка не нужны:

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

2. Полностью закройте и снова откройте Claude Desktop (в Windows выходите через системный трей — закрытия окна недостаточно). На этом всё.

npm install
npm run build

Затем укажите в конфигурации на dist/main.js из этой папки:

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

Как использовать

Просто поговорите с Claude. Например:

«Сохрани мой профиль» — сначала вставьте своё резюме; Claude извлекает ваши навыки, роли, стаж и местоположение, чтобы поиск и оценка были подстроены под вас.
«Найди вакансии бэкенд-инженера в Калифорнии, senior-уровень, опубликованные на этой неделе».
«Найди вакансии с малым числом откликов» — добавляет фильтр LinkedIn по малому числу откликов.
«Отклони всё, что ниже 60».
«Покажи, куда я откликнулся».
«Пересчитай оценки на доске».

Типичный первый запуск: сохраните профиль → «найти вакансии» → Claude оценивает их и показывает ранжированную доску → вы жмёте Apply/Skip.

Доска

Доска — это постоянно пополняемый шорт-лист. Вакансия остаётся на ней, пока вы не нажмёте Apply (она переходит в ваш трекер) или Skip (скрывается навсегда). Новые поиски автоматически пропускают вакансии, которые уже есть на доске, в трекере, отклонены или показывались за последние 6 месяцев, — так что вы никогда не увидите одно и то же объявление дважды подряд.

Нажмите Applied или Skip на карточке или попросите Claude сделать это. Если вы обработали вакансию в виджете, это сохранится.

Инструменты (для справки)

Вы редко вызываете их по имени — Claude сам выбирает нужный — но вот что под капотом:

Инструмент	Что делает
`find_jobs`	Ищет на досках вакансии по вашим целевым ролям/местоположению (с опциональными фильтрами: уровень, тип, свежесть, удалённая работа, зарплата, число откликов, источник).
`evaluate_jobs`	Claude оценивает найденные вакансии по соответствию от 0 до 100 (запускается автоматически после поиска).
`show_board`	Показывает ранжированную доску (или ваш трекер `saved`).
`set_status`	Apply / Skip / сохранить отдельную вакансию (это также кнопки на карточках).
`bulk_status`	Массово обрабатывает сразу много вакансий по оценке или источнику, например отклонить всё ниже 60.
`whats_promising`	Выводит текущую доску в виде текста (все оценённые вакансии + всё, что ещё не оценено).
`review_saved`	Ваш трекер — вакансии, которые вы сохранили или куда откликнулись.
`rescore_board`	Пересчитывает оценки всех вакансий на доске с нуля.
`clear_jobs`	Наводит порядок: очищает неоценённые остатки или всю доску (не затрагивает откликнувшиеся/отклонённые).
`save_profile`	Сохраняет профиль из вашего резюме (используется для поиска и оценки).

Где хранятся ваши данные

Один JSON-файл на вашей машине — никакого облака, ничего никуда не отправляется, кроме досок вакансий, по которым вы ищете:

При установке: ~/.job-search-mcp/jobs.json
При запуске из исходников: ./data/jobs.json
Можно переопределить с помощью переменной окружения JOB_SEARCH_MCP_DATA.

Опционально: режим LinkedIn Premium

По умолчанию LinkedIn использует свои публичные гостевые эндпоинты: не нужен вход и нет риска для аккаунта, и вы всё равно получаете полные описания вакансий. Учтите, что автоматический доступ по-прежнему выполняется с вашего IP и противоречит Пользовательскому соглашению LinkedIn даже в гостевом режиме, поэтому используйте его на своё усмотрение. Если вы хотите получать более полные/Premium данные, можете использовать аккаунт, в который вы вошли, добавив блок env в конфигурацию сервера:

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

Возьмите оба файла cookie из вкладки linkedin.com, где вы выполнили вход: DevTools → Application → Cookies.

⚠️ Внимание: это нарушает Условия использования LinkedIn и может привести к пометке или ограничению вашего аккаунта. Кроме того, срок действия файлов cookie истекает примерно раз в месяц, а внутренние эндпоинты LinkedIn меняются без предупреждения. Если что-то не сработает, автоматически выполняется откат к гостевому режиму. Не добавляйте блок env, чтобы оставаться в полной безопасности (только гостевой режим).

Как работает оценка

Оценку напрямую выполняет Claude (хост-модель): он читает каждое описание и оценивает соответствие — оценки получаются хорошо откалиброванными. Детерминированная формула (computeMatchScore в scoring.ts) оставлена как запасной вариант для тех, кто запускает более слабую локальную модель, которая склонна завышать оценки всему; по умолчанию она не активна.

Разработка

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

Сервер работает только через stdio (main.ts → server.ts); UI — это React-приложение, собранное в один встроенный HTML-файл (src/mcp-app.tsx → dist/mcp-app.html), который сервер отдаёт как ресурс ui://.

Для работы над UI используйте harness/. Это локальная замена Claude Desktop, которая рендерит виджет поверх синтетического хранилища вакансий и реального моста ui/*. Если открыть dist/mcp-app.html во вкладке браузера, вы увидите только «Connecting…», а всё, что скорее всего может сломаться (открытие ссылок, темизация, обновление после монтирования), управляется хостом, поэтому такие проблемы проявляются только при наличии хоста на другом конце.

Если источник вакансий перестал отвечать, npm run canary подскажет, какой именно. Слаги компаний часто протухают, поэтому исправление обычно нужно вносить в удалённый реестр слагов, который updateCompanyDirectoriesFromRegistry() перечитывает в рантайме, а не в новый релиз.

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.

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.

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.

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.

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.

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'.

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.

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.

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

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.

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

Output 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).

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

ActivityStale

ResponsivenessNo issues

Resources

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.
Product Management Search Workplace & Productivity
212
https://www.foundrole.com/mcp
HopeHire C
in.hopehire
Tailor resumes, score ATS fit, find hiring leads, and send cold outreach, from your agent.
App Automation Email
1671
https://hopehire.in/mcp
ApplyKoalaOAuth
com.applykoala
Job search for your AI: save jobs, research companies, keep stories, track applications.
Search Project Management Note Taking
1
https://applykoala.com/mcp
CareerCornerOAuth
ai.careercorner
Your personal career coach. Scanning jobs for you, daily.
Search Web Scraping App Automation
1
https://careercorner.ai/api/mcp

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 2 months 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 5 months ago (2026-05-22 18:01 UTC)
2
MIT
JobPilot MCP
Browser Automation Search App Automation
TheCodeDaniel
A
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 7 months ago (2026-03-25 11:49 UTC)
11
MIT
job-search-mcp
Search Web Scraping
jppoamaral
A
license
Not graded
quality
D
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 3 months ago (2026-08-02 21:12 UTC)
MIT