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

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, smartrecruiters — Two hiring systems are shown on resumebooster.work but not handed on by this connector: the U.S. federal job feed, whose terms of use forbid redistributing it as a data feed, and SmartRecruiters, withheld until SmartRecruiters (SAP) permits it. No tool here returns their rows; open the posting on the site instead. Naming one is refused rather than answered with an empty page.
`country`	No	ISO-2 codes, comma-separated, max 5. E.g. 'US,GB'.
`category`	No	Comma list of category slugs (see board_stats for the live set), max 3.
`location`	No	City/state/metro, e.g. 'texas', 'NYC', 'berlin'.
`maxYears`	No	Only roles asking for at most N years of experience.
`payBasis`	No	Restrict to hourly or salaried pay.
`workMode`	No	Comma list of: remote, hybrid, onsite.
`companies`	No	Scope to specific employers: a comma list of companyToken values from job cards (or from the site's employer pages). An employer the board does not carry simply matches nothing; tokens the board drops are named in ignoredFilters.
`salaryMax`	No	Annual USD-equivalent salary ceiling.
`salaryMin`	No	Annual USD-equivalent salary floor. Many postings state no comparable pay; the response's filterCoverage gives the live share this floor can see, dated by filterCoverageAt.
`department`	No	Substring match on the employer's own department/team text.
`experience`	No	Comma list of seniority bands the POSTING asks for: entry, mid, senior, expert. Rows whose band could not be read are excluded — use maxYears for the candidate's own side of the question.
`maxAgeDays`	No	Only postings from the last N days (1-30).
`postedAfter`	No	ISO-8601 instant; only postings the EMPLOYER dated after it. Undated rows fall out of this window (unlike maxAgeDays, which falls back to when the board first saw a posting), so this is the strict form of 'new'.
`hasStatedPay`	No	Only postings whose pay field carries a figure the employer published — hourly and per-shift rates included, read from the `salary` field. The response's filterCoverage gives the live share. Narrower than it sounds only for RANKING: salaryFloor compares an annualised figure in approximate US dollars, which fewer postings carry, so some rows this returns cannot be filtered by pay amount.
`agentReadyOnly`	No	Only jobs the apply agent can submit to on the user's behalf.
`employmentType`	No	Comma list of: full_time, part_time, contract, temporary, internship.
`excludeAgencies`	No	Hide postings from staffing/recruiting agencies (their job cards carry agency:true). Agencies are served by default; this is an opt-in narrowing.
`includeUnstatedPay`	No	WIDENS an active salaryMin/salaryMax band to also admit postings that state no pay at all. Inert with no band set (unpriced rows are already included). The response says salaryStatedOnly when a band is narrowing without it.

Output 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.

Changed8 schema fields changedOct 11, 2026

changedInput schema / properties / hasStatedPay / description

Previous value: -"Only postings whose pay field carries a figure the employer published — hourly and per-shift rates included, read from the `salary` field. About 28% of the board (2026-09-27). Narrower than it sounds only for RANKING: salaryFloor compares an annualised figure in approximate US dollars, which about 24% carry, so some rows this returns cannot be filtered by pay amount."New value: +"Only postings whose pay field carries a figure the employer published — hourly and per-shift rates included, read from the `salary` field. The response's filterCoverage gives the live share. Narrower than it sounds only for RANKING: salaryFloor compares an annualised figure in approximate US dollars, which fewer postings carry, so some rows this returns cannot be filtered by pay amount."

changedInput schema / properties / salaryMin / description

Previous value: -"Annual USD-equivalent salary floor. Note: only ~13% of postings state pay."New value: +"Annual USD-equivalent salary floor. Many postings state no comparable pay; the response's filterCoverage gives the live share this floor can see, dated by filterCoverageAt."

changedInput schema / properties / vendor / description

Previous value: -"Comma list of hiring-system vendors (greenhouse, lever, ashby, …), max 8. Not available here: usajobs — The U.S. federal job feed is readable on resumebooster.work but may not be redistributed as a data feed under its terms of use, so no tool here returns its rows. Naming one is refused rather than answered with an empty page."New value: +"Comma list of hiring-system vendors (greenhouse, lever, ashby, …), max 8. Not available here: usajobs, smartrecruiters — Two hiring systems are shown on resumebooster.work but not handed on by this connector: the U.S. federal job feed, whose terms of use forbid redistributing it as a data feed, and SmartRecruiters, withheld until SmartRecruiters (SAP) permits it. No tool here returns their rows; open the posting on the site instead. Naming one is refused rather than answered with an empty page."

addedOutput schema / properties / outcome / properties / filterCoverage

Added value: +{
+  "additionalProperties": {
+    "type": "number"
+  },
+  "description": "For each filter applied, the live share (0-1) of the board that states the field it filters on; rows that state nothing are excluded.",
+  "type": "object"
+}

addedOutput schema / properties / outcome / properties / filterCoverageAt

Added value: +{
+  "description": "When filterCoverage was measured. ABSENT when a figure is a pinned fallback rather than a live reading.",
+  "type": "string"
+}

addedOutput schema / properties / outcome / properties / relatedCapped

Added value: +{
+  "description": "relatedTotal stopped counting at the board's cap; the true figure is higher.",
+  "type": "boolean"
+}

addedOutput schema / properties / outcome / properties / relatedTotal

Added value: +{
+  "description": "Further postings matched in the description only, beyond `total` (which counts title matches). Each card says which in matchScope.",
+  "type": "integer"
+}

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

Previous value: -"Row-selecting: this page excludes the ~76% of postings with no annualised figure in approximate US dollars (2026-09-27), including postings that publish an hourly rate."New value: +"Row-selecting: this page excludes the postings with no annualised figure in approximate US dollars, including postings that publish an hourly rate (filterCoverage, when present, gives the live share)."

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 safety profile (readOnly, idempotent, non-destructive, openWorld). The description adds real behavior beyond that: it is read-only introspection and it 'Needs a key or a sign-in', an auth prerequisite not in the annotations. It also details the returned diagnostic content (fallback presence, count basis, seam). Lacks rate-limit or cost notes, but that is minor.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the purpose, then the payload contents, then the trigger condition, then the argument/auth note — a logical order with no filler. It is dense and longer than average, but each clause (ignored filters, ranking regime, fallback) carries distinct diagnostic meaning rather than padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 24-parameter read-only diagnostic tool with a full output schema and complete annotation coverage, the description is nearly complete: it explains the diagnostic scope, the auth requirement, and the argument contract. Since an output schema exists it need not enumerate return values, so nothing essential is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 24 parameters at 100% description coverage, so the schema already carries the per-parameter meaning and baseline is 3. The description only adds a cross-reference ('takes the SAME arguments as search_jobs'), which is useful routing but adds no new semantics for any individual parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (explain) and resource (a search), and enumerates exactly what the explanation contains: parsed query, applied vs IGNORED filters, route/retriever, ranking regime, timings, fallback. It also distinguishes itself from the sibling search_jobs by noting it takes the same arguments, so an agent can tell it is the diagnostic twin rather than another search.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a clear trigger — 'when a search returns surprising, empty, or mis-ranked results — it turns why? into one call' — and points to search_jobs for the argument set. It stops short of explicitly naming when NOT to use it (e.g. routine searching), so it is strong but not fully explicit about exclusions.

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

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.