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.
`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 that state a salary (excludes the ~87% that don't).
`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.

First observedSep 18, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, but the description adds valuable behavioral context beyond those hints: it details what the response covers (route, timings, count basis, fallback, ignoredFilters) and adds an authentication requirement ('Needs a key or a sign-in') that is not in the annotations. This is rich, non-redundant disclosure.

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

Conciseness4/5

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

The description is a few sentences, front-loaded with the core purpose and usage, then detailing outputs and constraints. It is longer than minimal but each clause adds necessary context for a diagnostic tool of this complexity. No redundancy or filler; structure is logical and scannable.

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

Completeness5/5

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

Given the tool's complexity (24 parameters), the presence of an output schema, and rich annotations, the description is complete. It covers purpose, usage triggers, output highlights, and the auth requirement. It does not repeat return-value details (handled by the output schema) and leaves no critical question unanswered for an agent deciding or invoking.

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%, so the schema already documents all 24 parameters thoroughly. The description only references 'same arguments as search_jobs' and does not add parameter-level meaning. Per the rubric, a baseline of 3 is appropriate when the schema carries full weight; the description neither improves nor worsens parameter clarity.

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

Purpose5/5

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

The description opens with a clear verb and resource: 'Explain WHY a search returns what it does' and then enumerates the specific diagnostic outputs (parsed query, applied/ignored filters, route, rankings, timings). It also names the sibling it is not by referencing search_jobs, so an agent can immediately distinguish the tool's scope.

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

Usage Guidelines5/5

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

It explicitly states when to reach for this tool: 'Use this when a search returns surprising, empty, or mis-ranked results.' It also notes that it takes the same arguments as search_jobs, giving the agent a clear alternative and a precise trigger condition. No inference is needed.

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.