Search 4,000+ live UX & product-design jobs from jobs.uxjobs.io. Read-only, no auth.
Scored across 7 tools
Two clear duplicate pairs exist: `search` and `search_jobs` both run live keyword searches over jobs.uxjobs.io, and `fetch` and `get_job` both retrieve a single listing by the same id. The descriptions even reference each other's counterpart ('id returned from search' vs 'id returned from search_jobs'), so an agent has no principled way to choose.
Bare verbs (`search`, `fetch`), a verb_noun (`get_job`), a verb-less verb_noun (`search_jobs`), gerund phrases (`companies_hiring`) and noun phrases (`hiring_snapshot`, `salary_snapshot`) are all mixed together. All are snake_case, but the structural pattern is unpredictable.
Seven tools is a reasonable count for a niche job board, but the surface is inflated by two redundant pairs, so effectively only five distinct capabilities exist. Consolidating search/search_jobs and fetch/get_job would be the obvious fix.
The domain is well covered: search, single-listing detail, company rankings, market snapshot and salary stats. Minor gaps (no discipline/company enumeration or saved-search-like listing browsing) are workable via filters on existing tools.
Rank companies by number of open UX/product-design roles on jobs.uxjobs.io, optionally within a filter (country, remote, seniority, keywords, recency). Useful for "who is hiring the most designers in Berlin" or "which companies opened design roles this week".
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | Keywords matched against title, company, location and description, e.g. "senior product designer fintech". All words must match. | |
| remote | No | true = only fully-remote roles; false = exclude remote roles. | |
| company | No | Company name (substring match). | |
| country | No | ISO-3166 alpha-2 country code, e.g. "US", "GB", "DE". | |
| location | No | City/state/country text to match in the posted location, e.g. "London", "New York", "Germany". Use "remote" for remote roles. | |
| seniority | No | Seniority derived from the title. | |
| workplace | No | Workplace arrangement when the employer stated one. | |
| remote_from | No | Remote roles open to candidates in this region (implies remote). Roles open "Anywhere" match every region; roles that only say "Remote" with no region are not matched. Same rules as the Remote-from filter on jobs.uxjobs.io. | |
| role_family | No | Design discipline derived from the title. | |
| min_open_roles | No | Only companies with at least this many matching open roles. | |
| min_salary_usd | No | Only roles whose posted annual USD salary range reaches at least this figure. Roles that post no USD range never match, and most roles post none. | |
| employment_type | No | e.g. "Full-time", "Contract", "Part-time", "Intern". | |
| posted_within_days | No | Only roles posted in the last N days (1–60). |
| Name | Required | Description |
|---|---|---|
| companies | Yes | |
| attribution | Yes | |
| generated_at | Yes | |
| matched_roles | Yes | |
| total_companies | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds the ranking basis (companies sorted by count of open roles) and the underlying source site, but says nothing about result limits, how the ranking is paginated, or how it differs in behavior from the aggregate siblings.
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?
Two sentences, front-loaded with the core aggregation, followed by an optional-filter clause and illustrative queries. No wasted text and nothing buried.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need no explanation, and the 93% schema coverage plus annotations handle the mechanical detail. The one gap is that it never clarifies its relationship to the seemingly overlapping hiring_snapshot sibling, leaving the agent to guess which aggregate to call.
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 93%, so nearly every parameter (remote_from region rules, min_salary_usd match caveat, query word-matching) is already documented in the schema. The description's parenthetical filter list ('country, remote, seniority, keywords, recency') adds no syntax or semantics beyond what the schema supplies, 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 and resource ('Rank companies by number of open UX/product-design roles') plus the data source, which immediately separates this aggregation tool from job-listing siblings like search_jobs. The two quoted example questions make the intent 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?
Gives concrete trigger scenarios ('who is hiring the most designers in Berlin', 'which companies opened design roles this week'), which tell the agent when this tool fits. It stops short of naming when NOT to use it or pointing to a sibling such as hiring_snapshot, so no explicit alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve one job listing from jobs.uxjobs.io by the id returned from search: location, salary, apply link and a description excerpt; the listing URL has the complete text.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Listing id from search. |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| url | Yes | |
| text | Yes | |
| title | Yes | |
| metadata | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, and closed-world behavior, so the safety profile is covered. The description still adds genuine value by disclosing that the returned description is only an excerpt and that the listing URL holds the complete text, which affects how an agent should use the result.
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 tightly packed sentence front-loads the core action, then adds return contents and the full-text pointer with no wasted words. Nothing is redundant or padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read with an output schema, the description supplies everything needed: the source, the required input provenance, the returned fields, and the truncation caveat. An agent can invoke it correctly without further context.
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% with a single well-documented 'id' parameter, so the schema carries the semantics. The description's "by the id returned from search" merely restates the schema's "Listing id from search" and adds no new format or constraint detail.
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 gives a specific verb and resource (retrieve one job listing) plus concrete return contents (location, salary, apply link, description excerpt) and names the id's origin. It does not, however, differentiate itself from the sibling get_job, which an agent would have to disambiguate on its own.
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?
"by the id returned from search" states the precondition and points to the correct upstream tool, which is clear usage context. It stops short of saying when not to use it or how it relates to alternatives like get_job or search_jobs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return one job listing in detail — location, workplace, posted salary, employer apply link, and a description excerpt when the source provides one — by the id returned from search_jobs (or the jobs.uxjobs.io page slug). The listing URL has the complete text.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Job id from search_jobs, or the slug from a jobs.uxjobs.io/jobs/{slug}/ URL. |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| url | Yes | |
| logo | Yes | |
| title | Yes | |
| region | Yes | |
| remote | Yes | |
| salary | Yes | |
| source | Yes | |
| company | Yes | |
| country | Yes | |
| location | Yes | |
| apply_url | Yes | |
| posted_at | Yes | |
| seniority | Yes | |
| workplace | Yes | |
| attribution | Yes | |
| remote_from | Yes | |
| role_family | Yes | |
| employment_type | Yes | |
| open_confidence | Yes | |
| description_note | Yes | |
| description_excerpt | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely useful behavior beyond them: the excerpt is conditional ('when the source provides one') and may be incomplete, with the listing URL holding the full text.
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?
A single dense sentence with the core action and payload front-loaded. The em-dash parentheticals carry real information, though the sentence is long enough that it borders on overload.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need no explanation, yet the description still usefully flags the partial-excerpt caveat and the full-text URL. Nothing essential to invoking a one-param lookup 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% and the single parameter is fully documented there, including the slug form. The description restates the same id provenance without adding syntax or format detail, 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?
Specific verb+resource ('Return one job listing in detail') with an enumerated payload (location, workplace, salary, apply link, excerpt). It also distinguishes itself from search_jobs by naming it as the id source rather than a competing tool.
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 establishes the acquisition path — the id comes from search_jobs or a jobs.uxjobs.io page slug — which tells the agent when this tool is applicable. It stops short of an explicit when-not-to-use or a named alternative for other lookup modes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A statistical snapshot of the design job market on jobs.uxjobs.io: total open roles, roles posted in the last 7 days, remote share, and breakdowns by seniority, discipline, top countries, top cities and top hiring companies. Accepts the same optional filters as search_jobs so you can snapshot a country, a discipline or a keyword.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Keywords matched against title, company, location and description, e.g. "senior product designer fintech". All words must match. | |
| remote | No | true = only fully-remote roles; false = exclude remote roles. | |
| company | No | Company name (substring match). | |
| country | No | ISO-3166 alpha-2 country code, e.g. "US", "GB", "DE". | |
| location | No | City/state/country text to match in the posted location, e.g. "London", "New York", "Germany". Use "remote" for remote roles. | |
| seniority | No | Seniority derived from the title. | |
| workplace | No | Workplace arrangement when the employer stated one. | |
| remote_from | No | Remote roles open to candidates in this region (implies remote). Roles open "Anywhere" match every region; roles that only say "Remote" with no region are not matched. Same rules as the Remote-from filter on jobs.uxjobs.io. | |
| role_family | No | Design discipline derived from the title. | |
| min_salary_usd | No | Only roles whose posted annual USD salary range reaches at least this figure. Roles that post no USD range never match, and most roles post none. | |
| employment_type | No | e.g. "Full-time", "Contract", "Part-time", "Intern". | |
| posted_within_days | No | Only roles posted in the last N days (1–60). |
| Name | Required | Description |
|---|---|---|
| countries | Yes | |
| open_roles | Yes | |
| top_cities | Yes | |
| attribution | Yes | |
| by_seniority | Yes | |
| generated_at | Yes | |
| top_companies | Yes | |
| top_countries | Yes | |
| by_role_family | Yes | |
| companies_hiring | Yes | |
| posted_last_7_days | Yes | |
| roles_with_posted_salary | Yes | |
| remote_share_of_stated_workplace | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered by structured data. The description adds that the result is an aggregate snapshot with named breakdowns rather than a list of postings, which is genuine behavioral context not present in annotations. It omits freshness/caching or rate-limit behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero padding. The output inventory is front-loaded and the filter-model note follows, so an agent gets purpose before mechanics.
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 detail need not be in prose, and all 12 parameters are documented. The description is essentially complete for a zero-required-param analytics tool, with only minor ambiguity about the unfiltered default scope.
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% with 12 well-described parameters including four enums, so the schema carries the full parameter burden. The description adds only the cross-reference that filters mirror search_jobs, which is useful but does not extend per-parameter meaning. 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 ('statistical snapshot of the design job market') and enumerates the exact outputs (total open roles, 7-day postings, remote share, seniority/discipline/country/city/company breakdowns). This clearly distinguishes it from sibling tools like search_jobs, salary_snapshot and companies_hiring, which return different shapes.
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 it 'accepts the same optional filters as search_jobs so you can snapshot a country, a discipline or a keyword,' which tells the agent the invocation context and the filtering model. It stops short of stating when to prefer this over salary_snapshot or search_jobs, but the aggregate-vs-listing distinction is inferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Median and quartile posted salary (annual USD, from roles that state a range) by seniority level, optionally filtered by country, remote, discipline or keywords. Only roles with a posted USD range count (a minority of listings; roles_with_salary gives the number), so treat small samples with caution; the sample size is returned per level.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Keywords matched against title, company, location and description, e.g. "senior product designer fintech". All words must match. | |
| remote | No | true = only fully-remote roles; false = exclude remote roles. | |
| company | No | Company name (substring match). | |
| country | No | ISO-3166 alpha-2 country code, e.g. "US", "GB", "DE". | |
| location | No | City/state/country text to match in the posted location, e.g. "London", "New York", "Germany". Use "remote" for remote roles. | |
| seniority | No | Seniority derived from the title. | |
| workplace | No | Workplace arrangement when the employer stated one. | |
| remote_from | No | Remote roles open to candidates in this region (implies remote). Roles open "Anywhere" match every region; roles that only say "Remote" with no region are not matched. Same rules as the Remote-from filter on jobs.uxjobs.io. | |
| role_family | No | Design discipline derived from the title. | |
| min_salary_usd | No | Only roles whose posted annual USD salary range reaches at least this figure. Roles that post no USD range never match, and most roles post none. | |
| employment_type | No | e.g. "Full-time", "Contract", "Part-time", "Intern". | |
| posted_within_days | No | Only roles posted in the last N days (1–60). |
| Name | Required | Description |
|---|---|---|
| currency | Yes | |
| attribution | Yes | |
| by_seniority | Yes | |
| generated_at | Yes | |
| roles_matched | Yes | |
| roles_with_salary | Yes | |
| overall_median_mid | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description goes beyond them with substantive behavioral context: only roles posting a USD range count, that subset is a minority of listings, and sample size is returned per level. The caution about small samples is exactly the kind of interpretation guidance annotations cannot express.
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?
Two sentences, front-loaded with the metric and grouping before the caveat, with no filler. Slightly dense but every clause carries information; the parenthetical about roles_with_salary is the only marginal addition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need no elaboration, and the description still flags the key interpretive risk (sample-size bias). Combined with 100% schema coverage and full annotations, an agent has what it needs to call and read this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 12 filters including enum meanings and edge-case behavior (e.g. 'Anywhere' matching rules). The description only restates four filter axes (country, remote, discipline, keywords) and adds nothing the schema lacks, 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 output (median and quartile posted salary, annual USD) and the grouping key (seniority level), which is precise enough for an agent to know what it returns. It only weakly differentiates from siblings like hiring_snapshot; its one comparative reference ('roles_with_salary gives the number') points at a tool not in the sibling list.
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 'optionally filtered by...' clause and the small-sample caution imply when the tool is useful, but there is no explicit when-to-use/when-not statement or named alternative among the actual siblings (hiring_snapshot, search_jobs). Usage context is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Keyword search over live UX & product-design job listings on jobs.uxjobs.io. Returns up to 20 results with id, title and URL; pass an id to fetch for the full listing. Natural-language queries work: "remote senior product designer fintech", "UX researcher London".
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query. |
| Name | Required | Description |
|---|---|---|
| results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description still adds genuinely new behavior: a hard cap of 20 results and that the response is a lightweight projection (id, title, URL) rather than full listings. It says nothing about pagination or ordering, which is a modest remaining gap.
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?
Two sentences plus examples; scope, return shape, and the next-step handoff are all front-loaded with no filler. Every clause earns its place.
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 and annotations covering safety, the description covers only what the agent still needs: result cap, returned fields, and the fetch handoff. The one real omission is disambiguation from the search_jobs sibling, which matters given the overlapping names.
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% but the schema only says "Search query." The description compensates by showing that natural-language free-text queries are supported, with two concrete phrasings ("remote senior product designer fintech", "UX researcher London"). Those examples teach query style rather than merely restating the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (search), resource (UX & product-design job listings), and the source domain jobs.uxjobs.io, which is concrete and identifiable. It does not, however, differentiate itself from the sibling search_jobs, leaving the agent to guess which search tool is intended when both are present.
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?
"pass an id to fetch for the full listing" explicitly routes the agent onward to the fetch sibling once an id is obtained. What is missing is a condition distinguishing this tool from search_jobs, so the when-to-use guidance is clear for the fetch handoff but silent on the more dangerous ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search live UX, product-design, UX-research, content-design and design-leadership roles on jobs.uxjobs.io. Filter by keywords, location/country, remote, seniority, discipline, company, posted salary and recency. Returns a page of compact results (newest first, keyword relevance when a query is given) plus the total match count.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Results per page (1–50). | |
| query | No | Keywords matched against title, company, location and description, e.g. "senior product designer fintech". All words must match. | |
| offset | No | Skip this many results (for paging). | |
| remote | No | true = only fully-remote roles; false = exclude remote roles. | |
| company | No | Company name (substring match). | |
| country | No | ISO-3166 alpha-2 country code, e.g. "US", "GB", "DE". | |
| location | No | City/state/country text to match in the posted location, e.g. "London", "New York", "Germany". Use "remote" for remote roles. | |
| seniority | No | Seniority derived from the title. | |
| workplace | No | Workplace arrangement when the employer stated one. | |
| remote_from | No | Remote roles open to candidates in this region (implies remote). Roles open "Anywhere" match every region; roles that only say "Remote" with no region are not matched. Same rules as the Remote-from filter on jobs.uxjobs.io. | |
| role_family | No | Design discipline derived from the title. | |
| min_salary_usd | No | Only roles whose posted annual USD salary range reaches at least this figure. Roles that post no USD range never match, and most roles post none. | |
| employment_type | No | e.g. "Full-time", "Contract", "Part-time", "Intern". | |
| posted_within_days | No | Only roles posted in the last N days (1–60). |
| Name | Required | Description |
|---|---|---|
| total | Yes | |
| offset | Yes | |
| results | Yes | |
| returned | Yes | |
| attribution | Yes | |
| generated_at | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: result ordering (newest first, keyword relevance when a query is given) and that a total match count is returned. It does not mention rate limits or auth needs, but the added ordering semantics are meaningful.
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, zero filler: purpose/filters first, return shape second. Every clause carries information and the scoping constraint is front-loaded.
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 full output schema present and 100% schema description coverage, the description need not re-explain return fields. It covers source, filter surface, ordering and pagination framing, leaving nothing an agent needs in order to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter including the subtle `remote_from` semantics and the salary-match caveat is already documented in the schema. The description only restates the filter categories at a high level, adding no syntax or format detail beyond the schema. 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 (Search) plus resource (live UX/product-design roles on jobs.uxjobs.io) and enumerates the disciplines covered. This clearly distinguishes it from the generic sibling `search` and from single-record `get_job`.
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 lists available filters, which implies usage, but never says when to prefer this over sibling `search` or how to follow up with `get_job`. No exclusions or prerequisites are stated, leaving routing to inference.
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.
companies_hiring2 fields changedInput schema / properties / min_salary_usd / descriptionPrevious value: -"Only roles whose posted annual USD salary range reaches at least this figure. Only ~8% of roles post salary."New value: +"Only roles whose posted annual USD salary range reaches at least this figure. Roles that post no USD range never match, and most roles post none."Input schema / properties / remote_fromAdded value: +{
+ "description": "Remote roles open to candidates in this region (implies remote). Roles open \"Anywhere\" match every region; roles that only say \"Remote\" with no region are not matched. Same rules as the Remote-from filter on jobs.uxjobs.io.",
+ "enum": [
+ "Anywhere",
+ "Latin America",
+ "US & Canada",
+ "Europe, Middle East & Africa",
+ "Asia-Pacific"
+ ],
+ "type": "string"
+}get_job2 fields changedOutput schema / properties / remote_fromAdded value: +{
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Output schema / requiredPrevious value: -[
- "id",
- "title",
- "company",
- "location",
- "country",
- "remote",
- "workplace",
- "seniority",
- "salary",
- "employment_type",
- "posted_at",
- "url",
- "role_family",
- "region",
- "source",
- "open_confidence",
- "logo",
- "apply_url",
- "description_excerpt",
- "description_note",
- "attribution"
-]New value: +[
+ "id",
+ "title",
+ "company",
+ "location",
+ "country",
+ "remote",
+ "remote_from",
+ "workplace",
+ "seniority",
+ "salary",
+ "employment_type",
+ "posted_at",
+ "url",
+ "role_family",
+ "region",
+ "source",
+ "open_confidence",
+ "logo",
+ "apply_url",
+ "description_excerpt",
+ "description_note",
+ "attribution"
+]hiring_snapshot2 fields changedInput schema / properties / min_salary_usd / descriptionPrevious value: -"Only roles whose posted annual USD salary range reaches at least this figure. Only ~8% of roles post salary."New value: +"Only roles whose posted annual USD salary range reaches at least this figure. Roles that post no USD range never match, and most roles post none."Input schema / properties / remote_fromAdded value: +{
+ "description": "Remote roles open to candidates in this region (implies remote). Roles open \"Anywhere\" match every region; roles that only say \"Remote\" with no region are not matched. Same rules as the Remote-from filter on jobs.uxjobs.io.",
+ "enum": [
+ "Anywhere",
+ "Latin America",
+ "US & Canada",
+ "Europe, Middle East & Africa",
+ "Asia-Pacific"
+ ],
+ "type": "string"
+}salary_snapshot2 fields changedInput schema / properties / min_salary_usd / descriptionPrevious value: -"Only roles whose posted annual USD salary range reaches at least this figure. Only ~8% of roles post salary."New value: +"Only roles whose posted annual USD salary range reaches at least this figure. Roles that post no USD range never match, and most roles post none."Input schema / properties / remote_fromAdded value: +{
+ "description": "Remote roles open to candidates in this region (implies remote). Roles open \"Anywhere\" match every region; roles that only say \"Remote\" with no region are not matched. Same rules as the Remote-from filter on jobs.uxjobs.io.",
+ "enum": [
+ "Anywhere",
+ "Latin America",
+ "US & Canada",
+ "Europe, Middle East & Africa",
+ "Asia-Pacific"
+ ],
+ "type": "string"
+}search_jobs4 fields changedInput schema / properties / min_salary_usd / descriptionPrevious value: -"Only roles whose posted annual USD salary range reaches at least this figure. Only ~8% of roles post salary."New value: +"Only roles whose posted annual USD salary range reaches at least this figure. Roles that post no USD range never match, and most roles post none."Input schema / properties / remote_fromAdded value: +{
+ "description": "Remote roles open to candidates in this region (implies remote). Roles open \"Anywhere\" match every region; roles that only say \"Remote\" with no region are not matched. Same rules as the Remote-from filter on jobs.uxjobs.io.",
+ "enum": [
+ "Anywhere",
+ "Latin America",
+ "US & Canada",
+ "Europe, Middle East & Africa",
+ "Asia-Pacific"
+ ],
+ "type": "string"
+}Output schema / properties / results / items / properties / remote_fromAdded value: +{
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Output schema / properties / results / items / requiredPrevious value: -[
- "id",
- "title",
- "company",
- "location",
- "country",
- "remote",
- "workplace",
- "seniority",
- "salary",
- "employment_type",
- "posted_at",
- "url"
-]New value: +[
+ "id",
+ "title",
+ "company",
+ "location",
+ "country",
+ "remote",
+ "remote_from",
+ "workplace",
+ "seniority",
+ "salary",
+ "employment_type",
+ "posted_at",
+ "url"
+]get_job1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "apply_url": {
+ "type": "string"
+ },
+ "attribution": {
+ "type": "string"
+ },
+ "company": {
+ "type": "string"
+ },
+ "country": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "description_excerpt": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "description_note": {
+ "type": "string"
+ },
+ "employment_type": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "id": {
+ "type": "string"
+ },
+ "location": {
+ "type": "string"
+ },
+ "logo": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "open_confidence": {
+ "anyOf": [
+ {
+ "enum": [
+ "verified",
+ "unverified"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "posted_at": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "region": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "remote": {
+ "type": "boolean"
+ },
+ "role_family": {
+ "type": "string"
+ },
+ "salary": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "seniority": {
+ "enum": [
+ "Junior / Entry",
+ "Mid-level",
+ "Senior",
+ "Lead / Staff",
+ "Principal",
+ "Director+"
+ ],
+ "type": "string"
+ },
+ "source": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "title": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ },
+ "workplace": {
+ "anyOf": [
+ {
+ "enum": [
+ "remote",
+ "hybrid",
+ "onsite"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "required": [
+ "id",
+ "title",
+ "company",
+ "location",
+ "country",
+ "remote",
+ "workplace",
+ "seniority",
+ "salary",
+ "employment_type",
+ "posted_at",
+ "url",
+ "role_family",
+ "region",
+ "source",
+ "open_confidence",
+ "logo",
+ "apply_url",
+ "description_excerpt",
+ "description_note",
+ "attribution"
+ ],
+ "type": "object"
+}hiring_snapshot1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": false,
+ "properties": {
+ "attribution": {
+ "type": "string"
+ },
+ "by_role_family": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "count": {
+ "type": "number"
+ },
+ "name": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "name",
+ "count"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "by_seniority": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "count": {
+ "type": "number"
+ },
+ "seniority": {
+ "enum": [
+ "Junior / Entry",
+ "Mid-level",
+ "Senior",
+ "Lead / Staff",
+ "Principal",
+ "Director+"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "seniority",
+ "count"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "companies_hiring": {
+ "type": "number"
+ },
+ "countries": {
+ "type": "number"
+ },
+ "generated_at": {
+ "type": "string"
+ },
+ "open_roles": {
+ "type": "number"
+ },
+ "posted_last_7_days": {
+ "type": "number"
+ },
+ "remote_share_of_stated_workplace": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "roles_with_posted_salary": {
+ "type": "number"
+ },
+ "top_cities": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "count": {
+ "type": "number"
+ },
+ "name": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "name",
+ "count"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "top_companies": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "count": {
+ "type": "number"
+ },
+ "name": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "name",
+ "count"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "top_countries": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "count": {
+ "type": "number"
+ },
+ "name": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "name",
+ "count"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "generated_at",
+ "open_roles",
+ "posted_last_7_days",
+ "remote_share_of_stated_workplace",
+ "roles_with_posted_salary",
+ "companies_hiring",
+ "countries",
+ "by_seniority",
+ "by_role_family",
+ "top_countries",
+ "top_cities",
+ "top_companies",
+ "attribution"
+ ],
+ "type": "object"
+}companies_hiringfetchget_jobhiring_snapshotsalary_snapshotsearchsearch_jobsLive job postings from company career pages on Greenhouse, Lever, Ashby and SmartRecruiters.
Semantic search over 3.5M+ live US job postings pulled straight from company ATSes. Read-only.
Search current startup jobs and hiring companies through RocketList's public read-only data.
Search ~1.4M open jobs from 24k company career boards: Greenhouse, Lever, Ashby, Workday and more
Add one secure layer between your agents and this server.
