Skip to main content
Glama

Reqbeat Hiring Signals

by com.reqbeat
OverviewDiscussionsAdmin

Search open roles

search_jobs
Read-onlyIdempotent

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. No key yet? On the hosted HTTP endpoint the first calls are free: send no X-API-Key header and the search runs on a shared demo credential -- a smaller page, billed to nobody, and the result says so -- 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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qNo
geoNo
roleNo
sortNo
limitNo
sinceNo
cursorNo
plane_api_keyNoDeprecated: pass the key in the `X-API-Key` header, or omit the header for demo mode. Removed in 1.2.
idempotency_keyNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / plane_api_key / description
      Added value: +"Deprecated: pass the key in the `X-API-Key` header, or omit the header for demo mode. Removed in 1.2."
  2. Changed2 schema fields changed
    • addedInput schema / properties / q
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Q"
+}
    • addedInput schema / properties / sort
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Sort"
+}
  3. First observed

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already establish readOnly/openWorld/idempotent/non-destructive, so the bar is for added context, and the description clears it decisively: ATS-only plus freshness floor, rejection-vs-empty error behavior for invalid `role` values, oversized-`limit` rejection instead of truncation, and the full demo-credential/signup-link authentication behavior. None of this is inferable from the annotations, and nothing contradicts readOnlyHint.

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 long (~200 words), but the tool has 9 parameters, pagination, error modes, and an authentication fallback that all need documenting, and every sentence adds a distinct fact with no filler. It is front-loaded with purpose and sibling routing; the weakness is the single dense paragraph, which would be easier to parse with sectioning.

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?

For a complex tool with no output schema, it covers filtering, pagination, error behavior, and authentication, and even names key return elements (`company_id`, `req_key`, `relevance`, `next_cursor`). It falls just short of fully specifying the result row shape, and `idempotency_key` is left unaddressed, but neither gap prevents an agent from invoking the tool correctly.

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?

With schema coverage at only 11%, the description carries nearly the entire burden and mostly succeeds: it explains that `role` must be a function id (plain names are rejected), `geo` is a country, `q` searches titles semantically with 0-1 `relevance`, `sort` takes 'relevance' or 'recency', `cursor` comes from a prior call's `next_cursor`, and `limit` is bounded. The one real gap is `idempotency_key`, which is never explained, and `since` is named as a filter without format detail.

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 opens with a specific verb and resource: 'Flat, role-granular job search -- the individual open roles across companies.' It further specifies the filtering dimensions (`role`/`geo`/`since`) and the row granularity (one per logical req with `company_id` + `req_key`), and it distinguishes itself from a sibling by naming `who_is_hiring_for` as the company-granular reverse view.

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 explicitly routes to an alternative: 'Use `who_is_hiring_for` for the company-granular reverse view.' It also gives conditional guidance for `q` vs `role`, for `sort` (relevance is the default with `q`, recency is the alternative), and for pagination (`cursor` instead of raising `limit`), so an agent knows exactly which parameter path fits which situation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Reqbeat Hiring Signals toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources