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 3 tools
Each tool has a clearly distinct purpose: one lists data sources, one lists pricing plans, and one searches jobs. There is no overlap or ambiguity between them.
All names use consistent snake_case with a verb_noun structure (list_job_sources, list_pricing_plans, search_jobs). The pattern is predictable and easy to parse.
Three tools is slightly minimal for a job-search service, but each tool is clearly scoped and earns its place. It is a reasonable no-key surface rather than an excessive or trivial set.
Core search is well-parameterized and returns useful fields, and source/pricing metadata is covered. However, there is no MCP tool for pagination, fetching the remaining results, or retrieving a specific job by ID, creating notable gaps for agent workflows.
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 (and the yearly price, two months free), 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 of this lookup is fully covered. The description adds the useful detail of what the payload contains (quota, features, yearly discount), but says nothing about caching, freshness of pricing, or result size. With annotations carrying the behavioral burden, 3 is appropriate.
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 well-formed sentence with zero filler, front-loading the resource and then the fields returned. The parenthetical 'two months free' is the only embellishment and it conveys real pricing semantics.
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 productively compensates by enumerating the returned fields (monthly price, yearly price, quota, features). The one remaining gap is the optional 'plan' filter, which the description ignores entirely, leaving the agent to discover filtering only from the schema.
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% — the single optional 'plan' parameter is documented in the schema with examples ('free', 'credits'). The description never references this filter, so it adds no meaning 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?
The description names a specific verb+resource (list JobsPipe pricing plans) and enumerates exactly what each plan entry contains: monthly USD price, yearly price with two months free, monthly job quota, and included features. The sibling tools (list_job_sources, search_jobs) cover unrelated domains, so there is no plausible confusion to resolve.
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?
Usage is only implied by the resource itself — an agent infers it should call this when it needs pricing/plan information. There is no explicit when-to-use statement, no mention of the optional single-plan lookup as an alternative to listing everything, and no exclusions.
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 real matching postings -- title, company, domain, location, salary range, tech stack and apply URL -- capped at 3 rows per call on this no-key server, with the total match count and the REST call that returns the rest.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum rows to return. | |
| remote | No | Only remote roles when true. | |
| city_or | No | Whole city names, e.g. London, Munich. Case-insensitive; a metro wrapper on the stored value is ignored. Spellings and diacritics are normalised for cities we know (München finds Munich, Cracow finds Kraków); other cities match the stored value exactly. | |
| 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. | |
| language_or | No | Languages the posting is written in, as lowercase ISO 639-1 codes, e.g. ["en"]. The language of the posting text, not the country: 18.3% of Swedish postings and 17.7% of German ones are in English. Unlabelled postings never match. | |
| job_title_or | Yes | Match any of these job titles. | |
| language_not | No | Exclude postings written in these languages, as lowercase ISO 639-1 codes, e.g. ["fr"]. Unlabelled postings are kept. | |
| 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. For a city by name, city_or is the precise filter. | |
| 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?
Beyond the readOnlyHint and openWorldHint annotations, the description discloses the 3-row cap per call on the no-key server, the total match count, and the REST call that returns the remaining results. It also states that results are real postings and lists the returned fields, which is valuable operational context an agent needs before invoking.
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-load the core purpose and then state the key operational limitation. Every clause earns its place: source scale, normalization, filter categories, return fields, row cap, total count, and continuation REST call.
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 26-parameter tool with no output schema, the description provides the essential return contract: fields returned, 3-row cap, total match count, and the REST call to retrieve the rest. The schema covers every parameter, and the sibling distinction is clear from names, so nothing required for correct invocation 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?
The input schema already provides full 100% per-parameter documentation, so the description correctly avoids repeating it. It adds only a high-level categorization of filter dimensions (title, skill/tech, country, remote, seniority, employment type, recency), which is useful orientation but no new semantic detail; 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?
The description opens with a specific verb ('Search') and a clearly bounded resource ('live, normalized job postings across 30+ sources'), and it lists the main filter dimensions. This is plainly distinct from the siblings list_job_sources and list_pricing_plans, so no explicit differentiation is needed.
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 clearly states what kind of query the tool serves and enumerates its filter dimensions, giving an agent the trigger conditions for use. It does not spell out explicit when-not-to-use exclusions, but the sibling tools are not competing search entry points, so the context is sufficient.
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.
search_upwork_jobssearch_jobs2 fields changedInput schema / properties / language_notAdded value: +{
+ "description": "Exclude postings written in these languages, as lowercase ISO 639-1 codes, e.g. [\"fr\"]. Unlabelled postings are kept.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Input schema / properties / language_orAdded value: +{
+ "description": "Languages the posting is written in, as lowercase ISO 639-1 codes, e.g. [\"en\"]. The language of the posting text, not the country: 18.3% of Swedish postings and 17.7% of German ones are in English. Unlabelled postings never match.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}search_jobs2 fields changedInput schema / properties / city_orAdded value: +{
+ "description": "Whole city names, e.g. London, Munich. Case-insensitive; a metro wrapper on the stored value is ignored. Spellings and diacritics are normalised for cities we know (München finds Munich, Cracow finds Kraków); other cities match the stored value exactly.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Input 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). 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."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. For a city by name, city_or is the precise filter."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: +[]
Add one secure layer between your agents and this server.