Job search over employers' own hiring systems. Search with no key; a free key opens every read tool.
Scored across 15 tools
Most tools target a distinct action (search, get detail, apply, status, analytics), and the descriptions explicitly disambiguate the tricky pairs. The only real overlap is the intentional aliases (fetch≈get_job, search≈search_jobs) and the single-vs-batch pair (get_job vs get_jobs), which the descriptions clarify well enough to avoid misselection.
Names are uniformly snake_case and mostly verb_noun (get_job, check_jobs_open, request_application, fit_resume), which is predictable. A few are noun_phrases (application_status, board_stats, employer_growth) but they stay readable and in the same style.
15 tools is reasonable for a job board plus an agentic apply flow spanning search, retrieval, key/auth, application lifecycle, and employer analytics. The count is slightly padded by two client-specific aliases (fetch, search), but each still serves a real integration need.
The surface covers search, detail (single and batch), board stats, key/tier status, apply-support checks, application submission and status, resume fitting, and employer analytics — a broad lifecycle. The main gap is no explicit cancel/withdraw-application operation, which an agent managing submissions would plausibly want.
Status of applications the key owner's agent has requested — queued, submitted, refused (with the refusing gate named), or failed. Needs a key or a sign-in.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Most recent N, default 20, max 50. |
| Name | Required | Description |
|---|---|---|
| fix | No | |
| error | No | Only when this key is not linked to an account. |
| queued | No | Requests waiting for the hourly preparer, newest first. |
| statusKey | No | What each status word means. |
| applications | No | Prepared packets and their outcome, newest first. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly, idempotent, openWorld, and non-destructive behavior. The description adds useful context beyond annotations by enumerating the statuses returned and disclosing the auth requirement ('Needs a key or a sign-in'), which is material for invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. The core meaning—what statuses are included—is front-loaded, and the auth note is an essential second sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low parameter count, rich annotations, and existing output schema, the description provides the key information an agent needs: what data is shown and that authentication is required. It stops short of explicitly steering the agent away from sibling tools, but the scope is clear enough for most cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is only one optional parameter, limit, and schema description coverage is 100%, so the schema fully documents it. The description adds no additional meaning about parameter syntax, defaults, or constraints beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as the status of applications requested by the key owner's agent, and lists the possible statuses. It is distinguishable from sibling tools like request_application and key_status, though it lacks an explicit verb such as 'retrieves' or 'returns'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool—when checking the status of requested applications—and notes the auth prerequisite. However, it does not explicitly contrast it with alternatives like key_status or request_application, so an agent must infer the right context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Live board statistics from cache (cheap to call): servable and tracked posting totals, the count of company job boards with open roles (boards, not employers — one employer can run several), the category set, freshness stamp. Answers with no key too, with a withKey block saying what a free key adds.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| note | No | |
| withKey | No | Present on an unkeyed call: where a free key comes from and what it adds. |
| categories | Yes | The category slugs search_jobs accepts. |
| refreshedAt | No | When the cache these figures come from was last written. |
| trackedPostings | No | Every posting the board holds, including ones outside the serving rules. |
| servablePostings | Yes | Postings the board serves right now: not withdrawn, dated within the freshness window. Null when the pass did not compute it. |
| openCompanyBoards | Yes | Company job boards with at least one servable posting. BOARDS, not employers — read openCompanyBoardsBasis. |
| freshnessWindowDays | Yes | |
| openCompanyBoardsBasis | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, and the description adds valuable behavior beyond these: it is served from cache, cheap to call, includes a freshness stamp, and behaves differently without a key by returning a withKey block. This gives an agent a realistic expectation of cost, freshness, and auth-dependent output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense, information-rich sentence with no filler. Every clause adds meaningful guidance: cache-backed, cheap, specific metrics, board-vs-employer disambiguation, freshness stamp, and keyless behavior. The key facts are front-loaded and the length is appropriate for the content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema available, the description is complete. It covers the data scope, the source and cost profile, the keyless mode, and the presence of a freshness stamp. There are no missing prerequisites, inputs, or behavioral caveats that an agent would need to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema confirms this, so parameter semantics are trivially complete. The description does not need to explain any parameter meaning and does not attempt to. A baseline of 4 is appropriate for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb with a clear resource: 'Live board statistics from cache' and enumerates exactly what is included (posting totals, board counts, category set, freshness stamp). It also disambiguates 'boards, not employers' to prevent a common misinterpretation. This clearly distinguishes board_stats from the sibling employer-oriented stats tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives practical usage context: it is 'cheap to call' and serves data from cache, implying it is appropriate for quick or repeated statistics lookups. It also clarifies that it 'answers with no key too,' which helps an agent know it works without authentication. It does not explicitly name alternative tools or exclusion conditions, but for a zero-parameter read-only stats tool this is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Whether the apply agent can submit an application for this job on the user's behalf, and what that requires. Jobs on non-supported systems still return their direct applyUrl for the human to use. For whether THIS KEY may apply at all, call key_status — this tool answers about the job, not the key. Needs a key or a sign-in.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
| Name | Required | Description |
|---|---|---|
| jobId | Yes | |
| vendor | Yes | The hiring-system prefix of the id, e.g. 'greenhouse'. Null when the id carries none. |
| applyUrl | No | The employer's own apply page. ABSENT when the board could not read the posting. |
| agentReady | Yes | True when the posting's hiring system is one the apply agent can submit to. |
| requirements | Yes | What applying through the agent needs — or, on a non-supported system, the one line saying the human applies at applyUrl. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description adds useful behavioral context: non-supported systems still return the direct applyUrl for human use, the tool answers about the job rather than the key, and authentication is required. These details are not redundant with the readOnlyHint/idempotentHint/destructiveHint annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: main purpose, fallback behavior, and alternative-tool routing plus prerequisite. The key scope differentiation is front-loaded and the entire description is free of filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a rich annotation set and an output schema present, the description covers what is needed to invoke the tool correctly: purpose, scope, job-vs-key distinction, fallback behavior, and authentication requirement. Nothing essential is missing for this level of complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no description for the single 'id' parameter, so the description must compensate. The text makes clear that the id refers to the job being checked ('this job'), especially by contrasting with key_status. It does not explicitly state the id's source or format, but for a single-parameter check tool, this is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool determines whether the apply agent can submit an application for a specific job on the user's behalf, and explicitly distinguishes it from key_status by noting this tool answers about the job, not the key. This gives a specific verb, resource, and scope that separates it from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when to use key_status instead: 'For whether THIS KEY may apply at all, call key_status.' It also clarifies the tool's scope and prerequisite ('Needs a key or a sign-in'), making the usage context unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Are these postings still on the board? Answers up to 200 ids in one call — the tool for re-verifying a saved shortlist before acting on it, instead of spending a metered get_job per posting. Returns open:{id:boolean} plus the closed ids, and names the basis of the answer: it reads the board's index (a closed posting is one the employer's feed stopped listing), not the employer's site at this instant, and it is a weaker test than get_job's — read basis before reporting a posting as live to a person. Needs a key or a sign-in.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | Job ids from search_jobs. Up to 200 per call; anything past that is named in notChecked rather than silently dropped. |
| Name | Required | Description |
|---|---|---|
| open | Yes | One entry per id checked. |
| basis | Yes | What 'open' means in this answer. |
| closed | No | The ids that are no longer on the board. |
| checked | No | |
| openCount | No | |
| notChecked | No | |
| closedCount | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds crucial behavioral context beyond these: it reads the board's index rather than the employer's live site, and it is explicitly a weaker test than get_job. This informs the agent of the tool's limitations and the need to check the `basis` field, which annotations alone cannot convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose, but it is slightly verbose. The phrase 'instead of spending a metered get_job per posting' is valuable guidance but could be integrated more compactly. Overall, it earns its place with no fluff, but a tighter phrasing would push it to 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the return format (open:{id:boolean} plus closed ids and basis), the caveat about basis, the prerequisite key/sign-in, and the tool's relationship to get_job. With an output schema present, it still provides essential behavioral context. Nothing an agent needs to decide when and how to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a description for the `ids` parameter (from search_jobs, max 200, notChecked behavior) and has 100% schema description coverage. The description restates the 200-id limit but adds no new semantic detail beyond what the schema specifies. Per the rubric, with high schema coverage, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a direct question and a clear statement of what the tool does: 'Are these postings still on the board? Answers up to 200 ids in one call'. It identifies the resource (job postings) and the action (checking open status), and explicitly contrasts with the sibling get_job, making differentiation unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'the tool for re-verifying a saved shortlist before acting on it, instead of spending a metered get_job per posting.' It also flags a key caution: 'it is a weaker test than get_job's — read `basis` before reporting a posting as live to a person,' and states the prerequisite 'Needs a key or a sign-in.' This is thorough and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain WHY a search returns what it does — the board's own decision trace merged with the run's outcome. Shows the parsed query (terms, exclusions, intent-lifts, alias expansions), which filters were applied vs IGNORED and why, the route and retriever chosen, the ranking regime (ranked/ring-merged/deep-page and the seam), plus the real run's route, timings, count basis and any fallback. Use this when a search returns surprising, empty, or mis-ranked results — it turns 'why?' into one call. Takes the SAME arguments as search_jobs. Needs a key or a sign-in.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Default relevance. | |
| limit | No | Rows per page, 1-60. Default 20. | |
| query | No | Search terms. Supports exclusions: 'engineer -senior'. | |
| offset | No | Paging offset — pass back the previous response's nextOffset. | |
| remote | No | Only remote-friendly roles. | |
| vendor | No | Comma list of hiring-system vendors (greenhouse, lever, ashby, …), max 8. Not available here: usajobs, smartrecruiters — Two hiring systems are shown on resumebooster.work but not handed on by this connector: the U.S. federal job feed, whose terms of use forbid redistributing it as a data feed, and SmartRecruiters, withheld until SmartRecruiters (SAP) permits it. No tool here returns their rows; open the posting on the site instead. Naming one is refused rather than answered with an empty page. | |
| country | No | ISO-2 codes, comma-separated, max 5. E.g. 'US,GB'. | |
| category | No | Comma list of category slugs (see board_stats for the live set), max 3. | |
| location | No | City/state/metro, e.g. 'texas', 'NYC', 'berlin'. | |
| maxYears | No | Only roles asking for at most N years of experience. | |
| payBasis | No | Restrict to hourly or salaried pay. | |
| workMode | No | Comma list of: remote, hybrid, onsite. | |
| companies | No | Scope to specific employers: a comma list of companyToken values from job cards (or from the site's employer pages). An employer the board does not carry simply matches nothing; tokens the board drops are named in ignoredFilters. | |
| salaryMax | No | Annual USD-equivalent salary ceiling. | |
| salaryMin | No | Annual USD-equivalent salary floor. Many postings state no comparable pay; the response's filterCoverage gives the live share this floor can see, dated by filterCoverageAt. | |
| department | No | Substring match on the employer's own department/team text. | |
| experience | No | Comma list of seniority bands the POSTING asks for: entry, mid, senior, expert. Rows whose band could not be read are excluded — use maxYears for the candidate's own side of the question. | |
| maxAgeDays | No | Only postings from the last N days (1-30). | |
| postedAfter | No | ISO-8601 instant; only postings the EMPLOYER dated after it. Undated rows fall out of this window (unlike maxAgeDays, which falls back to when the board first saw a posting), so this is the strict form of 'new'. | |
| hasStatedPay | No | Only postings whose pay field carries a figure the employer published — hourly and per-shift rates included, read from the `salary` field. The response's filterCoverage gives the live share. Narrower than it sounds only for RANKING: salaryFloor compares an annualised figure in approximate US dollars, which fewer postings carry, so some rows this returns cannot be filtered by pay amount. | |
| agentReadyOnly | No | Only jobs the apply agent can submit to on the user's behalf. | |
| employmentType | No | Comma list of: full_time, part_time, contract, temporary, internship. | |
| excludeAgencies | No | Hide postings from staffing/recruiting agencies (their job cards carry agency:true). Agencies are served by default; this is an opt-in narrowing. | |
| includeUnstatedPay | No | WIDENS an active salaryMin/salaryMax band to also admit postings that state no pay at all. Inert with no band set (unpriced rows are already included). The response says salaryStatedOnly when a band is narrowing without it. |
| Name | Required | Description |
|---|---|---|
| outcome | Yes | |
| decision | Yes | The board's own explain trace for this query: parsed terms, filters applied or ignored and why, route, retriever and ranking regime. Its keys are the board's and change as the board's decisions do. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld). The description adds real behavior beyond that: it is read-only introspection and it 'Needs a key or a sign-in', an auth prerequisite not in the annotations. It also details the returned diagnostic content (fallback presence, count basis, seam). Lacks rate-limit or cost notes, but that is minor.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the purpose, then the payload contents, then the trigger condition, then the argument/auth note — a logical order with no filler. It is dense and longer than average, but each clause (ignored filters, ranking regime, fallback) carries distinct diagnostic meaning rather than padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 24-parameter read-only diagnostic tool with a full output schema and complete annotation coverage, the description is nearly complete: it explains the diagnostic scope, the auth requirement, and the argument contract. Since an output schema exists it need not enumerate return values, so nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 24 parameters at 100% description coverage, so the schema already carries the per-parameter meaning and baseline is 3. The description only adds a cross-reference ('takes the SAME arguments as search_jobs'), which is useful routing but adds no new semantics for any individual parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (explain) and resource (a search), and enumerates exactly what the explanation contains: parsed query, applied vs IGNORED filters, route/retriever, ranking regime, timings, fallback. It also distinguishes itself from the sibling search_jobs by noting it takes the same arguments, so an agent can tell it is the diagnostic twin rather than another search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear trigger — 'when a search returns surprising, empty, or mis-ranked results — it turns why? into one call' — and points to search_jobs for the argument set. It stops short of explicitly naming when NOT to use it (e.g. routine searching), so it is strong but not fully explicit about exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Did this employer's board serve more roles than it did 7 days earlier? One row per companyToken (up to 20 per call), judged by the board itself from our own daily observation and passed through untouched: grew, no-growth, or unknown — and unknown ALWAYS carries unknown_reason (a feed bigger than one visit can read, a board too new or too small for a rate, a gap in our own series, a pool that was replaced rather than grown…): an unknown is a reading we could not take, never a no. The bars the verdict uses: at least 10 roles served at the window's start; then BOTH at least 4 more roles AND at least 25% more, on a board tracked for at least 21 days, with every read in the window whole. Per BOARD (a vendor tenant), never summed across an employer's boards; more roles served is roles opened net of roles that came down — not a headcount and not a hire. This tool never ranks employers, and no list of growing employers exists here or anywhere on the board. Needs a key or a sign-in.
| Name | Required | Description | Default |
|---|---|---|---|
| companyTokens | Yes | companyToken values from job cards or search_jobs. Up to 20; more is refused with the count named. |
| Name | Required | Description |
|---|---|---|
| bars | Yes | What the verdict measured against — for reading a row, never for re-judging one. |
| asked | No | |
| basis | Yes | |
| employers | Yes | One row per token asked, in the order asked. A token with no daily series answers unknown with its reason. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond annotations. It explains that 'unknown' is a result when a reading couldn't be taken, and it details the exact business logic (thresholds, per-board scope, net roles served). This transparency helps the agent understand edge cases and the meaning of outputs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense with useful details but is somewhat long. It front-loads the main question and then provides necessary nuances. While every sentence adds value, the structure could be more scannable, e.g., with bullet-point style, but the prose is efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex with multiple conditions and edge cases (e.g., unknown_reason), and the description covers all critical aspects: thresholds, board vs. employer, net roles, and the meaning of unknown. The output schema likely details the return format, so return values need no explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides a complete description for companyTokens (from job cards or search_jobs, up to 20). The description adds no additional parameter-specific insight beyond what the schema states, but since schema coverage is 100%, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description answers the exact question 'Did this employer's board grow?' by defining the judgment criteria (more roles served, thresholds of 10, 4, and 25%, 21-day tracking). It clearly distinguishes itself from sibling tools like board_stats or employer_hiring_record by focusing on board growth versus other statistics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It says this tool 'never ranks employers' and that no list of growing employers exists, which clarifies when not to use it. It does not explicitly name alternative tools for ranking or listing, but the context about scope (per board, not summed) provides clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
For each employer handle (companyToken, up to 20 per call), that employer's own record on this board: open_roles now, closed_90d (takedown events we watched on this board in the last 90 days, re-lists excluded — one posting that came back and came down again counts each time), superseded_90d (the re-lists, a floor), the two medians from the employer's own stated dates (lower bounds), tracking_days (how long we have watched THIS board, capped at 90) and feed_total (what its feed advertised at the last check). A takedown is not a hire — a filled role, a cancelled one and a withdrawn one look identical from here — and it is a record of one BOARD, never summed across an employer's boards, never a headcount. A board with no closure observed answers record:'unknown' with the reason, never a verdict about the employer: on a board bigger than one visit can read, no closure is observable to us until we complete a provable full pass and then watch a role go after it, so silence there is about our instrument. Every row carries its basis. Every row also carries layoff_filing — the newest layoff filing joined to that employer by a hand-curated alias or an exact multi-token name match, a US state WARN notice or an SEC 8-K Item 2.05 disclosure, printed as a filing (filer verbatim, its dates with their bases, count, state or form, link), read hourly from SEC EDGAR and nightly from state notices, null when none qualifies within 90 days, and no part of record or any verdict; layoff_basis on the response says what it is and is not. Pair with employer_growth for the other half of what the site calls "Actively hiring". Needs a key or a sign-in.
| Name | Required | Description | Default |
|---|---|---|---|
| companyTokens | Yes | companyToken values from job cards or search_jobs (a vendor tenant, e.g. 'acme' or 'gici~wd5~Careers'). Up to 20; more is refused with the count named. |
| Name | Required | Description |
|---|---|---|
| asked | No | |
| basis | Yes | |
| employers | Yes | One row per token asked, in the order asked. A token the board does not carry still answers, as unknown. |
| layoff_read | Yes | "ok" when the filing reader answered for every employer; otherwise "unread: <fault>" and every layoff_filing on this response is null for that reason, never because nothing qualified. The record is unaffected either way. |
| window_days | No | |
| layoff_basis | Yes | What layoff_filing is and is not, beside every row's record. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/openWorld, so the bar is lower. The description adds real interpretive behavior: 'A takedown is not a hire', that silence yields record:'unknown' and is about the instrument rather than the employer, that values are board-scoped lower bounds/never headcount, that layoff_filing is 'no part of record or any verdict', and refreshes ('read hourly from SEC EDGAR and nightly'). Much of the remaining text explains output fields the output schema already covers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core purpose is front-loaded, but the body is a dense wall of nested parentheticals and em-dash clauses covering field semantics, caveats and filing provenance. For a complex tool the length is partly justified, yet the readability cost is high and several clauses border on restating the output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value enumeration is not strictly required, and annotations cover the safety profile. The description still supplies the auth requirement, the board-scoping caveat, the 'unknown' semantics and the takedown-is-not-a-hire warning, making it complete enough to call correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter, and schema description coverage is 100%, so the schema already documents companyToken format, the 20-item cap and the refusal behavior. The description restates the handle concept and 'up to 20 per call' but adds no syntax or meaning beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('that employer's own record on this board') and enumerates the concrete outputs (open_roles, closed_90d, superseded_90d, medians, tracking_days, feed_total, layoff_filing). It also names a sibling ('Pair with employer_growth for the other half'), so an agent can distinguish it from the other employer/board tools without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies the context ('Pair with employer_growth for the other half of what the site calls "Actively hiring"') and notes it 'Needs a key or a sign-in', which is useful routing. But it never states an explicit when-to-use / when-not rule or which sibling to prefer over employer_growth, board_stats or check_jobs_open, leaving selection to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
An ALIAS of get_job in the fixed shape ChatGPT's deep-research and company-knowledge connectors call: one id in (from search), {id,title,text,url,metadata} out. text is the posting's full description; metadata carries the job card's structured fields (pay, experience, location, workMode, postedAt, companyToken, agentReady). A dead id answers with what the board knows — a watched closure, an aged-out stub, or not found — in text and metadata, never a stale card. Any other client should call get_job.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | A job id from search. |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| url | Yes | |
| note | No | |
| text | Yes | The description, or the board's one-line reason when there is none. |
| title | Yes | Null when there is no posting to return; read metadata.closed / agedOut / notFound. |
| metadata | Yes | The compact job card without the description; on a dead id, the board's closed/agedOut/notFound record. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, openWorld, idempotent), the description discloses important behavior for dead ids: it returns what the board knows (watched closure, aged-out stub, or not found) in text and metadata, never a stale card. This adds meaningful behavioral context not present in the annotations or schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-structured: it leads with the alias relationship, specifies the exact I/O shape, explains dead-id behavior, and closes with routing guidance. Every sentence adds distinct value, though the density makes it slightly less scannable than a minimal two-sentence description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter alias tool, the description covers all necessary runtime knowledge: where the id comes from, the exact output structure and fields, behavior for dead ids, and when to use the alternative get_job. With annotations covering safety and an output schema present, nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single 'id' parameter, so the baseline is 3. The description merely repeats 'from search' without adding format constraints or additional semantics, though it does reinforce the required input source.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states this is an alias of get_job with a fixed input/output shape (one id in, {id,title,text,url,metadata} out), and distinguishes it from the sibling get_job by naming the specific client context (ChatGPT deep-research and company-knowledge connectors) and directing other clients to call get_job. An agent can immediately tell what this tool does and how it differs from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says when to use this alias (when you are one of the ChatGPT connector shapes), the input source (id from search), and when not to use it ('Any other client should call get_job'). This is clear routing guidance with a named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Score a résumé against open jobs, for an agent holding a CV: reads the occupation out of resumeText (or uses query if given), searches the board for it, and scores up to 20 results 0-100 with the matched and missing terms per job. PAID — needs a paid API key, exactly like POST /v1/fit on the data API, or a live Agent Pass or the Agent plan on the key's account; a free key gets an in-band refusal saying what opens it. A null fit means the posting has no stored description to score. Returns the terms it read from the CV so the agent can pick a different one and call again with query. Needs a key or a sign-in.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Jobs to score, 1-20 (default 20). | |
| query | No | Optional job title to search instead of the one read from the résumé. | |
| remote | No | ||
| country | No | ||
| location | No | ||
| resumeText | Yes | The candidate's résumé as plain text (100+ characters). |
| Name | Required | Description |
|---|---|---|
| jobs | Yes | |
| note | No | |
| query | No | What was actually searched. Null when no occupation was recognised. |
| terms | Yes | The occupations read out of the résumé, best first. |
| total | No | Exact match count. ABSENT with countUnavailable:true when the board refuses to guess. |
| hasMore | No | |
| didYouMean | No | |
| nextOffset | No | Pass back as `offset` for the next page. |
| relatedTotal | No | Further postings matched in the description only, beyond `total` (which counts title matches). Each card says which in matchScope. |
| excludedTerms | No | |
| intentFilters | No | Words read out of the query as filters. |
| relatedCapped | No | relatedTotal stopped counting at the board's cap; the true figure is higher. |
| filterCoverage | No | For each filter applied, the live share (0-1) of the board that states the field it filters on; rows that state nothing are excluded. |
| ignoredFilters | No | Filters the board could NOT apply. Results answer a wider question than was asked. |
| agenciesExcluded | No | Row-selecting: disclosed agency inventory is hidden from this page. |
| countUnavailable | No | The board could not count this query exactly — do not report a total. |
| filterCoverageAt | No | When filterCoverage was measured. ABSENT when a figure is a pinned fallback rather than a live reading. |
| salaryStatedOnly | No | Row-selecting: this page excludes the postings with no annualised figure in approximate US dollars, including postings that publish an hourly rate (filterCoverage, when present, gives the live share). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/openWorld/non-destructive, yet the description adds substantial non-structured context: the operation is PAID and requires a paid API key, Agent Pass, or Agent plan; a free key yields an in-band refusal; and a null fit means the posting has no stored description. These are exactly the behavioral traits an agent cannot infer from the hint fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The single dense paragraph is front-loaded with the core action and cost constraint, and every clause carries information. It is slightly run-on with heavy parentheticals, which costs it the top mark.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a paid, key-gated scoring tool the description covers auth failure, the null-fit edge case, and the retry flow, and an output schema exists so return shape need not be restated. The geo/location filter parameters remain unexplained, which is the one real omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%, so the description must compensate, and it does for the important pair: it explains that the occupation is read out of resumeText and that `query` overrides it while also implying the retry loop. It adds nothing about remote, country, or location, however, leaving those filters undocumented in both places.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb+resource (score a résumé against open jobs) and quantifies the scope (up to 20 results, 0-100 with matched/missing terms). It is clearly the only scoring tool among search/get siblings, though it never names an alternative explicitly, which keeps it just short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the intended caller ('for an agent holding a CV') and the key branching condition: use `query` instead of the title read from the résumé, then re-call with a different term based on the returned terms. It gives no explicit when-not or sibling routing (e.g., versus search_jobs), so it lands at 4 rather than 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full detail for one job id (from search_jobs), including the complete description text and when the employer's feed last confirmed it open. A resumebooster.work/jobs?job= link's id is this argument (and fetch's, check_apply_support's and request_application's). For several ids at once, use get_jobs — it costs ONE call against the daily quota instead of one per posting. Needs a key or a sign-in. With neither, call fetch with the same id.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The job id, e.g. 'greenhouse:acme:12345'. |
| Name | Required | Description |
|---|---|---|
| id | No | vendor:employer:externalId — the id every other tool takes. |
| job | No | Present and null when there is no posting to return; read `closed` / `agedOut` / `notFound` beside it. |
| note | No | |
| title | No | |
| agency | No | Present and true when the posting comes from a staffing/recruiting agency. |
| closed | No | The board watched this posting come down: title, company, closedAt. |
| salary | No | The employer's own pay text, verbatim and unparsed. |
| agedOut | No | Past the 30-day freshness cap. |
| company | No | |
| country | No | ISO-2. |
| siteUrl | No | The posting's page on resumebooster.work. |
| applyUrl | No | |
| category | No | |
| location | No | |
| minYears | No | Years of experience the posting asks for. ABSENT when it names none (most postings). |
| notFound | No | No posting with this id — never on this board, or gone long enough that nothing is remembered. |
| postedAt | No | The employer's own date, ISO-8601. Null when the feed carries none — never the date we first saw it. |
| workMode | No | The employer's own statement: the option they chose in their ATS, or their own words on the posting (title, location, department). null has THREE meanings: neither source says anything, the two disagree and the board refuses to choose, or the posting is older than the vendor field this board now reads. Never inferred from the description, and silence is never read as onsite. |
| agentReady | No | True when request_application can submit to this hiring system. |
| department | No | The employer's own team name. ABSENT when the posting carries none. |
| matchScope | No | Which part of the posting matched the query. ABSENT when the board's path did not say. |
| description | No | The posting's full text, truncated at 24,000 characters with a [truncated] marker. |
| recheckedAt | No | When the employer's feed was last fetched and still carried this employer's board. |
| companyToken | No | The employer handle; pass it back in search_jobs `companies`. |
| salaryPeriod | No | The period the employer stated: hour, month, year. ABSENT when unstated (most postings). |
| employmentType | No | |
| experienceBand | No | ABSENT when the posting's seniority could not be read. |
| salaryCurrency | No | ISO-4217, as stated. ABSENT when unstated. |
| salaryMaxAnnual | No | Annual USD-equivalent ceiling. ABSENT when unstated. |
| salaryMinAnnual | No | Annual USD-equivalent floor, parsed by the board. ABSENT when the posting states no pay — absence is not zero. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the read-only, idempotent, open-world safety profile, so the bar is lower; the description adds real behavioral context beyond them — credential/sign-in requirement and the quota cost differential vs get_jobs. It stops short of describing error or rate-limit behavior, so it is not a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the core purpose, then layers routing and auth guidance in tight, self-contained sentences. It is information-dense rather than wasteful, though the parenthetical links in the final sentences make it slightly harder to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values need no explanation. With purpose, routing alternatives, credential requirements, the quota trade-off, and a fallback path all covered, an agent has everything needed to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3, but the description adds genuine meaning: the id is the same value found in a resumebooster.work/jobs?job=<id> link and is shared with fetch, check_apply_support, and request_application. That mapping is not in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('full detail for one job id') and immediately discloses the payload contents (complete description text, last-confirmed-open timestamp). It clearly differentiates from the sibling get_jobs by scoping to a single id.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use ('from search_jobs', single id) and when-not (several ids → get_jobs, which 'costs ONE call against the daily quota'). It also gives an auth precondition and a concrete fallback ('with neither, call fetch with the same id').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full detail for up to 10 job ids in ONE call — the shortlist form of get_job. Each id answers with a card plus its description; ids that closed, aged out or were never on this board come back in unavailable with the reason named, so one dead id never costs you the other nine. Set includeDescription=false for cards and freshness only (much smaller, and no vendor fetch). Needs a key or a sign-in.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | Job ids from search_jobs. Up to 10 per call — each one is a separate detail read that may fetch the employer's page. | |
| includeDescription | No | Default true. Descriptions are capped at 8,000 characters here; call get_job for the whole text of one. |
| Name | Required | Description |
|---|---|---|
| jobs | Yes | |
| returned | No | |
| requested | No | |
| notFetched | No | Ids past the per-call cap — sent, not read. Call again with these. |
| unavailable | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), but the description adds behavior annotations cannot express: partial-failure semantics ('one dead id never costs you the other nine'), the `unavailable` result bucket with reasons, the fact that includeDescription=false avoids a vendor fetch, and the auth requirement ('Needs a key or a sign-in').
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences, front-loaded with the purpose and ending with the auth prerequisite so the critical fact is not buried. The parenthetical asides are informative but make it slightly heavier than it needs to be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value documentation is not required, yet the description still warns about the `unavailable` bucket and named failure reasons. Combined with the auth note and the alternative-tool routing, an agent has everything needed to invoke this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both params and the 8,000-char cap. The description still adds meaning beyond the schema by explaining the cost trade-off behind includeDescription=false ('cards and freshness only, much smaller, no vendor fetch'), which tells the agent why to set it rather than just what it does.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource with scope: 'Full detail for up to 10 job ids in ONE call' and explicitly frames itself as 'the shortlist form of get_job.' An agent can immediately distinguish it from get_job (single, full text) and search_jobs (discovery) without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Names the alternative (get_job) and the conditions that select each: batch shortlist here, full single text there. It further routes the agent on the includeDescription=false path for lighter card-only reads, giving explicit when-to-use guidance rather than leaving it inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What THIS key is and may do: tier, requests left this minute, calls left today (both including this call), whether fit_resume (and engine=ranked on the data API) answers on it, and whether the apply tools would — with any blocker named: account link, Agent plan or live pass, mandate, résumé on file. On an Agent Pass: when the clock ends and how many applications are left (a pass starts at the first call other than this one). Call it first in a keyed session, and after any 'quota' or 'rate' refusal. Needs a key or a sign-in.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| key | Yes | |
| docs | No | |
| pass | Yes | The account's pass, if any. Every figure is read off the pass row; nothing here is a constant. |
| rate | Yes | |
| apply | Yes | |
| quota | Yes | |
| counted | No | |
| features | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower, and the description still adds real context: this call counts toward the very counters it reports, a pass clock 'starts at the first call other than this one,' and it 'Needs a key or a sign-in.' Auth requirement and counter semantics are exactly the kind of disclosure annotations cannot convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The opening clause is well front-loaded ('What THIS key is and may do'), but the body is one long run-on sentence with stacked em-dashes and parentheticals ('(and engine=ranked on the data API)', '(a pass starts at the first call other than this one)') that make it harder to parse than the information warrants. Nearly every clause earns its place, but the packaging is dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need no explanation, and the description nonetheless covers scope, timing of use, auth requirement, and blocker conditions. For a zero-parameter diagnostic tool, an agent has everything required to decide when and how to call it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero parameters, which is the baseline-4 case per the rubric; there is no parameter behavior to disambiguate. The description correctly implies a no-argument call and adds nothing that could mislead about inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific resource (THIS key) and enumerates exactly what the tool reports: tier, per-minute/per-day remaining calls, whether fit_resume/engine=ranked answers, whether the apply tools would fire, and any blocker (account link, Agent plan, mandate, résumé on file). That enumeration distinguishes it from siblings like check_apply_support and application_status, which cover narrower questions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives two explicit triggers: 'Call it first in a keyed session, and after any quota or rate refusal.' That is clear, actionable when-to-use guidance. It doesn't name a sibling as an alternative or state when not to call it, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ask the board's apply agent to submit an application to this job on behalf of the key's owner. Needs an account key (mint one at https://resumebooster.work/agents), an active Agent plan OR a live Agent Pass on the account, and a mandate set in Account — call key_status first: it says which of the three is missing, and on a pass how many applications and how much time are left. On a pass, only a job the agent can submit itself (agentReady true, which check_apply_support reports) uses an application; any other job is refused and nothing is spent. On the Agent plan nothing is counted, and such a job is prepared for the person to send. Every application passes the same gates as the signed-in flow, including the honesty classifier: answers are drawn from the owner's own profile and never invented. Ask the person for a yes on this specific job id before calling. Needs a key or a sign-in.
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | Optional note stored with the request (not sent to the employer). | |
| jobId | Yes | The job id from search_jobs. |
| Name | Required | Description |
|---|---|---|
| fix | No | Refused only: what would change the answer. |
| note | No | |
| error | No | Refused only: what the gate said. |
| jobId | No | |
| title | No | |
| fitPct | No | Keyword fit of the résumé on file to this posting, 0-100; null when the posting has no text to score. |
| company | No | |
| warning | No | Accepted but flagged: below the release floor, or a system the agent prepares for rather than submits to. |
| accepted | Yes | False when a gate refused; true when the request is in the agent's queue (or already was). |
| refusedBy | No | Refused only: the gate — key, jobId, mandate, resume, plan (no Agent plan and no live pass), pass (the pass has no applications left or its clock ended), posting, scope-country, scope-category, scope-age, scope-salary. |
| queueStatus | No | With alreadyQueued: the existing row's status. |
| alreadyQueued | No | Accepted only: this job was already in the queue — nothing duplicated, and on a pass nothing spent. |
| whatHappensNext | No | |
| passApplicationsLeft | No | Accepted on a pass: applications left on it after this one. Null when a subscription funded the request. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag this as destructive, non-read-only, idempotent, and open-world; the description adds crucial context: on a pass, only agentReady jobs consume an application, otherwise refused with nothing spent; on Agent plan, nothing is counted and the job is prepared for manual sending; all applications pass the same gates including an honesty classifier and answers are drawn from the owner's own profile. This exceeds annotation disclosure and clarifies side effects and billing behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-structured: it front-loads the action, then preconditions, then behavioral details. It contains necessary details but is somewhat lengthy; every sentence has purpose, though some could be tightened without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values needn't be explained. The description covers prerequisites, sibling dependencies (key_status, check_apply_support), consent requirement, billing/refusal behavior, and honesty constraints – everything needed to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters are documented. The description adds that the job must be one the agent can submit itself (agentReady true, which check_apply_support reports) and reinforces that consent must be for this specific job id, which adds meaning beyond the schema's 'job id from search_jobs.' The note parameter is not elaborated in the description, but the schema covers it adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('submit an application to this job') and actor ('on behalf of the key's owner'), clearly differentiating from siblings like check_apply_support (readiness check) and application_status (tracking). An agent knows exactly what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit preconditions (account key, active plan or pass, mandate) and directs to key_status first and check_apply_support for agentReady. It also states a consent requirement: 'Ask the person for a yes on this specific job id before calling.' The when-to-use and prerequisites are fully spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
An ALIAS of search_jobs in the fixed shape ChatGPT's deep-research and company-knowledge connectors call: one query string in, {results:[{id,title,url}]} out. Every result's id is the job id fetch and every other tool take; url is the employer's own apply page when the board holds one, else the posting's page on the site. Same board, same ranking, same limit as an unkeyed search_jobs (10 rows); the disclosures ride beside the results. Any other client should call search_jobs, which takes every filter.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Free text — title, skills, a place, exclusions with a leading minus. |
| Name | Required | Description |
|---|---|---|
| note | No | |
| total | No | Exact match count. ABSENT with countUnavailable:true when the board refuses to guess. |
| hasMore | No | |
| results | Yes | |
| didYouMean | No | |
| nextOffset | No | Pass back as `offset` for the next page. |
| relatedTotal | No | Further postings matched in the description only, beyond `total` (which counts title matches). Each card says which in matchScope. |
| excludedTerms | No | |
| intentFilters | No | Words read out of the query as filters. |
| relatedCapped | No | relatedTotal stopped counting at the board's cap; the true figure is higher. |
| filterCoverage | No | For each filter applied, the live share (0-1) of the board that states the field it filters on; rows that state nothing are excluded. |
| ignoredFilters | No | Filters the board could NOT apply. Results answer a wider question than was asked. |
| agenciesExcluded | No | Row-selecting: disclosed agency inventory is hidden from this page. |
| countUnavailable | No | The board could not count this query exactly — do not report a total. |
| filterCoverageAt | No | When filterCoverage was measured. ABSENT when a figure is a pinned fallback rather than a live reading. |
| salaryStatedOnly | No | Row-selecting: this page excludes the postings with no annualised figure in approximate US dollars, including postings that publish an hourly rate (filterCoverage, when present, gives the live share). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, openWorld, non-destructive), so the bar is lower, yet the description adds real context: the result cap (10 rows), that ranking and board match an unkeyed search_jobs, that disclosures ride beside results, and what id and url actually denote. It stops short of describing pagination or failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The alias identity and the routing rule are front-loaded in the first and last sentences, with the return-shape and limit details sandwiched in between. Three sentences, no filler, and every clause carries information an agent needs to decide or parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so the shape itself need not be explained, yet the description still supplies the semantics of id and url and the 10-row limit. Combined with annotations and the explicit sibling routing, an agent has everything needed to invoke this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single query parameter has 100% schema description coverage, including the leading-minus exclusion syntax, so the schema carries the burden. The description only says "one query string in" and adds no syntax or format detail beyond the schema, which is the baseline-3 case for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource (a search that is an alias of search_jobs) and pins down the contract: one query string in, a fixed {results:[{id,title,url}]} shape out. It explicitly distinguishes itself from the sibling search_jobs, so an agent can choose between them without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the exact call condition (the fixed shape ChatGPT's deep-research and company-knowledge connectors use) and an explicit exclusion: "Any other client should call search_jobs, which takes every filter." Both the when and the when-not, plus the named alternative, are present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the live job board (postings pulled directly from employers' own hiring systems, 30-day freshness cap; board_stats carries the live totals). Returns compact job cards — including the board's own parsed pay (salaryMinAnnual/salaryMaxAnnual/salaryPeriod), experience band and minYears, so pay and seniority never have to be re-read out of prose — plus the board's honesty disclosures: exact totals when knowable (countUnavailable otherwise), filters it could not honour (ignoredFilters), words it read as filters (intentFilters), and spelling suggestions. Set agentReadyOnly=true to see only jobs the apply agent can submit to directly.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Default relevance. | |
| limit | No | Rows per page, 1-60. Default 20. | |
| query | No | Search terms. Supports exclusions: 'engineer -senior'. | |
| offset | No | Paging offset — pass back the previous response's nextOffset. | |
| remote | No | Only remote-friendly roles. | |
| vendor | No | Comma list of hiring-system vendors (greenhouse, lever, ashby, …), max 8. Not available here: usajobs, smartrecruiters — Two hiring systems are shown on resumebooster.work but not handed on by this connector: the U.S. federal job feed, whose terms of use forbid redistributing it as a data feed, and SmartRecruiters, withheld until SmartRecruiters (SAP) permits it. No tool here returns their rows; open the posting on the site instead. Naming one is refused rather than answered with an empty page. | |
| country | No | ISO-2 codes, comma-separated, max 5. E.g. 'US,GB'. | |
| category | No | Comma list of category slugs (see board_stats for the live set), max 3. | |
| location | No | City/state/metro, e.g. 'texas', 'NYC', 'berlin'. | |
| maxYears | No | Only roles asking for at most N years of experience. | |
| payBasis | No | Restrict to hourly or salaried pay. | |
| workMode | No | Comma list of: remote, hybrid, onsite. | |
| companies | No | Scope to specific employers: a comma list of companyToken values from job cards (or from the site's employer pages). An employer the board does not carry simply matches nothing; tokens the board drops are named in ignoredFilters. | |
| salaryMax | No | Annual USD-equivalent salary ceiling. | |
| salaryMin | No | Annual USD-equivalent salary floor. Many postings state no comparable pay; the response's filterCoverage gives the live share this floor can see, dated by filterCoverageAt. | |
| department | No | Substring match on the employer's own department/team text. | |
| experience | No | Comma list of seniority bands the POSTING asks for: entry, mid, senior, expert. Rows whose band could not be read are excluded — use maxYears for the candidate's own side of the question. | |
| maxAgeDays | No | Only postings from the last N days (1-30). | |
| postedAfter | No | ISO-8601 instant; only postings the EMPLOYER dated after it. Undated rows fall out of this window (unlike maxAgeDays, which falls back to when the board first saw a posting), so this is the strict form of 'new'. | |
| hasStatedPay | No | Only postings whose pay field carries a figure the employer published — hourly and per-shift rates included, read from the `salary` field. The response's filterCoverage gives the live share. Narrower than it sounds only for RANKING: salaryFloor compares an annualised figure in approximate US dollars, which fewer postings carry, so some rows this returns cannot be filtered by pay amount. | |
| agentReadyOnly | No | Only jobs the apply agent can submit to on the user's behalf. | |
| employmentType | No | Comma list of: full_time, part_time, contract, temporary, internship. | |
| excludeAgencies | No | Hide postings from staffing/recruiting agencies (their job cards carry agency:true). Agencies are served by default; this is an opt-in narrowing. | |
| includeUnstatedPay | No | WIDENS an active salaryMin/salaryMax band to also admit postings that state no pay at all. Inert with no band set (unpriced rows are already included). The response says salaryStatedOnly when a band is narrowing without it. |
| Name | Required | Description |
|---|---|---|
| jobs | Yes | |
| total | No | Exact match count. ABSENT with countUnavailable:true when the board refuses to guess. |
| hasMore | No | |
| didYouMean | No | |
| nextOffset | No | Pass back as `offset` for the next page. |
| relatedTotal | No | Further postings matched in the description only, beyond `total` (which counts title matches). Each card says which in matchScope. |
| excludedTerms | No | |
| intentFilters | No | Words read out of the query as filters. |
| relatedCapped | No | relatedTotal stopped counting at the board's cap; the true figure is higher. |
| filterCoverage | No | For each filter applied, the live share (0-1) of the board that states the field it filters on; rows that state nothing are excluded. |
| ignoredFilters | No | Filters the board could NOT apply. Results answer a wider question than was asked. |
| agenciesExcluded | No | Row-selecting: disclosed agency inventory is hidden from this page. |
| countUnavailable | No | The board could not count this query exactly — do not report a total. |
| filterCoverageAt | No | When filterCoverage was measured. ABSENT when a figure is a pinned fallback rather than a live reading. |
| salaryStatedOnly | No | Row-selecting: this page excludes the postings with no annualised figure in approximate US dollars, including postings that publish an hourly rate (filterCoverage, when present, gives the live share). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the safe read-only/idempotent profile, and the description adds real behavioral context beyond them: the 30-day freshness cap, refusal rather than an empty page when a withheld vendor (usajobs, smartrecruiters) is named, and the response's honesty disclosures (countUnavailable, ignoredFilters, intentFilters, spelling suggestions). It does not detail rate limits or result-size behavior, keeping it out of the top band.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
All content is relevant, but it is delivered as a single sprawling sentence dense with em-dash parentheticals, so the front-loaded core (what the board is) competes with return-field enumeration and disclosure lists. It would read better split into purpose / returns / key-flag sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 24-parameter, zero-required search tool with an output schema, the description covers source, freshness, refusal semantics, return payload shape, and the one flag an agent most needs to set. Nothing required to invoke it correctly is missing, and explaining return fields is a bonus rather than a gap since the output schema already exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description goes further by surfacing the highest-leverage parameter ('agentReadyOnly=true') and framing pay/seniority fields as pre-parsed (salaryMinAnnual, minYears) so the agent knows it need not re-read prose. Most other parameter meaning (includeUnstatedPay, postedAfter vs maxAgeDays) is duplicated from the schema rather than added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource ('Search the live job board') and pins down the data source (postings pulled from employers' own hiring systems) and freshness scope (30-day cap). It never names the sibling it is distinguished from (e.g., get_jobs, search, debug_search), so an agent must infer the boundary between this broad search and the narrower getters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives conditional guidance ('Set agentReadyOnly=true to see only jobs the apply agent can submit to directly') and cross-references board_stats as the place for live totals. It stops short of explicit when-not/alternative routing (e.g., why use this over get_jobs or debug_search), so it is clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
debug_search8 fields changedInput schema / properties / hasStatedPay / descriptionPrevious value: -"Only postings whose pay field carries a figure the employer published — hourly and per-shift rates included, read from the `salary` field. About 28% of the board (2026-09-27). Narrower than it sounds only for RANKING: salaryFloor compares an annualised figure in approximate US dollars, which about 24% carry, so some rows this returns cannot be filtered by pay amount."New value: +"Only postings whose pay field carries a figure the employer published — hourly and per-shift rates included, read from the `salary` field. The response's filterCoverage gives the live share. Narrower than it sounds only for RANKING: salaryFloor compares an annualised figure in approximate US dollars, which fewer postings carry, so some rows this returns cannot be filtered by pay amount."Input schema / properties / salaryMin / descriptionPrevious value: -"Annual USD-equivalent salary floor. Note: only ~13% of postings state pay."New value: +"Annual USD-equivalent salary floor. Many postings state no comparable pay; the response's filterCoverage gives the live share this floor can see, dated by filterCoverageAt."Input schema / properties / vendor / descriptionPrevious value: -"Comma list of hiring-system vendors (greenhouse, lever, ashby, …), max 8. Not available here: usajobs — The U.S. federal job feed is readable on resumebooster.work but may not be redistributed as a data feed under its terms of use, so no tool here returns its rows. Naming one is refused rather than answered with an empty page."New value: +"Comma list of hiring-system vendors (greenhouse, lever, ashby, …), max 8. Not available here: usajobs, smartrecruiters — Two hiring systems are shown on resumebooster.work but not handed on by this connector: the U.S. federal job feed, whose terms of use forbid redistributing it as a data feed, and SmartRecruiters, withheld until SmartRecruiters (SAP) permits it. No tool here returns their rows; open the posting on the site instead. Naming one is refused rather than answered with an empty page."Output schema / properties / outcome / properties / filterCoverageAdded value: +{
+ "additionalProperties": {
+ "type": "number"
+ },
+ "description": "For each filter applied, the live share (0-1) of the board that states the field it filters on; rows that state nothing are excluded.",
+ "type": "object"
+}Output schema / properties / outcome / properties / filterCoverageAtAdded value: +{
+ "description": "When filterCoverage was measured. ABSENT when a figure is a pinned fallback rather than a live reading.",
+ "type": "string"
+}Output schema / properties / outcome / properties / relatedCappedAdded value: +{
+ "description": "relatedTotal stopped counting at the board's cap; the true figure is higher.",
+ "type": "boolean"
+}Output schema / properties / outcome / properties / relatedTotalAdded value: +{
+ "description": "Further postings matched in the description only, beyond `total` (which counts title matches). Each card says which in matchScope.",
+ "type": "integer"
+}Output schema / properties / outcome / properties / salaryStatedOnly / descriptionPrevious value: -"Row-selecting: this page excludes the ~76% of postings with no annualised figure in approximate US dollars (2026-09-27), including postings that publish an hourly rate."New value: +"Row-selecting: this page excludes the postings with no annualised figure in approximate US dollars, including postings that publish an hourly rate (filterCoverage, when present, gives the live share)."fit_resume9 fields changedOutput schema / properties / filterCoverageAdded value: +{
+ "additionalProperties": {
+ "type": "number"
+ },
+ "description": "For each filter applied, the live share (0-1) of the board that states the field it filters on; rows that state nothing are excluded.",
+ "type": "object"
+}Output schema / properties / filterCoverageAtAdded value: +{
+ "description": "When filterCoverage was measured. ABSENT when a figure is a pinned fallback rather than a live reading.",
+ "type": "string"
+}Output schema / properties / jobs / items / properties / matchScopeAdded value: +{
+ "description": "Which part of the posting matched the query. ABSENT when the board's path did not say.",
+ "enum": [
+ "title",
+ "description"
+ ],
+ "type": "string"
+}Output schema / properties / jobs / items / properties / minYears / descriptionPrevious value: -"Years of experience the posting asks for. ABSENT when it names none (~71%)."New value: +"Years of experience the posting asks for. ABSENT when it names none (most postings)."Output schema / properties / jobs / items / properties / salaryPeriod / descriptionPrevious value: -"The period the employer stated: hour, month, year. ABSENT when unstated (~89% of the board)."New value: +"The period the employer stated: hour, month, year. ABSENT when unstated (most postings)."Output schema / properties / jobs / items / properties / siteUrlAdded value: +{
+ "description": "The posting's page on resumebooster.work.",
+ "type": "string"
+}Output schema / properties / relatedCappedAdded value: +{
+ "description": "relatedTotal stopped counting at the board's cap; the true figure is higher.",
+ "type": "boolean"
+}Output schema / properties / relatedTotalAdded value: +{
+ "description": "Further postings matched in the description only, beyond `total` (which counts title matches). Each card says which in matchScope.",
+ "type": "integer"
+}Output schema / properties / salaryStatedOnly / descriptionPrevious value: -"Row-selecting: this page excludes the ~76% of postings with no annualised figure in approximate US dollars (2026-09-27), including postings that publish an hourly rate."New value: +"Row-selecting: this page excludes the postings with no annualised figure in approximate US dollars, including postings that publish an hourly rate (filterCoverage, when present, gives the live share)."get_job4 fields changedOutput schema / properties / matchScopeAdded value: +{
+ "description": "Which part of the posting matched the query. ABSENT when the board's path did not say.",
+ "enum": [
+ "title",
+ "description"
+ ],
+ "type": "string"
+}Output schema / properties / minYears / descriptionPrevious value: -"Years of experience the posting asks for. ABSENT when it names none (~71%)."New value: +"Years of experience the posting asks for. ABSENT when it names none (most postings)."Output schema / properties / salaryPeriod / descriptionPrevious value: -"The period the employer stated: hour, month, year. ABSENT when unstated (~89% of the board)."New value: +"The period the employer stated: hour, month, year. ABSENT when unstated (most postings)."Output schema / properties / siteUrlAdded value: +{
+ "description": "The posting's page on resumebooster.work.",
+ "type": "string"
+}get_jobs4 fields changedOutput schema / properties / jobs / items / properties / matchScopeAdded value: +{
+ "description": "Which part of the posting matched the query. ABSENT when the board's path did not say.",
+ "enum": [
+ "title",
+ "description"
+ ],
+ "type": "string"
+}Output schema / properties / jobs / items / properties / minYears / descriptionPrevious value: -"Years of experience the posting asks for. ABSENT when it names none (~71%)."New value: +"Years of experience the posting asks for. ABSENT when it names none (most postings)."Output schema / properties / jobs / items / properties / salaryPeriod / descriptionPrevious value: -"The period the employer stated: hour, month, year. ABSENT when unstated (~89% of the board)."New value: +"The period the employer stated: hour, month, year. ABSENT when unstated (most postings)."Output schema / properties / jobs / items / properties / siteUrlAdded value: +{
+ "description": "The posting's page on resumebooster.work.",
+ "type": "string"
+}key_status3 fields changedOutput schema / properties / features / properties / fit_resume / descriptionPrevious value: -"Paid tiers and a live pass, exactly as POST /v1/fit plus the pass."New value: +"Paid tiers, a live pass, and keys of an account on the Agent plan: POST /v1/fit plus the pass and the plan."Output schema / properties / pass / properties / buy / descriptionPrevious value: -"Where a pass is bought, signed in."New value: +"Where a pass is bought, signed in. ABSENT inside ChatGPT, whose app rules forbid purchase links."Output schema / properties / pass / requiredPrevious value: -[
- "state",
- "startsOn",
- "buy"
-]New value: +[
+ "state",
+ "startsOn"
+]search5 fields changedOutput schema / properties / filterCoverageAdded value: +{
+ "additionalProperties": {
+ "type": "number"
+ },
+ "description": "For each filter applied, the live share (0-1) of the board that states the field it filters on; rows that state nothing are excluded.",
+ "type": "object"
+}Output schema / properties / filterCoverageAtAdded value: +{
+ "description": "When filterCoverage was measured. ABSENT when a figure is a pinned fallback rather than a live reading.",
+ "type": "string"
+}Output schema / properties / relatedCappedAdded value: +{
+ "description": "relatedTotal stopped counting at the board's cap; the true figure is higher.",
+ "type": "boolean"
+}Output schema / properties / relatedTotalAdded value: +{
+ "description": "Further postings matched in the description only, beyond `total` (which counts title matches). Each card says which in matchScope.",
+ "type": "integer"
+}Output schema / properties / salaryStatedOnly / descriptionPrevious value: -"Row-selecting: this page excludes the ~76% of postings with no annualised figure in approximate US dollars (2026-09-27), including postings that publish an hourly rate."New value: +"Row-selecting: this page excludes the postings with no annualised figure in approximate US dollars, including postings that publish an hourly rate (filterCoverage, when present, gives the live share)."search_jobs12 fields changedInput schema / properties / hasStatedPay / descriptionPrevious value: -"Only postings whose pay field carries a figure the employer published — hourly and per-shift rates included, read from the `salary` field. About 28% of the board (2026-09-27). Narrower than it sounds only for RANKING: salaryFloor compares an annualised figure in approximate US dollars, which about 24% carry, so some rows this returns cannot be filtered by pay amount."New value: +"Only postings whose pay field carries a figure the employer published — hourly and per-shift rates included, read from the `salary` field. The response's filterCoverage gives the live share. Narrower than it sounds only for RANKING: salaryFloor compares an annualised figure in approximate US dollars, which fewer postings carry, so some rows this returns cannot be filtered by pay amount."Input schema / properties / salaryMin / descriptionPrevious value: -"Annual USD-equivalent salary floor. Note: only ~13% of postings state pay."New value: +"Annual USD-equivalent salary floor. Many postings state no comparable pay; the response's filterCoverage gives the live share this floor can see, dated by filterCoverageAt."Input schema / properties / vendor / descriptionPrevious value: -"Comma list of hiring-system vendors (greenhouse, lever, ashby, …), max 8. Not available here: usajobs — The U.S. federal job feed is readable on resumebooster.work but may not be redistributed as a data feed under its terms of use, so no tool here returns its rows. Naming one is refused rather than answered with an empty page."New value: +"Comma list of hiring-system vendors (greenhouse, lever, ashby, …), max 8. Not available here: usajobs, smartrecruiters — Two hiring systems are shown on resumebooster.work but not handed on by this connector: the U.S. federal job feed, whose terms of use forbid redistributing it as a data feed, and SmartRecruiters, withheld until SmartRecruiters (SAP) permits it. No tool here returns their rows; open the posting on the site instead. Naming one is refused rather than answered with an empty page."Output schema / properties / filterCoverageAdded value: +{
+ "additionalProperties": {
+ "type": "number"
+ },
+ "description": "For each filter applied, the live share (0-1) of the board that states the field it filters on; rows that state nothing are excluded.",
+ "type": "object"
+}Output schema / properties / filterCoverageAtAdded value: +{
+ "description": "When filterCoverage was measured. ABSENT when a figure is a pinned fallback rather than a live reading.",
+ "type": "string"
+}Output schema / properties / jobs / items / properties / matchScopeAdded value: +{
+ "description": "Which part of the posting matched the query. ABSENT when the board's path did not say.",
+ "enum": [
+ "title",
+ "description"
+ ],
+ "type": "string"
+}Output schema / properties / jobs / items / properties / minYears / descriptionPrevious value: -"Years of experience the posting asks for. ABSENT when it names none (~71%)."New value: +"Years of experience the posting asks for. ABSENT when it names none (most postings)."Output schema / properties / jobs / items / properties / salaryPeriod / descriptionPrevious value: -"The period the employer stated: hour, month, year. ABSENT when unstated (~89% of the board)."New value: +"The period the employer stated: hour, month, year. ABSENT when unstated (most postings)."Output schema / properties / jobs / items / properties / siteUrlAdded value: +{
+ "description": "The posting's page on resumebooster.work.",
+ "type": "string"
+}Output schema / properties / relatedCappedAdded value: +{
+ "description": "relatedTotal stopped counting at the board's cap; the true figure is higher.",
+ "type": "boolean"
+}Output schema / properties / relatedTotalAdded value: +{
+ "description": "Further postings matched in the description only, beyond `total` (which counts title matches). Each card says which in matchScope.",
+ "type": "integer"
+}Output schema / properties / salaryStatedOnly / descriptionPrevious value: -"Row-selecting: this page excludes the ~76% of postings with no annualised figure in approximate US dollars (2026-09-27), including postings that publish an hourly rate."New value: +"Row-selecting: this page excludes the postings with no annualised figure in approximate US dollars, including postings that publish an hourly rate (filterCoverage, when present, gives the live share)."debug_search2 fields changedInput schema / properties / hasStatedPay / descriptionPrevious value: -"Only postings that state a salary (excludes the ~87% that don't)."New value: +"Only postings whose pay field carries a figure the employer published — hourly and per-shift rates included, read from the `salary` field. About 28% of the board (2026-09-27). Narrower than it sounds only for RANKING: salaryFloor compares an annualised figure in approximate US dollars, which about 24% carry, so some rows this returns cannot be filtered by pay amount."Output schema / properties / outcome / properties / salaryStatedOnly / descriptionPrevious value: -"Row-selecting: this page excludes the ~87% of postings with no stated pay."New value: +"Row-selecting: this page excludes the ~76% of postings with no annualised figure in approximate US dollars (2026-09-27), including postings that publish an hourly rate."fit_resume2 fields changedOutput schema / properties / jobs / items / properties / workMode / descriptionPrevious value: -"Stated or inferred from title/location; null when neither says."New value: +"The employer's own statement: the option they chose in their ATS, or their own words on the posting (title, location, department). null has THREE meanings: neither source says anything, the two disagree and the board refuses to choose, or the posting is older than the vendor field this board now reads. Never inferred from the description, and silence is never read as onsite."Output schema / properties / salaryStatedOnly / descriptionPrevious value: -"Row-selecting: this page excludes the ~87% of postings with no stated pay."New value: +"Row-selecting: this page excludes the ~76% of postings with no annualised figure in approximate US dollars (2026-09-27), including postings that publish an hourly rate."get_job1 field changedOutput schema / properties / workMode / descriptionPrevious value: -"Stated or inferred from title/location; null when neither says."New value: +"The employer's own statement: the option they chose in their ATS, or their own words on the posting (title, location, department). null has THREE meanings: neither source says anything, the two disagree and the board refuses to choose, or the posting is older than the vendor field this board now reads. Never inferred from the description, and silence is never read as onsite."get_jobs1 field changedOutput schema / properties / jobs / items / properties / workMode / descriptionPrevious value: -"Stated or inferred from title/location; null when neither says."New value: +"The employer's own statement: the option they chose in their ATS, or their own words on the posting (title, location, department). null has THREE meanings: neither source says anything, the two disagree and the board refuses to choose, or the posting is older than the vendor field this board now reads. Never inferred from the description, and silence is never read as onsite."search1 field changedOutput schema / properties / salaryStatedOnly / descriptionPrevious value: -"Row-selecting: this page excludes the ~87% of postings with no stated pay."New value: +"Row-selecting: this page excludes the ~76% of postings with no annualised figure in approximate US dollars (2026-09-27), including postings that publish an hourly rate."search_jobs3 fields changedInput schema / properties / hasStatedPay / descriptionPrevious value: -"Only postings that state a salary (excludes the ~87% that don't)."New value: +"Only postings whose pay field carries a figure the employer published — hourly and per-shift rates included, read from the `salary` field. About 28% of the board (2026-09-27). Narrower than it sounds only for RANKING: salaryFloor compares an annualised figure in approximate US dollars, which about 24% carry, so some rows this returns cannot be filtered by pay amount."Output schema / properties / jobs / items / properties / workMode / descriptionPrevious value: -"Stated or inferred from title/location; null when neither says."New value: +"The employer's own statement: the option they chose in their ATS, or their own words on the posting (title, location, department). null has THREE meanings: neither source says anything, the two disagree and the board refuses to choose, or the posting is older than the vendor field this board now reads. Never inferred from the description, and silence is never read as onsite."Output schema / properties / salaryStatedOnly / descriptionPrevious value: -"Row-selecting: this page excludes the ~87% of postings with no stated pay."New value: +"Row-selecting: this page excludes the ~76% of postings with no annualised figure in approximate US dollars (2026-09-27), including postings that publish an hourly rate."debug_search1 field changedInput schema / properties / vendor / descriptionPrevious value: -"Comma list of hiring-system vendors (greenhouse, lever, ashby, …), max 8."New value: +"Comma list of hiring-system vendors (greenhouse, lever, ashby, …), max 8. Not available here: usajobs — The U.S. federal job feed is readable on resumebooster.work but may not be redistributed as a data feed under its terms of use, so no tool here returns its rows. Naming one is refused rather than answered with an empty page."search_jobs1 field changedInput schema / properties / vendor / descriptionPrevious value: -"Comma list of hiring-system vendors (greenhouse, lever, ashby, …), max 8."New value: +"Comma list of hiring-system vendors (greenhouse, lever, ashby, …), max 8. Not available here: usajobs — The U.S. federal job feed is readable on resumebooster.work but may not be redistributed as a data feed under its terms of use, so no tool here returns its rows. Naming one is refused rather than answered with an empty page."employer_hiring_record5 fields changedOutput schema / properties / employers / items / properties / layoff_filingAdded value: +{
+ "additionalProperties": false,
+ "description": "The newest qualifying layoff filing joined to this employer, or null when none qualifies. A fact about the employer on one date, beside the record and no part of it.",
+ "properties": {
+ "effective_date": {
+ "description": "The date the WARN notice gives for the separations; null when it gives none or on an SEC filing.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "event_basis": {
+ "type": "string"
+ },
+ "event_date": {
+ "description": "The filing's own date: the WARN notice date or the 8-K report date. Named by event_basis.",
+ "type": "string"
+ },
+ "event_type": {
+ "description": "What the WARN notice says it is, as the state classifies it; null on an SEC filing.",
+ "enum": [
+ "closure",
+ "layoff",
+ "relocation",
+ "unknown",
+ null
+ ],
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "filer": {
+ "description": "The employer as the source names it, verbatim — never the board's own display name.",
+ "type": "string"
+ },
+ "form": {
+ "description": "The SEC form (an amendment never appears); null on a WARN notice.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "headcount": {
+ "description": "Positions the 8-K states, as parsed; null when it states none or on a WARN notice.",
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "more_n": {
+ "description": "Further qualifying filings for this employer beyond this newest one.",
+ "type": "integer"
+ },
+ "pct": {
+ "description": "Workforce share the 8-K states, as parsed; null when it states none or on a WARN notice.",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "public_basis": {
+ "type": "string"
+ },
+ "public_date": {
+ "description": "When it became public: the SEC file date or the state's received/processed/posted stamp. Named by public_basis.",
+ "type": "string"
+ },
+ "read_at": {
+ "description": "When we read it. Our stamp, never a date basis for the filing.",
+ "type": "string"
+ },
+ "relation": {
+ "description": "filer: the filer is this board's employer. subsidiary_site: the filer is the parent company of this board's employer.",
+ "enum": [
+ "filer",
+ "subsidiary_site"
+ ],
+ "type": "string"
+ },
+ "site": {
+ "description": "The notice's site as the state lists it; null when not stated or on an SEC filing.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "source": {
+ "description": "state_warn: a US state WARN notice. sec_8k_205: an SEC 8-K Item 2.05 disclosure.",
+ "enum": [
+ "sec_8k_205",
+ "state_warn"
+ ],
+ "type": "string"
+ },
+ "source_name": {
+ "description": "SEC EDGAR, or the state agency as it names itself.",
+ "type": "string"
+ },
+ "source_url": {
+ "description": "The filing itself, at the source.",
+ "type": "string"
+ },
+ "state": {
+ "description": "Two-letter state of a WARN notice; null on an SEC filing.",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "workers": {
+ "description": "Positions the WARN notice states at that site. Null on an SEC filing — never zero.",
+ "type": [
+ "integer",
+ "null"
+ ]
+ }
+ },
+ "required": [
+ "source",
+ "relation",
+ "filer",
+ "event_date",
+ "event_basis",
+ "public_date",
+ "public_basis",
+ "state",
+ "site",
+ "workers",
+ "event_type",
+ "effective_date",
+ "pct",
+ "headcount",
+ "form",
+ "source_url",
+ "source_name",
+ "read_at",
+ "more_n"
+ ],
+ "type": [
+ "object",
+ "null"
+ ]
+}Output schema / properties / employers / items / requiredPrevious value: -[
- "company_token",
- "record",
- "basis"
-]New value: +[
+ "company_token",
+ "record",
+ "basis",
+ "layoff_filing"
+]Output schema / properties / layoff_basisAdded value: +{
+ "description": "What layoff_filing is and is not, beside every row's record.",
+ "type": "string"
+}Output schema / properties / layoff_readAdded value: +{
+ "description": "\"ok\" when the filing reader answered for every employer; otherwise \"unread: <fault>\" and every layoff_filing on this response is null for that reason, never because nothing qualified. The record is unaffected either way.",
+ "type": "string"
+}Output schema / requiredPrevious value: -[
- "employers",
- "basis"
-]New value: +[
+ "employers",
+ "basis",
+ "layoff_basis",
+ "layoff_read"
+]application_statusboard_statscheck_apply_supportcheck_jobs_opendebug_searchemployer_growthemployer_hiring_recordfetchfit_resumeget_jobget_jobskey_statusrequest_applicationsearchsearch_jobsLive jobs from ~5,000 employer ATS boards, hiring profiles, your job profile and tracker.
Free live multi-ATS + HN job search. Comp & hiring-signal depth metered via x402/USDC. Hosted MCP.
Job postings search: find, count and read open jobs from employer career sites, with pay and links.
Search a live index of millions of open jobs from employer career sites and 100+ ATS platforms.
Add one secure layer between your agents and this server.
