Skip to main content
Glama

Reqbeat Hiring Signals

search_jobs

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qNo
geoNo
roleNo
sortNo
limitNo
sinceNo
cursorNo
plane_api_keyNo
idempotency_keyNo

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.

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.

Resources