Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@HH MCP Server search for senior backend vacancies in Moscow"
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.
MCP-сервер для автоматизации работы с hh.ru через браузерную автоматизацию (Playwright).
Поиск вакансий — по ключевым словам, городу, зарплате, опыту, графику (удалёнка/офис/гибрид)
Просмотр деталей вакансий — полное описание, требования, стек, условия
Управление резюме — просмотр списка и содержимого своих резюме
Отклики на вакансии — с сопроводительным письмом и ответами на вопросы работодателя
Отслеживание откликов — статусы всех отправленных откликов
Информация о работодателях — карточка компании
Related MCP server: HeadHunter API MCP Server
Python 3.12+
uv (менеджер пакетов)
cd hh-mcp-server
uv sync
uv run playwright install chromiumПеред первым использованием нужно авторизоваться на hh.ru:
uv run hh-mcp-server --loginОткроется браузер — войдите в свой аккаунт hh.ru. Сессия сохранится в ~/.hh-mcp/profile/state.json.
uv run hh-mcp-serveruv run hh-mcp-server --no-headlessuv run hh-mcp-server --transport streamable-http --port 8766Добавьте в .claude/settings.json:
{
"mcpServers": {
"hh": {
"command": "/path/to/uv",
"args": ["run", "--directory", "/path/to/hh-mcp-server", "hh-mcp-server"]
}
}
}Инструмент | Описание |
| Поиск вакансий по ключевым словам (keywords, area, salary, experience, schedule) |
| Подходящие вакансии для резюме (алгоритм hh.ru, до 1000 вакансий) |
| Детали вакансии по ID |
| Список резюме пользователя |
| Полное содержимое резюме |
| Отклик на вакансию (с письмом и ответами на вопросы) |
| Статусы откликов |
| Информация о компании |
| Закрытие браузера и сохранение сессии |
Инструмент get_recommended_vacancies использует алгоритм hh.ru для подбора вакансий на основе резюме (аналог страницы "Подходящие вакансии"):
get_recommended_vacancies(
resume_id="0fe69243ff063cb4720039ed1f574b71676a55",
max_pages=50 # до 1000 вакансий (20 на страницу)
)Это значительно точнее, чем keyword search — hh.ru анализирует опыт, навыки и должность из резюме.
Некоторые вакансии имеют обязательные вопросы от работодателя:
Первый вызов без question_answers — возвращает список вопросов
Второй вызов с question_answers — отправляет отклик
# Шаг 1: получить вопросы
apply_to_vacancy(vacancy_id="12345")
# → {"status": "questions_required", "questions": [...]}
# Шаг 2: отправить с ответами
apply_to_vacancy(
vacancy_id="12345",
resume_id="abc123",
cover_letter="Текст письма",
question_answers={"task_123_text": "Ответ на вопрос"}
)hh_mcp_server/
├── cli_main.py # CLI точка входа (--login, --no-headless, --transport)
├── server.py # FastMCP сервер, регистрация инструментов
├── constants.py # URL, пути, маппинги (города, графики, опыт)
├── exceptions.py # Кастомные исключения
├── drivers/
│ └── browser.py # Playwright: контекст, страница, сохранение сессии
├── tools/
│ ├── vacancy.py # Инструменты поиска и просмотра вакансий
│ ├── apply.py # Инструмент отклика на вакансию
│ ├── resume.py # Инструменты работы с резюме
│ ├── employer.py # Информация о работодателе
│ └── responses.py # Отслеживание откликов
├── scraping/
│ ├── selectors.py # CSS-селекторы для парсинга hh.ru
│ ├── extractor.py # Утилиты извлечения данных со страниц
│ ├── apply.py # Логика отклика (cookies, вопросы, письмо, submit)
│ └── resume.py # Парсинг страниц резюме
└── utils/
└── auth.py # Авторизация (login flow, проверка сессии)uv run hh-mcp-server --log-level DEBUGУровни: DEBUG, INFO, WARNING (по умолчанию), ERROR.
Apply to a vacancy on hh.ru.
Two-pass flow for vacancies with questions:
First call without question_answers -> returns questions list
Second call with question_answers filled -> submits application
Args: vacancy_id: hh.ru vacancy ID resume_id: Resume ID to use (from get_my_resumes) cover_letter: Cover letter text question_answers: Dict mapping question label to answer text
| Name | Required | Description | Default |
|---|---|---|---|
| resume_id | No | ||
| vacancy_id | Yes | ||
| cover_letter | No | ||
| question_answers | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the two-pass flow and that the first call returns a questions list. However, it omits behavioral traits like authorization requirements, potential side effects (e.g., irreversible submission), or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, well-structured, and front-loaded with the core purpose. It uses two concise paragraphs: one for the two-pass flow and one for parameter definitions, with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a mutating tool with a two-pass workflow, the description covers the main flow and parameter usage. However, it lacks details on prerequisites (e.g., must have a resume), error scenarios, and output structure. An output schema exists but is not shown; its presence partially mitigates the need for return value explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains all four parameters: vacancy_id as hh.ru ID, resume_id with source hint, cover_letter as text, and question_answers as dict mapping label to answer. This adds meaningful context beyond the schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Apply to a vacancy on hh.ru', which is a specific verb and resource. It distinguishes the tool from siblings like search_vacancies and get_responses by focusing on the application action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains the two-pass flow for vacancies with questions, guiding the agent on when to call without and with question_answers. It also references get_my_resumes for resume_id. However, it doesn't explicitly state when not to use this tool or compare to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Close the browser session and save state.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It discloses that state is saved, but does not mention side effects such as whether unsaved work is lost or if the session can be reopened.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that is front-loaded with the key action. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema, the description is adequate. It covers the core purpose and side effect (saving state), though could mention whether the session is destroyed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema coverage is 100%. The description adds no param info, which is acceptable given zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'close' and the resource 'browser session', and mentions saving state. It is distinct from sibling tools which deal with vacancies and resumes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any preconditions or context about when closing the session is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get company/employer information.
Args: employer_id: hh.ru employer ID
| Name | Required | Description | Default |
|---|---|---|---|
| employer_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose any behavioral traits such as side effects, rate limits, or return format. It merely states the basic action, leaving the agent uninformed about the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and to the point, but it could include more useful information without becoming verbose. It is adequately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity and the presence of an output schema, the description is minimally complete. However, it omits details about the returned information, which could be inferred but is not explicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter 'employer_id' is described as 'hh.ru employer ID', adding specific meaning beyond the schema's type 'string'. This clarifies the expected value, which is valuable given 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get company/employer information', which specifies the verb (get) and resource (employer info). The tool name and title reinforce this, and the sibling tools are all different in function, so it distinguishes adequately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, conditions, or exclusions relative to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get list of user's resumes on hh.ru.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states 'get list', implying read-only, but lacks details on authentication needs, rate limits, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence accurately conveys the purpose with no extraneous words. For a zero-parameter tool, this is optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and an existing output schema, the description is mostly complete. However, it omits mention of authentication requirements, though implied by 'user's resumes'. Still, minimal for context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. The description does not need to add parameter details; baseline score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get list of user's resumes', specifying the verb and resource. It effectively distinguishes from sibling tools like get_resume (singular) and get_responses, as it refers to the user's own resumes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as get_resume or get_responses. The description offers no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get vacancies recommended by hh.ru for a specific resume.
Uses hh.ru's matching algorithm to find vacancies that best fit the resume. This is equivalent to the "Подходящие вакансии" page.
Args: resume_id: Resume ID from get_my_resumes (e.g., "0fe69243ff063cb4720039ed1f574b71676a55") max_pages: Maximum pages to load (1-50, default 5, 20 vacancies per page)
| Name | Required | Description | Default |
|---|---|---|---|
| max_pages | No | ||
| resume_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. Discloses use of matching algorithm, page loading, vacancies per page, and parameter defaults/range. Does not mention side effects (read-only), rate limits, or error handling for invalid resume_id.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise paragraph followed by Args block. Good front-loading of purpose. Minor formatting improvement possible (e.g., bullet points), but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 parameters, no annotations, and output schema, the description covers purpose, algorithm, parameters, and expected behavior. Complete enough for a read operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, so description adds significant value: explains resume_id sources (from get_my_resumes) with example, and max_pages with range, default, and per-page count.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'get' and resource 'recommended vacancies' with qualification 'for a specific resume'. Distinguishes from siblings like search_vacancies (general) and get_vacancy_details (specific).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains that it uses hh.ru's matching algorithm and is equivalent to the 'Подходящие вакансии' page. Notes prerequisite resume_id from get_my_resumes. However, does not explicitly state when to use vs alternatives like search_vacancies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get list of user's job applications/responses on hh.ru.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description adds minimal behavioral info. Does not disclose authentication, data scope, or any side effects. Output schema exists but description doesn't elaborate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, directly to the point, no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool with no parameters and output schema present, but description is minimal. Lacks details like return type or that it returns for the authenticated user. Adequate but could be improved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters in schema (0 params), so description doesn't need to add param info. Baseline 4 for 0 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool retrieves a list of user's job applications/responses on hh.ru, using specific verb and resource. Distinct from sibling 'get_my_resumes' which deals with resumes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use versus siblings like 'apply_to_vacancy' or 'get_my_resumes'. Implied usage for viewing applications, but no explicit context or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full resume content.
Args: resume_id: Resume ID (from get_my_resumes)
| Name | Required | Description | Default |
|---|---|---|---|
| resume_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description is the sole source. It describes a read operation without side effects, which is clear. But it does not mention any access restrictions, data sensitivity, or behavior beyond retrieval. Adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no redundant words. The argument list format is concise and clear. Every sentence contributes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, read-only, output schema exists), the description covers the key aspects: what it does and parameter source. Could add more about output but output schema handles that. Nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage for resume_id. The description adds value by stating the parameter is 'Resume ID (from get_my_resumes)', linking to sibling tool for acquisition. This meaningfully extends the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Get full resume content', which clearly identifies the action (get) and resource (resume) and specifies the scope (full content). Distinguishes from sibling 'get_my_resumes' which lists resume IDs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Indicates resume_id comes from 'get_my_resumes', providing context on origin. However, it does not explicitly state when to use this tool versus alternatives, nor provide conditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full details of a specific vacancy.
Args: vacancy_id: hh.ru vacancy ID (e.g., "12345678")
| Name | Required | Description | Default |
|---|---|---|---|
| vacancy_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the operation. It does not disclose behavioral traits such as authentication requirements, rate limits, or whether it returns full details (e.g., includes description, contacts). Minimal disclosure beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no waste. The first sentence states the purpose clearly. The second provides parameter details in a structured format. Could be slightly improved with bullet points, but efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter) and has an output schema, so the description need not detail return values. However, it lacks context about prerequisites (e.g., authentication) and when to use vs. siblings. Adequate but with gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no description on the vacancy_id parameter (0% coverage). The description adds an example ('12345678') and clarifies it's an hh.ru vacancy ID, providing format and platform-specific context that aids correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Get full details of a specific vacancy,' using a specific verb and resource. This clearly distinguishes it from siblings like search_vacancies (listing) and apply_to_vacancy (action).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: when you have a vacancy ID and need full details. However, no explicit guidance on when not to use or alternatives like search_vacancies for initial discovery. No prerequisites or context are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for vacancies on hh.ru.
Args: keywords: Search keywords (e.g., "QA Automation Engineer") area: Location filter (e.g., "москва", "россия") salary_from: Minimum salary salary_to: Maximum salary experience: Experience level (no_experience, 1-3, 3-6, 6+) schedule: Work schedule (remote, office, hybrid, flexible, shift) max_pages: Maximum pages to load (1-10, default 3)
| Name | Required | Description | Default |
|---|---|---|---|
| area | No | ||
| keywords | Yes | ||
| schedule | No | ||
| max_pages | No | ||
| salary_to | No | ||
| experience | No | ||
| salary_from | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It explains the search functionality and the max_pages parameter with a default of 3, but does not disclose whether the operation is read-only, any authentication needs, rate limits, or side effects. The description is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the purpose. The parameter list is clearly formatted with each on a new line and default values. It is well-structured for an AI agent to parse, though could be slightly more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool complexity (7 parameters), absence of annotations, and presence of an output schema, the description is sufficiently complete. It covers all parameters and their valid ranges. The output schema handles return value description, so the description need not expand on that. However, it could mention that the area parameter expects location names in Russian.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description provides detailed explanations for all 7 parameters, including examples (e.g., 'QA Automation Engineer' for keywords) and valid values (e.g., 'no_experience, 1-3, 3-6, 6+' for experience). This compensates for the missing schema descriptions, though minor details like currency for salary are omitted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search for vacancies on hh.ru', specifying the verb 'search' and resource 'vacancies'. The parameter list enumerates filtering options, distinguishing it from sibling tools like get_vacancy_details (single vacancy) and apply_to_vacancy (application).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates usage for searching vacancies with filters, but lacks explicit guidance on when to use this tool versus alternatives, such as get_recommended_vacancies. No when-not or context exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0apply_to_vacancyclose_sessionget_employer_infoget_my_resumesget_recommended_vacanciesget_responsesget_resumeget_vacancy_detailssearch_vacanciesScored across 9 tools
Each tool has a clearly distinct purpose: searching vacancies, getting details, applying, managing resumes, employer info, and responses. No overlap or ambiguity.
All tool names follow a consistent verb_noun pattern using snake_case (e.g., search_vacancies, get_resume, apply_to_vacancy). No mixing of styles.
9 tools are well-scoped for a job application platform, covering all core operations without being excessive or too sparse.
The tool set covers the essential job search and application workflow. Minor gaps like resume creation/editing are absent but can be handled externally.
Analyze job listings against your resume, track applications, and generate cover letters.
Web search, page reading and structured extraction for AI agents, with strong RU coverage
Manage job applications — jobs, companies, boards, notes, and profile — from your AI client.
Stealth web automation for AI agents. Login, signup, navigate, screenshot.
