JobsPipe

Server Details

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.

Ownership verified

Status: Healthy
Uptime: 100.0% over 69 days
Last Tested: 2026-10-25 04:37
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.1/5.0

Scored 2026-10-24 05:55 across 3 tools

Disambiguation5/5

The three tools target entirely distinct concerns: source metadata, pricing metadata, and job search. There is no realistic overlap that would cause an agent to misselect among them.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern: list_job_sources, list_pricing_plans, and search_jobs. The verbs are predictable and the nouns clearly describe the target resource.

Tool Count4/5

Three tools is a deliberately small but coherent surface for a no-key job search API. It is slightly thin because there is no separate job-detail or filter-listing tool, but each existing tool earns its place.

Completeness4/5

The surface covers the core job-search workflow plus useful context tools for sources and pricing. Minor gaps remain, such as direct job-detail retrieval and first-class pagination, though search_jobs documents the REST workaround for more results.

Available Tools

3 tools

list_job_sourcesA

Read-only

Inspect

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").

TDQS

A4.1/5.0

Behavior4/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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_pricing_plansA

Read-only

Inspect

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").

TDQS

A3.8/5.0

Behavior3/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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_jobsA

Read-only

Inspect

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 whether more match and the REST call that returns the rest (and the exact count).

Name	Required	Description
`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.

TDQS

A4.4/5.0

Behavior5/5

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

Annotations only declare readOnly and openWorld, so the description adds the substantive behavioral facts itself: the hard 3-row cap per call, that results are real live postings rather than stubs, what fields come back, and that the response includes a 'more matches' signal, the exact count, and the REST call to fetch the remainder. That is exactly the escalation path an agent needs when the cap truncates a result set.

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

Conciseness5/5

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

Two sentences: purpose and filter axes first, then what comes back and the row cap. The long second sentence is dense but each clause carries information an agent cannot get elsewhere (row cap, returned fields, continuation path). No filler.

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

Completeness4/5

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

For a 26-parameter tool with full schema coverage, no output schema and only read-only annotations, the description covers purpose, effective return shape, truncation and how to get the rest. It does not say whether filters combine with AND or OR, which matters here given the many *_or arrays.

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% with 26 documented parameters, so the schema already carries the semantics. The description only names the headline filter dimensions, which maps to but does not enrich the schema. Baseline 3 applies when the schema does the heavy lifting.

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

Purpose5/5

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

States a specific verb (Search) and resource (live, normalized job postings) plus the scope it covers: 30+ sources and the main filter axes. The sibling tools list_job_sources and list_pricing_plans are metadata utilities, so an agent can tell immediately that this is the only one that actually retrieves postings.

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

Usage Guidelines4/5

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

Gives clear usage context: it is the retrieval tool, results are capped at 3 rows on this no-key server, and the response carries the REST call that returns the rest. It does not state explicit exclusions or when another tool should be preferred, but with these siblings there is little ambiguity to resolve.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

1 tool updateSep 20, 2026
- Removedsearch_upwork_jobs

1 tool updateSep 16, 2026

Changedsearch_jobs2 fields changed

addedInput schema / properties / language_not

Added 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"
+}

addedInput schema / properties / language_or

Added 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"
+}

1 tool updateSep 16, 2026

Changedsearch_jobs2 fields changed

addedInput schema / properties / city_or

Added 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"
+}

changedInput schema / properties / job_location_or / description

Previous 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."

2 tool updatesSep 5, 2026

Changedlist_pricing_plans1 field changed

changedInput schema / properties / plan / description

Previous 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\")."

Changedsearch_jobs1 field changed

changedInput schema / properties / job_location_or / description

Previous 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."

1 tool updateSep 5, 2026

Changedsearch_jobs1 field changed

changedInput schema / properties / job_location_or / description

Previous 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)."

1 tool updateSep 4, 2026

Changedsearch_jobs1 field changed

addedInput schema / properties / include_unlabeled_employment_type

Added 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"
+}

1 tool updateAug 29, 2026

Changedsearch_jobs8 fields changed

addedInput schema / properties / benefits_or

Added value: +{
+  "description": "Match jobs advertising any of these benefit slugs, e.g. 401k, health insurance. Coverage is partial.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedInput schema / properties / esco_skill_id_or

Added value: +{
+  "description": "Match jobs tagged with any of these ESCO skill concept IDs (exact match).",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedInput schema / properties / has_recruiter_email

Added value: +{
+  "description": "true for only jobs with a recruiter contact email parsed from the posting, false for only jobs without one.",
+  "type": "boolean"
+}

addedInput schema / properties / max_applicant_count

Added 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"
+}

addedInput schema / properties / max_ghost_score

Added value: +{
+  "description": "Exclude jobs whose ghost-likelihood score (0-100) exceeds this. Unscored jobs always pass.",
+  "type": "number"
+}

addedInput schema / properties / metro_code_or

Added 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"
+}

addedInput schema / properties / min_salary_usd

Added 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"
+}

addedInput schema / properties / visa_sponsorship_or

Added 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"
+}

1 tool updateAug 12, 2026

Changedsearch_jobs1 field changed

addedInput schema / properties / region_or

Added 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"
+}

1 tool updateAug 9, 2026

Changedsearch_jobs1 field changed

addedInput schema / properties / work_arrangement_or

Added 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"
+}

1 tool updateJul 28, 2026

Changedsearch_jobs3 fields changed

addedInput schema / properties / isic_division_or

Added value: +{
+  "description": "ISIC Rev.4 employer industry divisions (2-digit, e.g. 62).",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedInput schema / properties / occupation_code_or

Added value: +{
+  "description": "ISCO-08 occupation codes; 4-digit exact, 1-3 digit as hierarchy prefix.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedInput schema / properties / skills_or

Added value: +{
+  "description": "Match jobs tagged with any of these skill slugs, e.g. python, kubernetes.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

1 tool updateJul 18, 2026

Changedsearch_jobs1 field changed

addedInput schema / properties / job_location_or

Added value: +{
+  "description": "Match any of these cities or regions, e.g. Seattle, WA.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

4 tool updatesJul 17, 2026
- Changedlist_job_sources1 field changed
  - addedInput schema / required
```
Added value: +[]
```
- Changedlist_pricing_plans1 field changed
  - addedInput schema / required
```
Added value: +[]
```
- Changedsearch_jobs1 field changed
  - changedInput schema / required
```
Previous value: -[]New value: +[
+  "job_title_or"
+]
```
- Changedsearch_upwork_jobs1 field changed
  - addedInput schema / required
```
Added value: +[]
```

Related MCP Servers

Adologyofficial
Marketing Social Media
adologyai
A
license
Not graded
quality
B
maintenance
Perplexity for social: ask what competitors are running across social and get answers grounded in real ad and creative data, not guesses.
Updated a month ago (2026-09-11 19:20 UTC)
2
Apache 2.0
Competitor Monitor AI MCP
Marketing Research & Data AI & Machine Learning
CSOAI-ORG
A
license
C
quality
B
maintenance
Competitor Monitor AI - MCP server providing AI-powered tools and automation by MEOK AI Labs
Updated 17 days ago (2026-10-08 01:01 UTC)
11
3 npm
54 PyPI
MIT
Citesurf MCP
Marketing Search Monitoring
citesurf
A
license
A
quality
C
maintenance
Enables brand visibility monitoring across major AI platforms like ChatGPT, Claude, Gemini, and Perplexity. It allows users to track visibility scores, analyze competitor data, and receive actionable insights to improve AI-generated brand recommendations.
Updated 6 months ago (2026-04-23 11:46 UTC)
16
4 npm
1
MIT
industrylens-mcpofficial
Research & Data
IndustryLensOp
A
license
Not graded
quality
B
maintenance
Browse IndustryLens's published competitive-intelligence reports and head-to-head competitor comparisons from any AI agent — real, source-backed data.
Updated 2 months ago (2026-08-17 15:55 UTC)
MIT