A
licenseA
qualityA
maintenanceDetects hiring intent signals by scanning job boards for specific companies. Returns structured role data for outbound sales targeting.
1
196
1
MIT
Reqbeat Hiring Signals
by com.reqbeat
Server Details
Find companies hiring for a role and geo, qualify them, and watch them for changes.
If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Available Tools
11 toolsget_changesAInspect
The since=cursor diff feed -- ledger events with event_seq > since, plus a next_cursor. Meters one change unit per event
returned, independent of poll count. A free-tier caller is
freshness-floored, the same as every other free-tier read. limit is
bounded: an oversized page is rejected rather than truncated, so
replay with next_cursor instead of raising limit.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| since | Yes | ||
| company_id | No | ||
| event_type | No | ||
| plane_api_key | No | ||
| idempotency_key | No |
TDQS
A3.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: cursor pagination, metering, free-tier freshness floors, and that oversized limits are rejected not truncated. Since no annotations exist, this adds critical transparency beyond schema.
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?
Description is concise (4 sentences), front-loaded with core purpose, and every sentence adds value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, description lacks details on return format beyond next_cursor, and omits explanations for 4 of 6 parameters. Incomplete for a complex tool with many optional params.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only explains 'since' and 'limit' parameters. With schema description coverage at 0%, the description should cover all 6 parameters but ignores company_id, event_type, plane_api_key, and idempotency_key.
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?
Description clearly states it's a diff feed for ledger events with cursor-based pagination, using specific verb 'get changes' and resource 'ledger events'. It distinguishes from siblings like search_jobs or get_open_reqs by focusing on event changes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context on pagination and rate limits but does not explicitly state when to use this tool vs alternatives like register_webhook or search_jobs. No when-not conditions or sibling comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_open_reqsAInspect
The company's current active reqs, deduped across boards --
ATS/board-only, freshness-floored. function must be a function id
(as seen in prior results); a plain role name like 'engineering' is
rejected with an explicit error rather than an empty result. limit
is bounded: an oversized page is rejected rather than truncated.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| country | No | ||
| function | No | ||
| company_id | Yes | ||
| plane_api_key | No | ||
| idempotency_key | No |
TDQS
A3.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals key behaviors: deduplication across boards, data freshness (freshness-floored), and specific error handling for function and limit parameters. This goes beyond a basic 'get reqs' and is valuable given no annotations.
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 core purpose. The first sentence is dense but informative. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 6 parameters with 0% schema descriptions, the description covers the main behavior and two key parameters. However, it omits details on country, plane_api_key, and idempotency_key, and does not describe return format.
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 meaningful detail for two parameters (function and limit) that are not documented in the schema (0% coverage). It explains type constraints and error behavior, but covers only 2 of 6 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns 'current active reqs' for a company, which is specific and distinguishes it from siblings that likely handle changes, pulses, or job searches. However, it does not explicitly contrast with siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 vs alternatives like get_changes or search_jobs. It only describes parameter constraints, not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_roleAInspect
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:
ATS-only and freshness-floored. The body adds raw_title (the
posting's own title) and boards, the full deduped list of boards
reporting this req. A role that does not exist, is closed, or has not
reached the freshness floor is an explicit error, never an empty
success -- and it is not billed.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| req_key | Yes | ||
| company_id | Yes | ||
| plane_api_key | No | ||
| idempotency_key | No |
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses error handling ('explicit error, never an empty success'), billing implication ('not billed'), and scoping constraints. It does not explicitly state read-only nature, but the name and context imply it. Overall it goes beyond minimal requirements.
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 information-dense with no fluff. It front-loads the purpose and uses an em-dash to structure the alternative. Every sentence adds value, and it is appropriately sized for the tool's simplicity.
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 (no output schema, 4 params), the description covers purpose, scoping, error behavior, and response additions (raw_title, boards). It does not detail the full response structure or optional parameters, but for a single-role fetch, it is largely complete.
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 0%, so description must compensate. It well explains the two required parameters (company_id + req_key) as the identifier pair from search_jobs. However, the two optional parameters (plane_api_key and idempotency_key) are not mentioned at all, leaving a gap for those parameters.
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 'One open role's detail' and specifies it is addressed by company_id + req_key pair, distinguishing it from get_open_reqs which pulls the whole company. Provides specific verb (get) and resource (role) with scope limitations.
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 it is the follow-up call when you already hold identifiers from search_jobs, and explicitly contrasts with 'instead of re-pulling the whole company with get_open_reqs'. Also notes scoping exactly like search_jobs (ATS-only, freshness-floored), giving clear context for when to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hiring_pulseCInspect
A company's hiring velocity/direction/momentum in one call --
dual-metered via max_age (seconds). Cold returns {job_id, status: "crawling"} instead of a synchronous body, same as the REST route.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| max_age | No | ||
| company_id | Yes | ||
| plane_api_key | No | ||
| idempotency_key | No |
TDQS
C2.8/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions the cold behavior returning a crawling status, which provides some insight into asynchronous response handling. However, it does not disclose side effects, authentication requirements, rate limiting, or error conditions. With no annotations, more detail would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short (two sentences) but uses jargon like 'dual-metered' and 'cold' without explanation for newcomers. It could be more straightforward while remaining concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 4 parameters, the description is insufficient. It explains the cold response and max_age but omits the full response shape, error handling, and parameter details, making it incomplete for reliable tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain parameters. It only elaborates on max_age and its effect on response behavior. company_id, plane_api_key, and idempotency_key are not mentioned, leaving their semantics unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides hiring velocity/direction/momentum and mentions dual-metered behavior with max_age. However, it does not differentiate from sibling tools like is_hiring or get_open_reqs, which reduces clarity on when to use this specific tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus alternatives. The description lacks context such as prerequisites, typical use cases, or scenarios where another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
is_hiringAInspect
WHEN an agent already holds a company and needs to qualify it -- the cheap gate before spending a richer call. ATS/board-only 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_hiring false with coverage_status "no_ats_signal" -- that company has no ATS coverage yet, which is not evidence it is quiet, so do not score it as a negative. No key yet? Pass plane_api_key as an empty string and the call answers with a signup link instead of an auth error. To find companies in the first place, use who_is_hiring_for.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| company_id | Yes | ||
| plane_api_key | No | ||
| idempotency_key | No |
TDQS
A4.7/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses behavior: checks ATS/board only, freshness-floored, returns signup link without key, and explains coverage status meanings. No contradictions.
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?
Informative but slightly verbose. Front-loads purpose and each sentence adds value. Could be more succinct but still well-structured.
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 inputs, behavior, edge cases, and alternatives. Missing explicit return structure, but examples and warnings compensate well.
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?
Adds meaning beyond schema for 'company_id' (must be integer from earlier result, not name/domain) and 'plane_api_key' (empty string leads to signup link). Does not explain 'idempotency_key', but overall helpful.
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: qualifying a company as a cheap gate before a richer call, checking ATS/board and freshness. It provides examples and distinguishes it from sibling tools like 'who_is_hiring_for'.
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 agent already holds a company) and when not to (use 'who_is_hiring_for' to find companies first). Also warns about interpreting 'no_ats_signal' and explains API key handling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pre_action_briefDInspect
The motion atoms + history primitives pre-joined into one
bounded, compact call -- dual-metered via max_age. Cold returns
{job_id, status: "crawling"}, same as the REST route.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| max_age | No | ||
| company_id | Yes | ||
| plane_api_key | No | ||
| idempotency_key | No |
TDQS
D1.3/5.0
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must provide behavioral details. It only hints at a 'cold' state and dual-metering via max_age without explanation. Missing side effects, permissions, or life cycle details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but not well-structured. It uses technical jargon without definition and does not front-load a clear purpose. Every sentence is cryptic rather than informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no output schema, no annotations, and 0% param description coverage, the description fails to provide basic context. It does not explain inputs, outputs (except cold start), or behavior, making it nearly useless.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description only mentions max_age in passing without explaining its purpose or effect. The other three parameters (company_id, plane_api_key, idempotency_key) are not mentioned at all. Schema has 0% description coverage, so description adds little to no value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses unclear jargon ('motion atoms', 'history primitives') and does not explicitly state what the tool does. The verb is implied but not clear. It mentions returning a job_id and status, but the overall purpose is vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs. alternatives. The description does not mention use cases, prerequisites, or contrast with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
register_webhookAInspect
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-Plane-Signature on delivered payloads, omit it and one is
generated (it is never returned). Registration itself is free -- the
watch_company call that follows is what bills.
Plane session only: `webhook_endpoints` is plane-owned and this tool reads
no corpus table.ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| secret | No | ||
| plane_api_key | No |
TDQS
A4.3/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavioral traits: idempotency (retry safe), secret handling (optional, generated if omitted, never returned), billing (free registration), session scope (plane-owned, no corpus table read), and return value (webhook_endpoint_id). No contradictions present.
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 coherent paragraph with valuable information. Each sentence contributes to understanding, though it could be slightly more concise. It is front-loaded with the core purpose.
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?
The description covers the tool's purpose, workflow relative to siblings, idempotency, secret behavior, billing, and session scope. The only missing piece is the plane_api_key parameter. No output schema, but the returned value is mentioned.
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 coverage is 0%. The description adds meaning for url (idempotent on same url) and secret (optional, for signature verification, auto-generated if omitted, never returned). However, plane_api_key is not mentioned at all, so not all parameters are sufficiently explained.
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: registering a delivery target (webhook) for a watch and returning a webhook_endpoint_id needed by watch_company. It uses specific verbs (register) and resource (delivery target), and distinguishes from sibling tool watch_company by noting this is a prerequisite.
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?
Explicitly says 'call this first if you do not already hold one' and explains that registration is free while the subsequent watch_company call bills. This provides context for when to use it relative to siblings, though it does not mention when not to use or alternatives for other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_jobsAInspect
Flat, role-granular job search -- the individual open roles across
companies matching role (function) / geo (country) / since, one
row per logical req (each with its own company_id + req_key),
ATS-only + freshness-floored. Keyset-paginated via the opaque cursor
(a prior call's next_cursor). Use who_is_hiring_for for the
company-granular reverse view. role must be a function id (as seen
in prior results); a plain role name like 'engineering' is rejected
with an explicit error rather than an empty result -- pass plain
language as q instead, which searches the posting's own title,
expanded semantically to nearby titles, and reports each row's
relevance (0-1). q is independent of role: pass both to search
titles within one function. sort is 'relevance' (the default with a
q) or 'recency'; omit both and the page keeps its stable default
order. limit is bounded: an oversized page is rejected rather than
truncated, so page through the full set with cursor instead of
raising limit.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | ||
| geo | No | ||
| role | No | ||
| sort | No | ||
| limit | No | ||
| since | No | ||
| cursor | No | ||
| plane_api_key | No | ||
| idempotency_key | No |
TDQS
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden and does so richly. It discloses ATS-only filtering, freshness flooring, explicit rejection of invalid role values, semantic expansion of q, relevance reporting, sort defaults, bounded limit behavior, and opaque keyset pagination.
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 dense and information-rich, with no filler and the core purpose front-loaded. However, it is a single long paragraph; separating filter semantics, pagination, and sorting would improve scannability without losing 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?
For a tool with no annotations, no output schema, and nine optional parameters, the description is remarkably complete. It covers invocation semantics, pagination, filtering, sorting, error behavior, and even key output fields like company_id, req_key, and relevance, leaving little ambiguity for an agent.
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 0%, so the description must compensate. It clearly explains q, role, geo, since, sort, limit, and cursor, including error behavior and defaults. It does not explain plane_api_key or idempotency_key, though their titles give some hint; the coverage is strong but not total.
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 states a specific verb and resource: a 'job search' over 'individual open roles across companies.' It also distinguishes this tool from the sibling 'who_is_hiring_for' by explicitly calling that the 'company-granular reverse view,' so an agent can tell them apart.
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?
It gives explicit routing guidance: use who_is_hiring_for for the company-granular view, pass plain language as q rather than role, and use cursor instead of raising limit. These are concrete when-to-use and when-not-to-use instructions beyond generic context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
watch_companyAInspect
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.
A free key holds a limited number of watches at once; the one past that
is refused with the same 402 the REST route raises, and cancelling a
watch returns the slot.ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| company_id | Yes | ||
| event_types | Yes | ||
| plane_api_key | No | ||
| idempotency_key | No | ||
| webhook_endpoint_id | Yes |
TDQS
A4.4/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses metering ('Meters one watch unit'), quota limits on free keys with a specific 402 error, and that cancelling a watch returns the slot. These are useful behavioral details beyond what a schema would convey.
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 short paragraphs, front-loaded with the core purpose, followed by important constraints and consequences. Every sentence serves a purpose, with no fluff or repetition.
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?
It covers the main action, prerequisites, metering, quota behavior, and cancellation semantics, which is good for a subscription tool without an output schema. However, it doesn't describe valid event_types, the response/acknowledgement format, or the purpose of plane_api_key, leaving some gaps given the tool's complexity.
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 coverage is 0% and there are five parameters. The description adds a critical semantic for webhook_endpoint_id (ownership requirement) and mentions the idempotency implicitly via cancelling behavior, but it leaves plane_api_key and event_types unexplained beyond their names. It partially compensates for the lack of schema documentation but not fully.
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 specific action: 'Subscribe to a company's hiring events on a registered webhook', using a specific verb and resource. It distinguishes itself from siblings like register_webhook (which creates webhooks) and get_changes (which retrieves changes), so there is no ambiguity.
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?
It provides clear context for when to use the tool: you need an existing webhook endpoint and the tool subscribes a company to it. It also states a prerequisite (webhook_endpoint_id must belong to the same customer as the authenticated key). However, it doesn't explicitly mention alternatives or when not to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
who_is_hiring_forAInspect
WHEN an agent needs to FIND the companies worth working -- the sourcing step, before it knows which companies exist. Reverse who's-hiring-for {role, geo} search: companies with active reqs matching role/geo/since, deduped by company, keyset-paginated via cursor. role is free text matched against the posting title, not an id. geo is resolved to a stored country before matching; an unresolvable one is an explicit error, never a quietly partial page. limit is bounded -- page through the full set with cursor instead of raising it. Billed per company returned (~0.10 USD each) -- an empty result bills nothing. role="backend engineer", geo="USA" -> the companies with matching active reqs, each with its pulse and its matched reqs. geo="Atlantis" -> an explicit unresolvable-country error rather than an empty page. No key yet? On the hosted HTTP endpoint the first calls are free: pass plane_api_key as an empty string and the search runs on a shared demo credential -- a smaller page, billed to nobody -- until a per-IP limit is reached, after which the answer becomes a signup link whose minted key finishes this exact search. On any other transport a blank key answers with that signup link straight away. Already holding a company_id and only need a yes/no? Use is_hiring.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| geo | No | ||
| role | No | ||
| limit | No | ||
| since | No | ||
| cursor | No | ||
| plane_api_key | No | ||
| idempotency_key | No |
TDQS
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description fully discloses behavior: deduped by company, keyset-paginated, role as free text, geo resolution with explicit error for unresolvable, bounded limit, billing per company, and demo key mode. It also explicitly contrasts with is_hiring.
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 comprehensive and well-structured, but slightly verbose. Each sentence adds value, covering purpose, usage, parameters, billing, errors, and alternatives. Could be tightened slightly but still effective.
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 output schema or annotations, the description covers purpose, usage, parameters, error cases, billing, and demo mode. It lacks explicit output structure but gives an example result. Almost complete for the tool's complexity.
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?
Schema coverage is 0%, but the description fully explains all 7 parameters: role (free text), geo (resolved to country), limit (bounded), cursor (pagination), since (date-time), plane_api_key (demo usage), and idempotency_key. It adds meaning beyond the schema.
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 that the tool is for finding companies hiring for a role/geo, distinguishing it from the sibling 'is_hiring' which is for a known company. It specifies the sourcing step and uses specific verbs like 'FIND' and 'Reverse who's-hiring-for search'.
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 ('before it knows which companies exist') and when not to ('Already holding a company_id... use is_hiring'). It also clarifies billing and demo key behavior, providing full usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
write_outcomeBInspect
Write back a conversion outcome for company_id -- the
label-flywheel substrate. Appends to outcome_labels scoped to the
caller's own customer.
Plane session only: `outcome_labels` is plane-owned (Phase 1 dropped its
one foreign key into the corpus) and this tool reads no corpus table.ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| outcome | Yes | ||
| req_key | No | ||
| company_id | Yes | ||
| observed_at | Yes | ||
| plane_api_key | No |
TDQS
B3.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides good behavioral context: it appends to outcome_labels, is scoped to the caller's customer, requires a plane session, and reads no corpus table. Missing details on idempotency, errors, or side effects, but still informative.
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 short with two paragraphs, front-loading the purpose. The second paragraph adds relevant context about plane session restrictions. Somewhat cryptic references ('Phase 1 dropped its one foreign key') may distract, but overall concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, and the description does not explain return values, error conditions, or idempotency. For a tool with 5 parameters and side effects, an agent lacks critical execution context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only mentions company_id ('for company_id') without explaining outcome, observed_at, req_key, or plane_api_key. Little value added beyond the schema's structural 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 action ('Write back a conversion outcome'), the resource ('company_id'), and the effect ('Appends to outcome_labels'). It is specific and distinct from siblings, which are about hiring and changes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. The only hint is 'Plane session only', but no mention of conditions for not using it or comparison with sibling tools.
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. Dates show when Glama detected each change.
1 tool update
- Changed
search_jobs2 fields changed- added
Input schema / properties / qAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Q" +} - added
Input schema / properties / sortAdded value: +{ + "anyOf": [ + { + "type": "string" + }, + { + "type": "null" + } + ], + "default": null, + "title": "Sort" +}
1 tool update
- Added
get_role
10 tool updates
- First observed
get_changes - First observed
get_open_reqs - First observed
hiring_pulse - First observed
is_hiring - First observed
pre_action_brief - First observed
register_webhook - First observed
search_jobs - First observed
watch_company - First observed
who_is_hiring_for - First observed
write_outcome
Frequently Asked Questions
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as
io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such asio.github.acme/serveralso needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at
/.well-known/glama.jsonon the same origin as the connector, then choose Check HTTP challenge.DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Connectors
Search job postings, companies, and technology stacks across 10M+ companies.
Real-time B2B buying signals on your target accounts: funding, hiring, leadership, tech stack.
- KaironOAuthcom.heykairon
Build prospecting lists from buying signals, enrich them, and run LinkedIn outreach.
Job platform for AI agents. Track tech jobs from companies that match your stack.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceTransforms job postings into qualified sales leads by searching for active jobs, enriching company data, and identifying decision-maker contact information.-
- AlicenseAqualityAmaintenanceEnables monitoring of job postings by keyword, returning companies currently advertising those roles enriched with firmographics and LinkedIn URLs via Apify.1158MIT
- AlicenseAqualityCmaintenanceScans job boards for keyword patterns that indicate buying intent, technology adoption, or team expansion. Returns structured signal data for outbound targeting.11862MIT
Try in Browser
Glama MCP Gateway
Add one secure layer between your agents and this server.
TDQS
C2.6/5.0
Disambiguation2/5
Multiple tools have overlapping purposes (e.g., get_changes/get_open_reqs/get_role all retrieve job-related data with pagination; hiring_pulse and pre_action_brief share nearly identical descriptions; is_hiring and hiring_pulse both assess company hiring status). The long, verbose descriptions provide some subtle differentiators but the functional boundaries are unclear.
Naming Consistency1/5
Naming patterns are highly inconsistent: some tools use 'get_' prefixes (get_changes, get_open_reqs, get_role), others are noun phrases (hiring_pulse, is_hiring, pre_action_brief) or verb phrases (register_webhook, watch_company, write_outcome). There is no uniform verb-object or resource-based convention, making it hard to predict functionality from names.
Tool Count3/5
The server has 11 tools, which falls within the typical 3-15 range for a domain-specific API. However, several tools appear to serve redundant or narrowly-overlapping purposes (e.g., at least five tools deal with fetching job/company data), suggesting the count could be pruned without losing core functionality.
Completeness3/5
The tool set covers core operations like searching jobs, retrieving role details, checking hiring status, registering webhooks, and writing outcomes. However, there are notable gaps: no webhook management (e.g., list/unregister), no explicit company profile retrieval, and no update/delete operations. This makes the surface feel incomplete for a comprehensive hiring-signals API.