Techmap Job Postings MCP Server

Official

by TechMap

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

Search job postings

search_jobs

Read-only

Find job postings from 185 sources across 250 countries using filters like title, skills, and location. Returns up to 10 postings per page, newest first.

Instructions

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.

Input Schema

TableJSON Schema

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

Output Schema

TableJSON Schema

Name	Required	Description
`jobs`	Yes
`page`	No
`pageSize`	No
`totalCount`	No	Number of postings matching the filters

Schema Changelog

Changes observed during successful MCP inspections.

Changed9 schema fields changedv1.0.0Oct 1, 2026

changedInput schema / properties / countryCode / description

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

changedInput schema / properties / dateCreated / description

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

changedInput schema / properties / dateCreatedMax / description

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

changedInput schema / properties / dateCreatedMin / description

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

changedInput schema / properties / skills / description

Previous value: -"Skill or keyword, e.g. \"python\""New value: +"Skill or keyword, e.g. \"python\"; same comma/+/- syntax as title"

changedInput schema / properties / sort / description

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

changedInput schema / properties / title / description

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

changedInput schema / properties / workPlace / description

Previous value: -"remote, hybrid, onsite, field or offshore"New value: +"remote, hybrid, onsite, field or offshore (use list_filter_values for all values)"

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

First observedv0.1.0Oct 1, 2026

TDQS

A4.7/5.0

Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

Deploy Server