Reqbeat Hiring Signals

com.reqbeat/hiring-signals

Find companies hiring for a role and geo, qualify them, and watch them for changes.

Yes, your AI can use this right now.Answered a live MCP handshake in 224 ms with no sign-in needed and exposes 15 tools.

Connect it

Settings → Connectors → Add custom connector
URL: https://mcp.reqbeat.com/mcp

15 tools, verified live

Pulled straight from the server with tools/list on 2026-10-17.
is_hiringread-only

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` from an earlier result, not a company name or domain. company_id=1234 -> is_hiring true, open_req_count 7, coverage_status "ats_direct_hit". company_id=5678 -> is_h

get_open_reqsread-only

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 of the req, not the employer's posting date; `source_posted_at` is the date the source itself published, null when it gave none. `function` is a fu

hiring_pulseread-only

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 per week, a flow rather than a stock. Use it to rank or score a company you already hold a `company_id` for. Freshness is controlled by `max_ag

who_is_hiring_forread-only

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, keyset-paginated via `cursor`. `q` is free text matched against the posting title, not an id; plurals and other inflections match, so "backend engineers" is the s

search_jobsread-only

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 job boards and aggregators; each row's `board` names its source) + freshness-floored. `since` filters on `first_seen`, our first observation

get_roleread-only

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`. Scoped exactly as `search_jobs` is: LinkedIn-excluded (ATS tenants plus public job boards and aggregators) and freshness-floored. The body adds `raw_t

find_qualified_reqsread-only

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 company. `criteria` takes up to three groups -- `company` (country, industry, industry_terms, headcount_band, company_kind), `req` (q, q_exclu

pre_action_briefread-only

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 migrations, pre-joined and each section capped so the payload stays compact. Use it right before writing outreach or a qualification note for a

get_changesread-only

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 nothing and one `change` unit is metered per event returned. Filter by `company_id`, or by one exact `event_type`. `limit` is bounded -- page wi

find_companyread-only

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 neither is an error naming that rule. `domain` takes a bare host or a full URL and matches exactly ({"domain": "https://www.stripe.com/jobs"} -> the

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 is safe and never leaves you with two endpoints. `secret` is optional; supply one to verify the `X-Reqbeat-Signature` on delivered payloads, om

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: `opened` (a req seen for the first time), `reobserved` (a known req seen again on a later day), `reposted` (a req that came back after it was gone),

list_watchesread-only

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": ..., "event_types": [...], "webhook_endpoint_id": ..., "status": "firing", ...}]}. Each also reports its heartbeat -- `last_fired_at`, `fires_last_7d`, `f

cancel_watchcan modify

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 one of your watches is an error, identical whether it belongs to someone else or does not exist. Frees the slot a free key's watch limit coun

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, optionally, the `req_key` of the role that prompted the outreach: {"company_id": 1234, "outcome": "meeting_booked", "observed_at": "2026-10-0

Alternatives in Maps & Travel

Compare →
Try “Notion”, “Stripe”, “create invoice”, “browser”