Live job postings for AI agents: search normalized postings from 30+ ATS feeds and job boards by title, skill, country, remote, seniority and recency. Also lists sources and pricing plans.
Scored across 4 tools
list_job_sources and list_pricing_plans are clearly separate metadata tools, and search_upwork_jobs is explicitly scoped to Upwork. The only possible boundary issue is that search_jobs may also cover Upwork through its 30+ sources, but the dedicated Upwork tool has a clearly specialized purpose.
All tool names follow a consistent lower_snake_case verb_noun pattern: list_job_sources, list_pricing_plans, search_jobs, search_upwork_jobs. The verb choice is uniform and the object naming is predictable.
Four tools is a reasonable size for a focused job-data API server, but the set feels slightly thin because two tools are metadata-oriented and only two are search-oriented. Every tool has a clear role, but the overall functional surface is narrow.
The set covers source discovery and two search paths, but search_jobs returns guidance for calling an external REST API rather than clearly returning job results, and there is no tool for retrieving a single job posting or handling pagination. This creates a notable gap between searching and actually accessing job details.
List the ATS and job-board sources JobsPipe normalizes into a single JSON schema, with coverage and freshness notes.
| Name | Required | Description | Default |
|---|---|---|---|
| name_contains | No | Optional case-insensitive substring to filter sources by name (e.g. "workday"). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and non-destructive behavior. The description adds context about normalizing into a single JSON schema and including coverage/freshness notes, which goes beyond the annotations without contradicting them.
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 sentence that is front-loaded and contains no waste. Every word adds value.
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 simple listing tool with no required parameters, no output schema, and good annotations, the description fully covers its behavior and return values. It mentions the key output aspects (sources, coverage, freshness), making it complete.
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%, with the single optional parameter already well-documented in the schema. The tool description does not repeat or add to parameter semantics, which is acceptable given high schema coverage.
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 ('List') and resource ('ATS and job-board sources JobsPipe normalizes'), including details about output ('coverage and freshness notes'). It clearly distinguishes from sibling tools like search_jobs and search_upwork_jobs.
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 the tool is for listing sources, but does not explicitly state when to use it versus alternatives like search_jobs or list_pricing_plans. No when-not or explicit usage context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List JobsPipe pricing plans with monthly price in USD, monthly job quota and included features.
| Name | Required | Description | Default |
|---|---|---|---|
| plan | No | Optional plan name to return just one plan (e.g. "free", "credits"). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds what fields are returned (price, quota, features), but it does not disclose potential behaviors like response ordering, pagination, or the effect of omitting the optional plan filter. Credit is given for the field detail, but it is modest beyond the 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?
The description is a single, tightly worded sentence with no wasted words. It front-loads the verb and resource, then specifies the key return attributes efficiently.
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 simple list operation with one optional parameter and a safe read-only annotation, the description is complete. It states what is returned, the schema explains the filter, and the annotations cover safety. No output schema exists, but the description already lists the main return fields.
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 fully documents the optional 'plan' parameter. The tool description adds no additional meaning about the parameter, so the baseline of 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?
The description states a specific verb and resource: 'List JobsPipe pricing plans' with the exact data points returned (monthly price, job quota, features). It clearly distinguishes itself from sibling tools like list_job_sources and search_jobs, which deal with different entities.
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 usage context is implied by the tool's purpose—it is the obvious choice for pricing plan inquiries—but there is no explicit guidance about when to use it versus alternatives or any exclusions. No sibling tool is mentioned as a fallback or contrast.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search live, normalized job postings across 30+ sources by title, skill/tech, country, remote, seniority, employment type and recency. Returns guidance for calling the authenticated REST API that runs the query.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum rows to return. | |
| remote | No | Only remote roles when true. | |
| region_or | No | US states and Canadian provinces as ISO 3166-2 codes, e.g. US-NY, CA-ON. Matches every spelling a job board publishes, so CA-ON finds both ON and Ontario. More precise than job_location_or for a state or province. | |
| skills_or | No | Match jobs tagged with any of these skill slugs, e.g. python, kubernetes. | |
| benefits_or | No | Match jobs advertising any of these benefit slugs, e.g. 401k, health insurance. Coverage is partial. | |
| job_title_or | Yes | Match any of these job titles. | |
| metro_code_or | No | Match any of these US CBSA metro codes, e.g. 35620 for New York. Non-US jobs never match. | |
| description_or | No | Match any of these skills or technologies in the posting. | |
| min_salary_usd | No | Only jobs whose posted salary reaches this annual USD amount. Jobs without a posted salary never match; estimated salaries are not consulted. | |
| job_location_or | No | Match any of these cities or regions, e.g. Seattle, WA. Metro wrappers are stripped (Greater London also matches London) and a state, province or UK nation by name matches every spelling of it (Pennsylvania also matches PA). Terms of three characters or fewer are codes or exact names and match whole values (WA is Washington state, never Iowa); a country code or name matches the whole country. | |
| max_ghost_score | No | Exclude jobs whose ghost-likelihood score (0-100) exceeds this. Unscored jobs always pass. | |
| esco_skill_id_or | No | Match jobs tagged with any of these ESCO skill concept IDs (exact match). | |
| isic_division_or | No | ISIC Rev.4 employer industry divisions (2-digit, e.g. 62). | |
| job_seniority_or | No | Match any of these seniority levels. | |
| employment_type_or | No | Match any of these employment types. | |
| occupation_code_or | No | ISCO-08 occupation codes; 4-digit exact, 1-3 digit as hierarchy prefix. | |
| has_recruiter_email | No | true for only jobs with a recruiter contact email parsed from the posting, false for only jobs without one. | |
| job_country_code_or | No | Match any of these ISO 3166-1 alpha-2 country codes. | |
| max_applicant_count | No | Only jobs with at most this many applicants. Counts exist only where the source exposes them (LinkedIn), so this also drops every job without a count. | |
| visa_sponsorship_or | No | Match any of these visa stances parsed from the posting text: offers, no, citizenship_required. Jobs that say nothing never match. | |
| work_arrangement_or | No | Match any of remote, hybrid or onsite. Finer than remote, which answers false for hybrid and onsite alike. Jobs whose arrangement is unknown never match, and coverage is still backfilling, so this returns far fewer results than expected today; remote is the reliable filter for now. | |
| posted_at_max_age_days | No | Only postings published within this many days. | |
| include_unlabeled_employment_type | No | Also return jobs whose employment type is unknown. About 27% of postings do not state one, and employment_type_or excludes every one of them by default. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds meaningful behavioral context beyond the annotations: the tool returns 'guidance for calling the authenticated REST API' rather than simply raw job postings, and it signals that live, normalized data across sources is involved. It does not contradict the 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?
The description is two sentences with no filler. It front-loads the core action and resource, enumerates filter dimensions efficiently, and ends with the important output behavior. Every sentence contributes useful context without redundancy.
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 no output schema, the description must explain the return value, but it only vaguely says 'Returns guidance for calling the authenticated REST API' without describing the format, contents, pagination, or authentication mechanics. It also does not address how this tool relates to search_upwork_jobs. The rich parameter schema compensates for filter semantics, but the overall invocation and result picture is incomplete for an agent.
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 input schema already documents all 23 parameters in detail. The description's filter list ('title, skill/tech, country, remote, seniority, employment type and recency') summarizes the parameter groups but adds no new semantic meaning beyond the schema. A baseline of 3 is appropriate because the schema carries the parameter-documentation burden.
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 and resource: searching live, normalized job postings across 30+ sources by a long list of filters. It is clearly distinct from the list_* sibling tools, though it does not explicitly differentiate itself from search_upwork_jobs. The phrase 'Returns guidance for calling the authenticated REST API' introduces some ambiguity about whether the tool returns postings or instructions.
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 this is the general multi-source job search tool, but it never states when to prefer it over search_upwork_jobs or when not to use it. No explicit exclusions, alternatives, or prerequisite context are provided. An agent must infer the appropriate choice from the name and the '30+ sources' phrase.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search live Upwork job postings ingested by JobsPipe. Returns normalized rows with budget, skills and client signals.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | ||
| limit | No | Maximum rows to return (1-200, default 25). | |
| order | No | ||
| offset | No | Pagination offset. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, non-destructive, and open-world. The description adds value by specifying inputs (parameter mentions in schema but not description), outputs (normalized rows with budget, skills, client signals), and data freshness (live, ingested by JobsPipe). The description does not contradict 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?
The description consists of two front-loaded sentences with no wasted words. It efficiently conveys the core purpose and key output characteristics.
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 no output schema and four parameters (all optional), the description gives a general idea of the output but lacks details about default behaviors, sorting/ordering mechanics, and full response structure. Adequate but not comprehensive.
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 50% (only 'limit' and 'offset' have descriptions). The tool's description does not mention any parameters or provide additional meaning beyond the schema. Since half of parameters lack documentation and the description offers no compensation, the semantic value is low.
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 the verb 'search', the resource 'live Upwork job postings', and gives specifics about the data source and returned fields (budget, skills, client signals). This distinguishes it from siblings like 'search_jobs' and 'list_job_sources'.
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 usage for Upwork-specific job searches with certain data, but does not explicitly state when to use this tool versus alternatives or provide any exclusions. The context signals mention sibling tools, but they are not referenced in the description.
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.
list_pricing_plans1 field changedInput schema / properties / plan / descriptionPrevious value: -"Optional plan name to return just one plan (e.g. \"free\", \"builder\", \"scale\")."New value: +"Optional plan name to return just one plan (e.g. \"free\", \"credits\")."search_jobs1 field changedInput schema / properties / job_location_or / descriptionPrevious value: -"Match any of these cities or regions, e.g. Seattle, WA. Metro wrappers are stripped (Greater London also matches London) and a state, province or UK nation by name matches every spelling of it (Pennsylvania also matches PA)."New value: +"Match any of these cities or regions, e.g. Seattle, WA. Metro wrappers are stripped (Greater London also matches London) and a state, province or UK nation by name matches every spelling of it (Pennsylvania also matches PA). Terms of three characters or fewer are codes or exact names and match whole values (WA is Washington state, never Iowa); a country code or name matches the whole country."search_jobs1 field changedInput schema / properties / job_location_or / descriptionPrevious value: -"Match any of these cities or regions, e.g. Seattle, WA."New value: +"Match any of these cities or regions, e.g. Seattle, WA. Metro wrappers are stripped (Greater London also matches London) and a state, province or UK nation by name matches every spelling of it (Pennsylvania also matches PA)."search_jobs1 field changedInput schema / properties / include_unlabeled_employment_typeAdded value: +{
+ "description": "Also return jobs whose employment type is unknown. About 27% of postings do not state one, and employment_type_or excludes every one of them by default.",
+ "type": "boolean"
+}search_jobs8 fields changedInput schema / properties / benefits_orAdded value: +{
+ "description": "Match jobs advertising any of these benefit slugs, e.g. 401k, health insurance. Coverage is partial.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Input schema / properties / esco_skill_id_orAdded value: +{
+ "description": "Match jobs tagged with any of these ESCO skill concept IDs (exact match).",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Input schema / properties / has_recruiter_emailAdded value: +{
+ "description": "true for only jobs with a recruiter contact email parsed from the posting, false for only jobs without one.",
+ "type": "boolean"
+}Input schema / properties / max_applicant_countAdded value: +{
+ "description": "Only jobs with at most this many applicants. Counts exist only where the source exposes them (LinkedIn), so this also drops every job without a count.",
+ "type": "number"
+}Input schema / properties / max_ghost_scoreAdded value: +{
+ "description": "Exclude jobs whose ghost-likelihood score (0-100) exceeds this. Unscored jobs always pass.",
+ "type": "number"
+}Input schema / properties / metro_code_orAdded value: +{
+ "description": "Match any of these US CBSA metro codes, e.g. 35620 for New York. Non-US jobs never match.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Input schema / properties / min_salary_usdAdded value: +{
+ "description": "Only jobs whose posted salary reaches this annual USD amount. Jobs without a posted salary never match; estimated salaries are not consulted.",
+ "type": "number"
+}Input schema / properties / visa_sponsorship_orAdded value: +{
+ "description": "Match any of these visa stances parsed from the posting text: offers, no, citizenship_required. Jobs that say nothing never match.",
+ "items": {
+ "enum": [
+ "offers",
+ "no",
+ "citizenship_required"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+}search_jobs1 field changedInput schema / properties / region_orAdded value: +{
+ "description": "US states and Canadian provinces as ISO 3166-2 codes, e.g. US-NY, CA-ON. Matches every spelling a job board publishes, so CA-ON finds both ON and Ontario. More precise than job_location_or for a state or province.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}search_jobs1 field changedInput schema / properties / work_arrangement_orAdded value: +{
+ "description": "Match any of remote, hybrid or onsite. Finer than remote, which answers false for hybrid and onsite alike. Jobs whose arrangement is unknown never match, and coverage is still backfilling, so this returns far fewer results than expected today; remote is the reliable filter for now.",
+ "items": {
+ "enum": [
+ "remote",
+ "hybrid",
+ "onsite"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+}search_jobs3 fields changedInput schema / properties / isic_division_orAdded value: +{
+ "description": "ISIC Rev.4 employer industry divisions (2-digit, e.g. 62).",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Input schema / properties / occupation_code_orAdded value: +{
+ "description": "ISCO-08 occupation codes; 4-digit exact, 1-3 digit as hierarchy prefix.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Input schema / properties / skills_orAdded value: +{
+ "description": "Match jobs tagged with any of these skill slugs, e.g. python, kubernetes.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}search_jobs1 field changedInput schema / properties / job_location_orAdded value: +{
+ "description": "Match any of these cities or regions, e.g. Seattle, WA.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}list_job_sources1 field changedInput schema / requiredAdded value: +[]list_pricing_plans1 field changedInput schema / requiredAdded value: +[]search_jobs1 field changedInput schema / requiredPrevious value: -[]New value: +[
+ "job_title_or"
+]search_upwork_jobs1 field changedInput schema / requiredAdded value: +[]list_job_sourceslist_pricing_planssearch_jobssearch_upwork_jobs
