MCP server for Huntflow — ATS, vacancies, candidates, recruiting (Russia)
Huntflow MCP has well-structured tool definitions with consistent naming (verb_noun pattern), clear descriptions in Russian, and explicit input schemas using Zod. All 14 tools are registered with descriptions and typed parameters. However, output schemas are only partially documented (12 tools have outputSchema declarations, 2 return raw text). Parameter descriptions are present but often terse (avg ~40 chars). No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite all tools being read-only. Error handling returns basic error messages without recovery guidance. Missing: parameter constraints (enums, min/max) on several tools, and no documentation of pagination behavior or result limits.
Полная информация о кандидате.
Резюме кандидата (все прикреплённые external).
Полное тело конкретного резюме (external) кандидата.
Полная информация о вакансии.
Список доступных аккаунтов HuntFlow.
Сотрудники/рекрутеры аккаунта.
Справочник подразделений (отделов).
Three tools (get_vacancy, get_applicant, get_resume) return raw text responses without documented output schemas. LLMs cannot plan downstream operations or extract structured data.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite all 14 tools being read-only. Agents cannot distinguish safe tools from destructive ones without explicit hints.
Error handling returns raw exception messages without recovery guidance. E.g., 'Invalid account_id' does not suggest calling list_accounts() first or explain what valid IDs look like.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | 2025-06-18+ | v2 |
Справочник причин отказа.
Справочник источников кандидатов.
Этапы воронки подбора (статусы вакансий).
Справочник тегов аккаунта.
Список вакансий в HuntFlow (по умолчанию открытые).
Кандидаты, прикреплённые к конкретной вакансии.
Поиск кандидатов по имени/email/телефону и фильтрам (вакансия, этап, тег).
Pagination parameters (count, page) lack documented limits and behavior. No indication of max result size, whether page is 0-indexed or 1-indexed, or what happens when page exceeds available data.
Parameter descriptions are terse (avg ~40 chars). E.g., 'ID аккаунта' lacks context on how to obtain it or what format is expected. Descriptions should be 50-200 chars with actionable guidance.