Techmap Job Postings MCP Server

Official

by TechMap

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

Count job postings

count_jobs

Read-only

Count matching job postings and return only the total for labor market questions, trends, or comparisons; use search_jobs to view the postings.

Instructions

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.

Input Schema

TableJSON Schema

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

Output Schema

TableJSON Schema

Name	Required	Description	Default
`totalCount`	No	Number of postings matching the filters

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 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 / 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": {
+    "totalCount": {
+      "description": "Number of postings matching the filters",
+      "type": "number"
+    }
+  },
+  "type": "object"
+}

First observedv0.1.0Oct 1, 2026

TDQS

A4.9/5.0

Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

Deploy Server