Resume Booster Job Board

Explain a search

debug_search

Read-onlyIdempotent

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.

Input Schema

TableJSON Schema

Name	Required	Description
`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.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`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.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 27, 2026

changedInput schema / properties / hasStatedPay / description

Previous 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."

changedOutput schema / properties / outcome / properties / salaryStatedOnly / description

Previous 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."

Changed1 schema field changedSep 25, 2026

changedInput schema / properties / vendor / description

Previous 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."

First observedSep 18, 2026

TDQS

A4.1/5.0

Behavior4/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

All Resume Booster Job Board tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.