Techmap Job Postings MCP Server
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| TECHMAP_RAPIDAPI_KEY | Yes | Your RapidAPI key for the Techmap Jobs API |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| search_jobsA | 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. |
| count_jobsA | 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. |
| get_rss_feed_urlA | 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. |
| list_filter_valuesA | 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). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored 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.