Job search over employers' own hiring systems. Search with no key; a free key opens every read tool.
Scored across 15 tools
Most tools have distinct resource/action targets such as search, job detail, apply support, application submission, key status, and employer analytics. The main overlap is deliberate: search/fetch are aliases of search_jobs/get_job for ChatGPT connectors, and employer_growth vs employer_hiring_record are adjacent employer metrics; descriptions explain when to use each, but duplicate-purpose tools remain visible.
All names use snake_case, and most are action-oriented (get_job, search_jobs, check_apply_support, request_application). Deviations are limited to bare verb aliases (fetch, search), noun-status tools (application_status, board_stats, key_status), and employer-prefixed metrics; readable and mostly consistent.
15 tools is at the upper end of the ideal range but appropriate for a job-board API with search, batch detail, apply-agent, résumé scoring, employer analytics, and key/quota tools. Aliases add two entries, but each tool has a clear operational role.
Core lifecycle is covered: discovery/search, job detail, batch re-verification, apply support, application submission, status, key quota, résumé scoring, and employer research. Minor gaps exist around application withdrawal/cancellation and richer application history, but no dead end for the primary agent workflow.
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 — 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. | |
| 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. Note: only ~13% of postings state pay. | |
| 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. 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. | |
| 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 read-only/idempotent/non-destructive safety profile, but the description adds real context beyond them: the auth requirement ('needs a key or a sign-in') and a substantive account of what the trace contains, including that ignored filters are surfaced by name. No rate limits or cost details are given, so 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?
One dense paragraph, but front-loaded with the core purpose and the when-to-use clause before the payload enumeration. The list of trace contents is long but each item is concrete; a little trimming of the parenthetical enumerations would tighten it without losing information.
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, no-required-field diagnostic tool with an output schema, the description covers purpose, trigger, argument equivalence, auth needs and payload contents. Return values are properly delegated to the output schema. Only the absence of any guidance on failure/empty-trace behavior keeps it below 5.
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% across all 24 params, so the schema already carries the full semantic load. The description only adds the meta-fact that it accepts the SAME arguments as search_jobs, which is useful but not parameter-level meaning. 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?
States a specific verb and resource — explain WHY a search returns what it does — and enumerates the concrete artifacts returned (parsed query, applied vs ignored filters, route/retriever, ranking regime, run timings). It is clearly distinguishable from siblings search and search_jobs because it is positioned as the diagnostic trace rather than a results fetch.
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 an explicit trigger condition: use it when a search returns surprising, empty, or mis-ranked results. It also anchors the argument contract to search_jobs, implicitly routing normal retrieval to that sibling. There is no explicit when-not statement (e.g. 'do not use for fetching results'), so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 on the key's account; a free key gets an in-band refusal naming where to upgrade. 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. |
| excludedTerms | No | |
| intentFilters | No | Words read out of the query as filters. |
| 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. |
| salaryStatedOnly | No | 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations already covering read-only/idempotent/no-destructive, the description adds genuinely new behavior: PAID access requiring a paid key or Agent Pass, an in-band refusal for free keys naming where to upgrade, and the meaning of a null fit. This is exactly the value-add beyond structured 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?
Front-loaded with the purpose and workflow, then the paid/auth caveat and return semantics. It is dense and slightly run-on with stacked parentheticals, but each clause carries information an agent needs.
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 not be re-explained, yet the description still notes the returned terms and the null-fit case. Auth requirements, pricing, and refusal behavior are all covered — nothing an agent needs to invoke this 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?
Schema coverage is only 50% (remote, country, location undocumented), so the description carries extra burden. It adds real meaning for resumeText (plain text, 100+ chars), query (title to search instead of CV-derived one), and the limit=20 cap, but says nothing about remote/country/location filters, leaving a partial gap.
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 and resource ('Score a résumé against open jobs') and elaborates the pipeline (read occupation, search board, score up to 20 results), which clearly separates it from siblings like search_jobs or get_job. It stops short of naming an alternative sibling explicitly, so it lands at a strong 4 rather than 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 scopes the caller ('for an agent holding a CV') and gives a concrete workflow: use resumeText, or pass `query` if you already have a title, and re-call with `query` if the returned terms are wrong. No explicit when-not or named alternative, so 4.
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. |
| applyUrl | No | |
| category | No | |
| location | No | |
| minYears | No | Years of experience the posting asks for. ABSENT when it names none (~71%). |
| 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. |
| 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 (~89% of the board). |
| 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 readOnly/idempotent/non-destructive/openWorld, but the description adds non-obvious operational context: the auth precondition ('Needs a key or a sign-in'), the unauthenticated fallback, and the fact that each call consumes the daily quota. It also notes what the payload contains (complete description text, last-confirmed-open). Return format details are largely left to the output 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?
Four dense sentences, front-loaded with the purpose and content, then the id provenance, then the alternative and auth path. No filler, though the parenthetical list of sibling tools sharing the id is slightly list-heavy.
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 one-param, output-schema-backed read tool, everything an agent needs is present: what it returns, how to obtain the id, the batch alternative, and the credential/fallback path. Nothing material is missing or deferred to guesswork.
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?
With 100% schema coverage the baseline is 3, but the description adds real meaning: it tells the agent the id is the same value as the job=<id> query param in a resumebooster.work link and is shared by fetch, check_apply_support and request_application, plus where to obtain it (search_jobs). That cross-tool identity 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 qualifies scope and source ('from search_jobs'), which cleanly separates it from get_jobs (multiple ids) and fetch. An agent can pick it out 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?
Explicit when-to-use (single id, need full description text), explicit alternative for the multi-case ('For several ids at once, use get_jobs — it costs ONE call'), and an explicit fallback when unauthenticated ('call fetch with the same id'). Routing is fully specified.
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 safety (readOnly, idempotent, openWorld), yet the description adds real behavior: dead/aged-out/off-board ids surface in `unavailable` with a named reason and don't fail the batch, includeDescription=false avoids the vendor fetch, and auth is required ('needs a key or a sign-in'). This is exactly the extra context annotations can't carry.
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 core capability and tightly written; every clause carries information. It is dense (long em-dash-chained sentences) which costs a little readability but nothing is 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?
With an output schema present the description needn't describe returns, and it covers the remaining agent-relevant facts: batch cap, partial-failure semantics, the size/fetch tradeoff, and auth. Nothing needed 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?
Schema coverage is 100%, so baseline is 3, but the description adds consequence-level meaning: the ids cap of 10 is framed as '10 separate detail reads that may fetch the employer's page', and includeDescription=false is explained as 'cards and freshness only (much smaller, and no vendor fetch)'.
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 with scope ('Full detail for up to 10 job ids in ONE call') and explicitly positions itself against the sibling get_job as 'the shortlist form'. An agent can distinguish it from get_job and search_jobs 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?
Routes clearly: batch here vs. single-id detail via get_job (reinforced by the includeDescription param note), and gives a concrete condition for includeDescription=false ('much smaller, and no vendor fetch'). It doesn't spell out a when-not beyond that, but the alternative is named.
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 declare readOnly, idempotent, and non-destructive behavior. The description adds valuable context beyond that: counts include the current call, an Agent Pass starts at the first call other than this one, and it names specific blockers. This gives the agent meaningful behavioral detail.
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 every clause adds relevant information, and the key purpose is front-loaded. It is somewhat run-on and hard to parse due to dashes and nested clauses, but there is no fluff or repetition beyond the title echo.
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 output schema exists, the description does not need to explain return values. It covers what the tool reports, when to call it, and access prerequisites. The main limitation is the awkward prose, which may make some details easy to miss, but nothing critical appears absent.
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 schema coverage is 100%, so there is nothing to clarify. The description still notes access requirements (key or sign-in), which is useful but not parameter-specific. Baseline for zero-parameter tools is appropriately strong.
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 what the tool reports: the API key's tier, remaining requests and calls, whether fit_resume and apply tools would work, and blocker details. It differentiates itself from siblings like application_status and check_apply_support by focusing on the key itself rather than job or application state.
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 says to call it first in a keyed session and after quota/rate refusals. It does not discuss when not to use it or name alternatives, but the use case is clearly specified.
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 (bought signed-in at https://resumebooster.work/agents/pass), 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. 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?
Beyond annotations (which declare destructiveHint=true, readOnlyHint=false, etc.), the description discloses that every application passes the same gates as the signed-in flow including an honesty classifier, that answers are drawn from the owner's profile and never invented, and that it requires a key or sign-in. It also hints at consumption by mentioning key_status reports how many applications are left. This goes well beyond the structured 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 description is dense but every sentence carries essential information: the action, prerequisites, the need to call key_status, consent requirement, and the honesty classifier behavior. It's front-loaded with the action and then the required steps. Slightly long, but no filler; a 4 is warranted for being thorough without being verbose.
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 tool's complexity (mutation, external effects, prerequisites), the description covers everything an agent needs: what to do first (key_status), what to confirm (consent), what resources are required (key/plan/pass/mandate), and the behavioral guarantees (honesty classifier, profile-based answers). With an output schema present, return format is not required. The description is complete for correct invocation.
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 100% coverage with descriptions for both parameters: jobId is 'The job id from search_jobs' and note is 'Optional note stored with the request (not sent to the employer).' The description doesn't add extra parameter-specific guidance (e.g., format or usage of jobId), but with full schema coverage, the 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 states a specific verb and resource: 'Ask the board's apply agent to submit an application to this job on behalf of the key's owner.' This clearly distinguishes it from siblings like application_status or check_apply_support, which are read/check tools. The core action is 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 pre-call steps: 'call key_status first' to determine missing prerequisites, and 'Ask the person for a yes on this specific job id before calling.' It also enumerates required conditions (key, active plan/pass, mandate), effectively telling the agent when and how to use the tool. It doesn't name alternatives but gives a clear workflow.
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. |
| excludedTerms | No | |
| intentFilters | No | Words read out of the query as filters. |
| 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. |
| salaryStatedOnly | No | 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely non-structured context: identical ranking and 10-row limit versus unkeyed search_jobs, that disclosures 'ride beside the results', and that url falls back to the posting's page when no employer apply page exists.
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 alias identity and the shape before the routing advice; every sentence carries distinct information. It is slightly dense across three sentences, but nothing is redundant or 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?
An output schema exists, yet the description still notes the envelope and the id/url meaning that drive cross-tool routing. Combined with the annotations, the only required parameter, and the sibling alternatives, an agent has everything needed to select and 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?
The single query parameter is already 100% documented in the schema, including free-text syntax and leading-minus exclusions. The description only frames it as 'one query string in', adding no syntax or constraint beyond the schema, so the 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 exactly what it is (an alias of search_jobs), the fixed input/output shape, and the response envelope {results:[{id,title,url}]}. It also distinguishes the id's downstream use (fetch and every other tool) and the url's semantics, so an agent can place it precisely against siblings 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?
Explicitly says which clients should use it (ChatGPT deep-research and company-knowledge connectors) and names the alternative for everyone else: 'Any other client should call search_jobs, which takes every filter.' It also states the equivalence: same board, same ranking, same unkeyed limit of 10 rows.
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 — 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. | |
| 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. Note: only ~13% of postings state pay. | |
| 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. 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. | |
| 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. |
| excludedTerms | No | |
| intentFilters | No | Words read out of the query as filters. |
| 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. |
| salaryStatedOnly | No | 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover the read-only/idempotent/open-world profile; the description adds substantial behavior the agent could not infer: the 30-day freshness cap, that pay/seniority are pre-parsed rather than prose, and the board's honesty disclosures (countUnavailable when totals aren't knowable, ignoredFilters for filters that could not be honoured, intentFilters for words read as filters, plus spelling suggestions). That is exactly the kind of non-obvious contract detail that prevents misreading results.
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?
It is front-loaded: what it searches, then what it returns, then the one actionable setting. The single dense paragraph is longer than most but nearly every clause carries distinct information; the aside about the 30-day cap and board_stats could be trimmed.
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 tool with a full output schema, the description covers the important intangibles (corpus freshness, result shape, filter-fidelity disclosures, error/refusal semantics for ignored filters). It stops short of explaining pagination expectations or how to interpret intentFilters beyond naming it, but nothing critical to a correct call 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 description coverage is 100%, so the schema already documents all 24 parameters, including the nuanced ones (postedAfter vs maxAgeDays, includeUnstatedPay widening). The description adds field-level context about parsed pay and the agentReadyOnly switch, but does not supply meaning beyond what the schema already states, so the 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 names a specific verb+resource ("Search the live job board") and goes further than the title by characterizing the corpus (postings pulled directly from employers' hiring systems, 30-day freshness cap) and the return type (compact job cards). It partially differentiates from siblings by pointing at board_stats for live totals, but never distinguishes itself from the closely-named search, get_jobs, or debug_search 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?
There is one concrete usage rule — "Set agentReadyOnly=true to see only jobs the apply agent can submit to directly" — and an implied routing hint that totals live in board_stats. However, with 15 sibling tools including search and get_jobs, the description gives no explicit when-to-use/ when-not guidance against those alternatives.
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_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_jobsSearch live employer-direct job postings, company hiring signal, market stats and the change feed.
Search a live index of millions of open jobs from employer career sites and 100+ ATS platforms.
Read job postings live from employer career sites across 10 applicant tracking systems.
Open jobs and hiring changes per company, daily. Free keyless lookup. AI-compiled from job boards.
Add one secure layer between your agents and this server.
