MCP-сервер Reqbeat

• Имя в реестреcom.reqbeat/hiring-signalsподтверждён в реестре MCP

Имя в реестре лежит в пространстве reqbeat.com. Реестр пускает в такое пространство только того, кто доказал владение доменом через DNS или HTTP.

• Состояниеотвечаетпроверено 2026-10-25
• Инструменты15
• Сервер называет себяhiring-signals
• Версия сервера1.1.4
• Версия протокола2025-06-18

2026-10-25 сервер ответил на initialize и tools/list без входа. Первый ответ за 158 мс.

• Инструменты делают все проверенные сценарии: Get webhook alerts when watched companies post new job requisitions; Give AI agents a live list of who is hiring.
• Проверок пока 3 из 7, нужных, чтобы судить о надёжности.

Вывод сделан правилами по замерам выше. Вероятный первый вызов выбрала модель по списку инструментов: прочитайте описание, прежде чем на него полагаться.

• Оценка INITE MCPчерез неделюдля оценки нужно 7 ежедневных проверок, пока 3
• Что агент может с ним сделать2 из 2 сценариев
• Отвечалидёт замерпроверок пока 3, долю покажем после 7
• Медиана первого ответа168 мс
• Место в контексте агента≈ 5 775 токеновописания всех инструментов (15), они занимают контекст агента на каждом ходу
• Описания инструментовB · 84 из 100
• Типизированные ответы0 из 15 инструментовобъявлен outputSchema: ответ приходит с типами и читается сразу

• Параметры без описания: в 14 из 15

Программа проверяет сервер раз в день: initialize и tools/list, без модели. Токены - это длина описаний из расчёта примерно четыре символа на токен. Оценка - среднее шести проверок имени, описания, схемы и аннотаций каждого инструмента. Она говорит, насколько понятно описаны инструменты, а не о том, работают ли они. Оценка складывается только из замеренного: отвечает ли сервер (25%), делает ли работу продукта (25%), описания (20%), контекст (10%), использование (10%) и насколько просто подключиться (10%). Незамеренная часть не учитывается, а скрытая инструкция ограничивает оценку 40 баллами. Состояние MCP-серверов вендоров: методика и цифры →

• is_hiring

  WHEN an agent already holds a company and needs to qualify it -- the cheap gate before spending a richer call. LinkedIn-excluded (ATS tenants plus public job boards and aggregators) and freshness-floored. Takes the integer `company_id`…

• get_open_reqs

  The company's current active reqs, deduped across boards -- LinkedIn-excluded: ATS tenants plus public job boards and aggregators; each row's `boards` names its source. Freshness-floored. Each row's `first_seen` is our first observation…

• hiring_pulse

  One number set for one company: how many reqs it opened in the last 30 days, a `velocity` ratio of that against the 30 days before it, a `direction` of up / flat / down between the two, a surge flag, and `momentum` -- postings published…

• who_is_hiring_for

  WHEN an agent needs to FIND the companies worth working -- the sourcing step, before it knows which companies exist. Reverse who's-hiring-for {title, geo} search: companies with active reqs matching `q`/`geo`/`since`, deduped by company…

• search_jobs

  Flat, role-granular job search -- the individual open roles across companies matching `function` / `geo` (country) / `since`, one row per logical req (each with its own `company_id` + `req_key`), LinkedIn-excluded (ATS tenants plus public…

• get_role

  One open role's detail, addressed by the `company_id` + `req_key` pair every `search_jobs` row already carries -- the follow-up call for a role you hold an identifier for, instead of re-pulling the whole company with `get_open_reqs`…

• find_qualified_reqs

  WHEN an agent already knows its ideal customer profile and wants the matching open roles as rows it can act on: several countries, an industry, a headcount band and title keywords in ONE call, instead of a search followed by a lookup per…

• pre_action_brief

  Everything an agent needs before acting on one company, in one bounded round-trip instead of five: the hiring pulse, its top open reqs deduped across boards, first-hire-by-function events, hardest-to-fill (reposted) reqs and ATS-vendor…

• get_changes

  The change feed, not a search: ledger events -- a req opened, re-observed, reposted or closed -- with `event_seq > since`, ascending, plus `next_cursor`. Replay with `next_cursor` instead of polling or re-searching; an empty page bills…

• find_company

  WHEN you hold a company's website or name but not the `company_id` every company-scoped tool takes (`is_hiring`, `get_open_reqs`, `hiring_pulse`, `pre_action_brief`, `watch_company`). Pass exactly one of `domain` or `name`; both or…

• register_webhook

  Register the delivery target a watch fires to, and get back the `webhook_endpoint_id` `watch_company` needs -- call this first if you do not already hold one. Idempotent: registering the same `url` twice returns the same id, so retrying…

• watch_company

  Subscribe to a company's hiring events on a registered webhook -- `webhook_endpoint_id` must belong to the same customer as the authenticated key. Meters one `watch` unit. `event_types` names which events fire it, at least one of…

• list_watches

  WHEN you need to see what you are subscribed to -- before adding a watch, or to find the `id` `cancel_watch` takes. Returns your live watches newest first, cancelled ones excluded: {} -> {"watches": [{"id": ..., "company_id"…

• cancel_watch

  WHEN a watch should stop firing. Takes the `id` `watch_company` returned (or `list_watches` lists): {"watch_id": 42} -> {"id": 42, "canceled": true}. Idempotent -- cancelling a watch you already cancelled succeeds again. An id that is not…

• write_outcome

  WHEN a company you reached through a signal converts -- a reply, a meeting, a closed deal -- report it back. Takes the `company_id`, a short `outcome` label of your choosing (e.g. "meeting_booked"), the `observed_at` time it happened and…