You can use this server to search, count, analyze filter values, and generate RSS feeds for Techmap's global job postings data.
Search job postings with filters (country, title, occupation, skills, company, city, workplace, contract/work type, language, industry, date, salary, direct-employer/recruiter flags) and pagination/sorting.
Count job postings matching the same filters for labour market questions.
List common filter values (e.g., work place, industry, occupation, skills, company, city) with posting counts from the last 30 days (PRO plan or higher).
Build filtered RSS feed URLs for job board backfill, with a RapidAPI key placeholder.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Techmap Job Postings MCP Server Find remote Python developer jobs posted in Germany this week"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that gives AI assistants and agents access to Techmap's job postings data: about 8 million new postings per month from 185 sources (company career pages and ATS platforms, job boards, aggregators and public employment offices) in 250 countries and territories, with history since 2020.
Use it to ask things like:
"Find remote Python developer jobs posted in Germany this week."
"How many nursing jobs were posted in Austria in September?"
"Which companies in Luxembourg are hiring controllers?"
"Build an RSS feed URL for hybrid marketing jobs in the Netherlands for my job board."
Tool | What it does | API requests |
| Search postings by country, title, occupation, skills, company, city, work place (remote/hybrid/onsite), contract/work type, language, industry, posting date, salary and direct-employer flags. Returns 10 postings per page. | 1 per page |
| Count postings that match the same filters - for labour market questions. | 1 |
| List the most common values of a filter field (work place, industry, occupation, skills, company, city …) in the last 30 days with posting counts - to find exact filter values or the top companies/skills. Needs a PRO plan or higher. | 1 |
| Build a filtered RSS feed URL for job board backfill (with a key placeholder). | none |
Related MCP server: Bright Data MCP
Get a RapidAPI key and subscribe to the Techmap Jobs API. The free BASIC plan includes 1,000 job postings per month (1 request per second); paid usage is $1 per 1,000 postings.
Add the server to your MCP client.
Claude Desktop / Claude Code / Cursor (mcpServers config):
{
"mcpServers": {
"techmap-jobs": {
"command": "npx",
"args": ["-y", "@techmap/mcp-server"],
"env": { "TECHMAP_RAPIDAPI_KEY": "your-rapidapi-key" }
}
}
}Claude Code (CLI):
claude mcp add techmap-jobs -e TECHMAP_RAPIDAPI_KEY=your-rapidapi-key -- npx -y @techmap/mcp-serverSmithery: install from smithery.ai/servers/techmap/job-postings and enter your RapidAPI key when asked.
Your key stays on your machine; the server only sends it to RapidAPI. Usage is billed by RapidAPI on your own plan.
API documentation and OpenAPI specs: https://api.techmap.io
Daily data feeds and historical datasets per country (gzipped JSON Lines on AWS Data Exchange): https://jobdatafeeds.com/pricing
Free samples: Hugging Face, Kaggle
npm install
npm test # unit tests with a mocked API
TECHMAP_RAPIDAPI_KEY=... npx @modelcontextprotocol/inspector node build/src/index.jsMIT - © Techmap GmbH, Karlsruhe, Germany
Count the job postings that match the filters and return only the number (totalCount), e.g. how many remote Python jobs were posted in Germany in September 2026. Use this instead of search_jobs for labour market questions, trends or comparisons (call it once per country, month or role to compare); use search_jobs to see the postings themselves. Cost and limits: 1 API request, no postings are delivered; free plan allows 1 request per second. Without a date filter the most recent complete day is counted, so set dateCreated (month) or dateCreatedMin/Max for longer periods.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City of the workplace | |
| state | No | State/region of the workplace | |
| title | No | Search in the job title. Comma = OR, prefix + = must contain, prefix - = exclude, quotes = exact phrase, e.g. "data engineer",-senior (exact phrase "data engineer", excluding senior) | |
| skills | No | Skill or keyword, e.g. "python"; same comma/+/- syntax as title | |
| company | No | Hiring company name | |
| industry | No | Industry, e.g. "healthcare" | |
| isDirect | No | Only postings that link directly to the employer | |
| language | No | ISO 639-1 language of the posting, e.g. "en" | |
| workType | No | fulltime, parttime, flextime … | |
| hasSalary | No | Only postings with salary information | |
| workPlace | No | remote, hybrid, onsite, field or offshore (use list_filter_values for all values) | |
| occupation | No | Occupation stem extracted from the title, e.g. "developer", "nurse" | |
| countryCode | No | ISO 3166-1 alpha-2 country code of the job location, e.g. "de", "us", "lu"; "##" for postings without a country (mostly remote). Several codes can be combined with commas, e.g. "de,at,ch" | |
| dateCreated | No | Day (YYYY-MM-DD) or month (YYYY-MM) the job was posted. If neither dateCreated nor dateCreatedMin/Max is set, the API uses the day two days ago (the most recent complete day) | |
| isRecruiter | No | true = only recruiting firms, false = exclude them | |
| contractType | No | permanent, temporary, internship … | |
| dateCreatedMax | No | End of a posting date range (YYYY-MM-DD); use together with dateCreatedMin | |
| dateCreatedMin | No | Start of a posting date range (YYYY-MM-DD); use together with dateCreatedMax |
| Name | Required | Description |
|---|---|---|
| totalCount | No | Number of postings matching the filters |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover only readOnlyHint and openWorldHint; the description adds operational traits those do not: 1 API request per call, no postings are delivered, a free-plan limit of 1 request/second, and the non-obvious default that the most recent complete day is counted unless a date filter is set. That default is the kind of behavior an agent would otherwise get wrong.
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, front-loaded with the purpose, then the sibling routing, then a clearly labelled 'Cost and limits:' block. Every sentence carries distinct information; nothing is restated from the schema or annotations.
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 read-only counting tool with an output schema (totalCount) and full schema coverage, the description supplies the remaining decision-relevant context: when to prefer it, its cost, and its date-default behavior. An agent has everything needed 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 coverage is 100%, so the schema carries the per-field definitions and the baseline would be 3. The description adds meaning beyond the schema by explaining the fallback behavior of the date parameters ('Without a date filter the most recent complete day is counted, so set dateCreated (month) or dateCreatedMin/Max for longer periods'), which affects how an agent must set them.
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 ('Count the job postings') plus the exact return shape ('only the number (totalCount)'), which an agent can distinguish from search_jobs at a glance. The worked example ('how many remote Python jobs were posted in Germany in September 2026') removes any ambiguity about output.
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 routes between tools: 'Use this instead of search_jobs for labour market questions, trends or comparisons ... use search_jobs to see the postings themselves.' It also gives a concrete calling pattern ('call it once per country, month or role to compare'), leaving no inference needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build a URL for Techmap's RSS API that returns the postings matching the filters as an RSS 2.0 feed, e.g. to import jobs into job board software (backfill) or an RSS reader. Makes no API request and uses no quota: it only returns the URL, with a {YOUR_RAPIDAPI_KEY} placeholder that the user replaces with a key subscribed to the Techmap RSS API (free plan: 300 postings per month). Use search_jobs instead to see postings in this conversation.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City of the workplace | |
| state | No | State/region of the workplace | |
| title | No | Search in the job title. Comma = OR, prefix + = must contain, prefix - = exclude, quotes = exact phrase, e.g. "data engineer",-senior (exact phrase "data engineer", excluding senior) | |
| skills | No | Skill or keyword, e.g. "python"; same comma/+/- syntax as title | |
| company | No | Hiring company name | |
| industry | No | Industry, e.g. "healthcare" | |
| isDirect | No | Only postings that link directly to the employer | |
| language | No | ISO 639-1 language of the posting, e.g. "en" | |
| workType | No | fulltime, parttime, flextime … | |
| hasSalary | No | Only postings with salary information | |
| workPlace | No | remote, hybrid, onsite, field or offshore (use list_filter_values for all values) | |
| occupation | No | Occupation stem extracted from the title, e.g. "developer", "nurse" | |
| countryCode | No | ISO 3166-1 alpha-2 country code of the job location, e.g. "de", "us", "lu"; "##" for postings without a country (mostly remote). Several codes can be combined with commas, e.g. "de,at,ch" | |
| dateCreated | No | Day (YYYY-MM-DD) or month (YYYY-MM) the job was posted. If neither dateCreated nor dateCreatedMin/Max is set, the API uses the day two days ago (the most recent complete day) | |
| isRecruiter | No | true = only recruiting firms, false = exclude them | |
| contractType | No | permanent, temporary, internship … | |
| dateCreatedMax | No | End of a posting date range (YYYY-MM-DD); use together with dateCreatedMin | |
| dateCreatedMin | No | Start of a posting date range (YYYY-MM-DD); use together with dateCreatedMax |
| Name | Required | Description |
|---|---|---|
| url | Yes | RSS feed URL with a {YOUR_RAPIDAPI_KEY} placeholder |
| docs | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial context beyond the readOnly/openWorld annotations: it makes no API request, consumes no quota, returns a {YOUR_RAPIDAPI_KEY} placeholder the user must replace, and notes the free plan limit of 300 postings per month. These are exactly the non-obvious traits an agent needs before calling it.
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 tight sentences, front-loaded with what the tool produces, then the key operational facts, then the routing hint. No filler and nothing redundant with the schema.
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 URL-builder that returns no data, the description covers the essential facts: no request/quota cost, the key placeholder requirement, and the sibling alternative. An output schema exists, so return-value explanation is unnecessary.
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% across 18 parameters, so the schema already documents every filter in detail. The description only says results 'matching the filters' without adding syntax or semantics beyond the schema, 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?
States a specific verb ('Build a URL'), the resource ('Techmap's RSS API'), and the exact artifact produced (an RSS 2.0 feed URL matching the filters). It explicitly contrasts itself with search_jobs, so an agent can distinguish it from siblings without opening a schema.
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 when-to-use cases (importing jobs into job board software for backfill, or an RSS reader) and names the alternative explicitly: 'Use search_jobs instead to see postings in this conversation.' Both the use and the exclusion are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the most common values of a filter field in the job postings of the last 30 days, with the number of postings per value - e.g. which work places, industries or occupations exist, or the top companies, cities or skills. Use it to find exact filter values for search_jobs and count_jobs, or to answer "which companies post the most jobs" style questions. Returns up to "limit" values sorted by count, plus valueCount (number of distinct values). Cost and limits: 1 API request, no postings are delivered; requires a PRO, ULTRA or MEGA plan of the Techmap Jobs API (the free BASIC plan gets HTTP 403).
| Name | Required | Description | Default |
|---|---|---|---|
| field | Yes | Filter field whose values to list | |
| limit | No | Maximum number of values to return, sorted by number of postings (default 50) |
| Name | Required | Description |
|---|---|---|
| field | Yes | |
| values | Yes | Values with their number of postings, most frequent first |
| valueCount | No | Number of distinct values in the last 30 days |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover readOnlyHint/openWorldHint, but the description adds the material facts an agent needs before calling: it costs 1 API request, delivers no postings, and requires a PRO, ULTRA or MEGA plan (free BASIC returns HTTP 403). That auth/plan caveat and cost disclosure go well beyond structured data.
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 core purpose is front-loaded and the dense em-dash clause packs in examples and cost/plan constraints efficiently. There is minor redundancy, since 'top companies, cities or skills' partially repeats the 'which companies post the most jobs' example, but no sentence is wasted.
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 not be enumerated, yet the description still states the return shape and valueCount. With the plan prerequisite, request cost, field enum and limit semantics all covered, an agent has everything needed to call 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 coverage is 100% and the enum already documents the field values, so baseline is 3. The description adds meaning by illustrating what kinds of questions each field class answers ('which work places, industries or occupations exist', 'top companies, cities or skills') and restates limit as count-sorted with the valueCount companion, which helps the agent pick a field.
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 ('List the most common values of a filter field in the job postings of the last 30 days') plus the returned shape (count per value, valueCount). It is immediately distinguishable from search_jobs and count_jobs, which return postings or counts rather than distinct filter values.
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 names when to use it: 'to find exact filter values for search_jobs and count_jobs, or to answer which companies post the most jobs style questions.' Both the alternative tools and the selection condition are named, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Techmap's job postings (185 sources, 250 countries and territories, ~8M new postings per month) and return up to 10 postings per page, newest first by default. Each posting has title, company, location, work place, contract/work type, posting date, the URL of the original ad and a description shortened to 600 characters; totalCount tells how many postings match in total. Use this to show concrete postings; use count_jobs when only the number is needed. Cost and limits: 1 API request per page, counted as 10 postings against the caller's RapidAPI quota (free plan: 1,000 postings per month, 1 request per second). Without a date filter the most recent complete day is searched.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City of the workplace | |
| page | No | Result page (10 postings per page), default 1 | |
| sort | No | newest = most recently collected jobs first (default), oldest = stable order for paging through all results | |
| state | No | State/region of the workplace | |
| title | No | Search in the job title. Comma = OR, prefix + = must contain, prefix - = exclude, quotes = exact phrase, e.g. "data engineer",-senior (exact phrase "data engineer", excluding senior) | |
| skills | No | Skill or keyword, e.g. "python"; same comma/+/- syntax as title | |
| company | No | Hiring company name | |
| industry | No | Industry, e.g. "healthcare" | |
| isDirect | No | Only postings that link directly to the employer | |
| language | No | ISO 639-1 language of the posting, e.g. "en" | |
| workType | No | fulltime, parttime, flextime … | |
| hasSalary | No | Only postings with salary information | |
| workPlace | No | remote, hybrid, onsite, field or offshore (use list_filter_values for all values) | |
| occupation | No | Occupation stem extracted from the title, e.g. "developer", "nurse" | |
| countryCode | No | ISO 3166-1 alpha-2 country code of the job location, e.g. "de", "us", "lu"; "##" for postings without a country (mostly remote). Several codes can be combined with commas, e.g. "de,at,ch" | |
| dateCreated | No | Day (YYYY-MM-DD) or month (YYYY-MM) the job was posted. If neither dateCreated nor dateCreatedMin/Max is set, the API uses the day two days ago (the most recent complete day) | |
| isRecruiter | No | true = only recruiting firms, false = exclude them | |
| contractType | No | permanent, temporary, internship … | |
| dateCreatedMax | No | End of a posting date range (YYYY-MM-DD); use together with dateCreatedMin | |
| dateCreatedMin | No | Start of a posting date range (YYYY-MM-DD); use together with dateCreatedMax |
| Name | Required | Description |
|---|---|---|
| jobs | Yes | |
| page | No | |
| pageSize | No | |
| totalCount | No | Number of postings matching the filters |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, and the description goes well beyond them: RapidAPI quota cost (1 request = 10 postings, free plan 1,000/month, 1 req/s), 10-per-page pagination, sort default, and the crucial default that with no date filter the most recent complete day is searched.
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?
Front-loaded with what the tool returns, then usage routing, then cost/defaults. Every sentence carries distinct information; nothing is redundant filler despite the density.
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 and readOnly/openWorld annotations, the description only needed to add cost, pagination, and default-window behavior — all of which it does. An agent has everything required to call this correctly and interpret page semantics.
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 20 documented parameters, so the schema carries the parameter burden. The description only reinforces a couple of defaults (newest first, dateCreated fallback) and the 600-character description truncation, which is useful but adds little beyond the structured fields.
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 (search Techmap's job postings) plus concrete scope: 185 sources, 250 countries, ~8M postings/month. It also enumerates the returned fields and totalCount, so an agent can tell exactly what it gets back and distinguish it from count_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?
Explicitly routes the agent: 'Use this to show concrete postings; use count_jobs when only the number is needed.' It also points to list_filter_values for workPlace values, so the alternative and its trigger condition are named rather than inferred.
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.
v1.0.0count_jobs8 fields changedInput schema / properties / countryCode / descriptionPrevious value: -"ISO 3166-1 alpha-2 country code of the job location, e.g. \"de\", \"us\", \"lu\""New value: +"ISO 3166-1 alpha-2 country code of the job location, e.g. \"de\", \"us\", \"lu\"; \"##\" for postings without a country (mostly remote). Several codes can be combined with commas, e.g. \"de,at,ch\""Input schema / properties / dateCreated / descriptionPrevious value: -"Day (YYYY-MM-DD) or month (YYYY-MM) the job was posted; defaults to the most recent data"New value: +"Day (YYYY-MM-DD) or month (YYYY-MM) the job was posted. If neither dateCreated nor dateCreatedMin/Max is set, the API uses the day two days ago (the most recent complete day)"Input schema / properties / dateCreatedMax / descriptionPrevious value: -"End of a posting date range (YYYY-MM-DD)"New value: +"End of a posting date range (YYYY-MM-DD); use together with dateCreatedMin"Input schema / properties / dateCreatedMin / descriptionPrevious value: -"Start of a posting date range (YYYY-MM-DD)"New value: +"Start of a posting date range (YYYY-MM-DD); use together with dateCreatedMax"Input schema / properties / skills / descriptionPrevious value: -"Skill or keyword, e.g. \"python\""New value: +"Skill or keyword, e.g. \"python\"; same comma/+/- syntax as title"Input schema / properties / title / descriptionPrevious value: -"Free-text search in the job title, e.g. \"data engineer\""New value: +"Search in the job title. Comma = OR, prefix + = must contain, prefix - = exclude, quotes = exact phrase, e.g. \"data engineer\",-senior (exact phrase \"data engineer\", excluding senior)"Input schema / properties / workPlace / descriptionPrevious value: -"remote, hybrid, onsite, field or offshore"New value: +"remote, hybrid, onsite, field or offshore (use list_filter_values for all values)"Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "totalCount": {
+ "description": "Number of postings matching the filters",
+ "type": "number"
+ }
+ },
+ "type": "object"
+}get_rss_feed_url8 fields changedInput schema / properties / countryCode / descriptionPrevious value: -"ISO 3166-1 alpha-2 country code of the job location, e.g. \"de\", \"us\", \"lu\""New value: +"ISO 3166-1 alpha-2 country code of the job location, e.g. \"de\", \"us\", \"lu\"; \"##\" for postings without a country (mostly remote). Several codes can be combined with commas, e.g. \"de,at,ch\""Input schema / properties / dateCreated / descriptionPrevious value: -"Day (YYYY-MM-DD) or month (YYYY-MM) the job was posted; defaults to the most recent data"New value: +"Day (YYYY-MM-DD) or month (YYYY-MM) the job was posted. If neither dateCreated nor dateCreatedMin/Max is set, the API uses the day two days ago (the most recent complete day)"Input schema / properties / dateCreatedMax / descriptionPrevious value: -"End of a posting date range (YYYY-MM-DD)"New value: +"End of a posting date range (YYYY-MM-DD); use together with dateCreatedMin"Input schema / properties / dateCreatedMin / descriptionPrevious value: -"Start of a posting date range (YYYY-MM-DD)"New value: +"Start of a posting date range (YYYY-MM-DD); use together with dateCreatedMax"Input schema / properties / skills / descriptionPrevious value: -"Skill or keyword, e.g. \"python\""New value: +"Skill or keyword, e.g. \"python\"; same comma/+/- syntax as title"Input schema / properties / title / descriptionPrevious value: -"Free-text search in the job title, e.g. \"data engineer\""New value: +"Search in the job title. Comma = OR, prefix + = must contain, prefix - = exclude, quotes = exact phrase, e.g. \"data engineer\",-senior (exact phrase \"data engineer\", excluding senior)"Input schema / properties / workPlace / descriptionPrevious value: -"remote, hybrid, onsite, field or offshore"New value: +"remote, hybrid, onsite, field or offshore (use list_filter_values for all values)"Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "docs": {
+ "type": "string"
+ },
+ "url": {
+ "description": "RSS feed URL with a {YOUR_RAPIDAPI_KEY} placeholder",
+ "type": "string"
+ }
+ },
+ "required": [
+ "url",
+ "docs"
+ ],
+ "type": "object"
+}list_filter_valuessearch_jobs9 fields changedInput schema / properties / countryCode / descriptionPrevious value: -"ISO 3166-1 alpha-2 country code of the job location, e.g. \"de\", \"us\", \"lu\""New value: +"ISO 3166-1 alpha-2 country code of the job location, e.g. \"de\", \"us\", \"lu\"; \"##\" for postings without a country (mostly remote). Several codes can be combined with commas, e.g. \"de,at,ch\""Input schema / properties / dateCreated / descriptionPrevious value: -"Day (YYYY-MM-DD) or month (YYYY-MM) the job was posted; defaults to the most recent data"New value: +"Day (YYYY-MM-DD) or month (YYYY-MM) the job was posted. If neither dateCreated nor dateCreatedMin/Max is set, the API uses the day two days ago (the most recent complete day)"Input schema / properties / dateCreatedMax / descriptionPrevious value: -"End of a posting date range (YYYY-MM-DD)"New value: +"End of a posting date range (YYYY-MM-DD); use together with dateCreatedMin"Input schema / properties / dateCreatedMin / descriptionPrevious value: -"Start of a posting date range (YYYY-MM-DD)"New value: +"Start of a posting date range (YYYY-MM-DD); use together with dateCreatedMax"Input schema / properties / skills / descriptionPrevious value: -"Skill or keyword, e.g. \"python\""New value: +"Skill or keyword, e.g. \"python\"; same comma/+/- syntax as title"Input schema / properties / sort / descriptionPrevious value: -"newest = most recently collected jobs first (recommended), oldest = default API order"New value: +"newest = most recently collected jobs first (default), oldest = stable order for paging through all results"Input schema / properties / title / descriptionPrevious value: -"Free-text search in the job title, e.g. \"data engineer\""New value: +"Search in the job title. Comma = OR, prefix + = must contain, prefix - = exclude, quotes = exact phrase, e.g. \"data engineer\",-senior (exact phrase \"data engineer\", excluding senior)"Input schema / properties / workPlace / descriptionPrevious value: -"remote, hybrid, onsite, field or offshore"New value: +"remote, hybrid, onsite, field or offshore (use list_filter_values for all values)"Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "jobs": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "city": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ ]
+ },
+ "company": {
+ "type": "string"
+ },
+ "contractType": {
+ "$ref": "#/properties/jobs/items/properties/city"
+ },
+ "countryCode": {
+ "$ref": "#/properties/jobs/items/properties/city"
+ },
+ "datePosted": {
+ "type": "string"
+ },
+ "description": {
+ "description": "Description shortened to 600 characters",
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "industry": {
+ "$ref": "#/properties/jobs/items/properties/city"
+ },
+ "isDirect": {
+ "type": "boolean"
+ },
+ "isRecruiter": {
+ "type": "boolean"
+ },
+ "language": {
+ "$ref": "#/properties/jobs/items/properties/city"
+ },
+ "occupation": {
+ "$ref": "#/properties/jobs/items/properties/city"
+ },
+ "salary": {
+ "description": "Salary details from the posting, if any"
+ },
+ "state": {
+ "$ref": "#/properties/jobs/items/properties/city"
+ },
+ "title": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ },
+ "validThrough": {
+ "type": "string"
+ },
+ "workPlace": {
+ "$ref": "#/properties/jobs/items/properties/city"
+ },
+ "workType": {
+ "$ref": "#/properties/jobs/items/properties/city"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "page": {
+ "type": "number"
+ },
+ "pageSize": {
+ "type": "number"
+ },
+ "totalCount": {
+ "description": "Number of postings matching the filters",
+ "type": "number"
+ }
+ },
+ "required": [
+ "jobs"
+ ],
+ "type": "object"
+}v0.1.0count_jobsget_rss_feed_urlsearch_jobsScored across 4 tools
Each tool has a clearly distinct role: URL construction (get_rss_feed_url), postings retrieval (search_jobs), counting only (count_jobs), and filter discovery (list_filter_values). The descriptions explicitly cross-reference each other (e.g. 'use count_jobs when only the number is needed') eliminating overlap ambiguity.
All names follow a consistent snake_case verb_noun pattern: get_rss_feed_url, search_jobs, count_jobs, list_filter_values. Verbs are varied but semantically appropriate rather than inconsistent.
Four tools is lean but each has a defensible purpose for a job-postings API, and no tool is redundant. Slightly under the ideal range, though nothing feels missing that a paginated search doesn't already cover.
The surface covers search, count, filter discovery, and RSS feed generation, which handles most lifecycle needs. Minor gap: there is no direct fetch-by-posting-ID tool, though search results already include full posting fields.
Search job postings across Indeed, LinkedIn, and more from one request - titles, companies
JobsPipe — data pipeline of every job posting on the web. Search live, normalized job postings from 30+ ATS feeds and job boards for AI agents via MCP.
Search job postings, companies, and technology stacks across 10M+ companies.
Search a live index of millions of open jobs from employer career sites and 100+ ATS platforms.
