StaatsJobs.com

Server Details

Stellen im öffentlichen Dienst in Deutschland suchen und filtern, mit Tarif- und Besoldungstabellen

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Last Tested: 2026-11-05 19:09
Transport: Streamable HTTP · MCP 2025-11-25
URL
ChatGPT: –
Claude: –

TDQS

A3.6/5.0

Scored 2026-11-05 16:10 across 6 tools

Disambiguation2/5

fetch and get_job are described almost identically (both return 'Eckdaten zu einer Stelle' by id and both explicitly note the full text is only on the job page), so an agent cannot reliably choose between them. search and search_jobs also overlap on job lookup, though their descriptions (full-text vs. filters/pagination) do help separate them.

Naming Consistency3/5

All names are snake_case, which is good, but the verb style is mixed: bare verbs (fetch, search) alongside get_job, get_pay_table, list_filter_values, and search_jobs. Notably, two tools for the same 'get job details' action use different verbs (fetch vs get_job), breaking the pattern.

Tool Count4/5

Six tools is a well-scoped surface for a job board (search, detail, pay tables, filter metadata). The only redundancy is the fetch/get_job pair, which arguably should be one tool.

Completeness3/5

Discovery (search, search_jobs with pagination), detail lookups, filter value enumeration, and pay tables are all covered. However, both detail tools explicitly state they do not return the job text (Aufgaben/Anforderungen), and no tool exists to retrieve it, forcing agents to fetch the external URL themselves — a notable gap for a job-listing server.

Available Tools

6 tools

fetchStelle abrufen (ChatGPT)A

Read-onlyIdempotent

Inspect

Eckdaten zu einer Stelle anhand der id aus search. Den Stellentext gibt es nur auf der Stellenseite (url).

Name	Required	Description	Default
`id`	Yes	id aus search

Output Schema

Name	Required	Description
`id`	Yes
`url`	Yes
`text`	Yes
`title`	Yes
`metadata`	No

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the bar is lower. The description still adds real behavioral value by disclosing a data limitation: only key data is returned, and the full text must be obtained from the url page. Permissions, rate limits and error behavior are not covered.

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 short sentences, both load-bearing: the first states what is returned, the second states what is not returned and where to get it. Nothing is wasted and the key limitation is front-loaded.

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 an output schema present, the description need not explain return fields, and it usefully flags the partial-data nature of the response. For a one-parameter read-only tool this is close to complete; only sibling disambiguation is missing.

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% and the single id parameter is documented in the schema as 'id aus search'. The description merely repeats that phrasing without adding format, length or validity constraints, so baseline 3 applies.

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

Purpose4/5

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

The description names a concrete resource (Eckdaten zu einer Stelle) and states the lookup key (id aus search), and it explicitly bounds the scope by saying the full job text is only on the job page (url). An agent can tell this apart from search, though the overlap with the sibling get_job is not addressed.

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 implied rather than stated: use it when you already have an id from search and need summary data. It gives no explicit when-not guidance and never mentions the close siblings get_job or search_jobs, so an agent must infer which one to call.

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

get_jobStelle anzeigenA

Read-onlyIdempotent

Inspect

Eckdaten zu einer Stelle: Arbeitgeber, Ort, Eingruppierung, Gehaltsspanne, Laufbahn, Bewerbungsfrist und Link zur Stellenseite. Den Stellentext (Aufgaben, Anforderungen) liefert das Tool nicht; er steht nur auf der Stellenseite.

Name	Required	Description	Default
`id`	Yes	Feld id aus search_jobs oder die URL der Stellenseite

Output Schema

Name	Required	Description
`id`	Yes	Stellen-ID für get_job
`url`	Yes	Stellenseite auf StaatsJobs.com – dort steht die vollständige Ausschreibung und der Bewerbungsweg
`city`	Yes
`note`	No
`state`	Yes
`title`	Yes
`remote`	No
`salary`	No
`status`	Yes
`deadline`	No
`employer`	Yes
`pay_grade`	No
`employment`	No
`fixed_term`	No
`postal_code`	No
`salary_note`	No
`career_track`	No
`published_at`	No
`working_time`	No
`employer_slug`	No
`employer_type`	No
`pay_table_url`	No
`career_changer`	No
`details_only_on_website`	No

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed world), so the bar is lower. The description earns credit by disclosing the key negative behavior: the Stellentext (tasks, requirements) is deliberately NOT returned and must be obtained from the linked page, which prevents a wrong assumption about coverage.

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, no waste: the first front-loads the returned fields, the second immediately flags the exclusion. Each sentence carries distinct, decision-relevant information.

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?

An output schema exists, so return values need not be spelled out, and the description still summarizes them helpfully. Combined with annotations covering safety and a fully documented single parameter, the only remaining gap is the absence of explicit guidance on sourcing the id or on when to fall back to fetch/search_jobs.

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% and there is a single required id parameter already documented in the schema as 'field id aus search_jobs oder die URL der Stellenseite'. The description adds no additional meaning about the accepted id formats or URL handling, so the baseline 3 applies.

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

Purpose4/5

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

States a specific verb-resource pair (retrieve job key data) and enumerates exactly which fields come back: employer, location, grading, salary range, career track, deadline, link. It is clearly the detail-lookup counterpart to search_jobs, though it does not name any sibling explicitly in the description itself.

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: the closing sentence tells you the job text lives on the job page, which hints that this tool is a metadata shortcut rather than a full-text fetch. There is no explicit 'call search_jobs first to get the id' or 'use fetch instead if you need the full posting' routing guidance inside the description; that hint exists only in the schema's id field.

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

get_pay_tableTarif- und BesoldungstabelleA

Read-onlyIdempotent

Inspect

Aktuelle Monatsbeträge (brutto) einer Entgelt- oder Besoldungstabelle je Gruppe und Stufe, mit Gültigkeitsdatum und amtlicher Quelle. Optional nur eine Gruppe, z. B. „E 9b“ oder „A 13“.

Name	Required	Description	Default
`grade`	No	Eine Gruppe, z. B. „E 9b“, „A 13“, „S 8a“
`scheme`	Yes	Tabelle: tvoed-vka, tvoed-bund, tvoed-sue, tvoed-pflege, tv-l oder besoldung-bund

Output Schema

Name	Required	Description
`name`	Yes
`unit`	Yes
`stand`	Yes
`grades`	Yes
`scheme`	Yes
`source`	Yes
`table_url`	Yes
`source_url`	Yes
`step_label`	Yes
`valid_from`	Yes
`grade_label`	Yes

TDQS

A4/5.0

Behavior4/5

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

Annotations already establish read-only, idempotent, non-destructive, closed-world behavior, so the description need not repeat safety. It adds meaningful context: amounts are current and gross, include validity date and official source, and grade can optionally limit results to one group. Error handling and pagination are not discussed, but an output schema exists, reducing that burden.

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, front-loaded with what data is returned, followed by the optional filter. There is no filler or redundant wording.

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 two-parameter read-only tool with an output schema and full schema descriptions, the definition is complete enough: it states scope, returned data context, and the optional group filter. The required scheme choices are fully enumerated in the schema.

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 baseline is 3. The description adds that grade is optional and limits results to a single group, with examples matching the schema, providing useful semantic clarification beyond the schema field descriptions.

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

Purpose4/5

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

The description names a specific verb and resource (get pay table) and states the returned content: current gross monthly amounts per group and step, with validity date and official source. It is clearly distinct from generic siblings like fetch/search by domain, but it does not explicitly name or contrast alternative tools.

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 use for retrieving current pay table amounts and explains that grade can optionally narrow results to one group. However, it gives no explicit when-to-use versus when-not guidance or alternatives among sibling tools.

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

list_filter_valuesFilterwerteA

Read-onlyIdempotent

Inspect

Gültige Werte mit Beschriftung für die Filter von search_jobs (Bundesländer, Berufsfelder, Arbeitgebertypen, Dienstverhältnis, Laufbahn, Tarife) und die Tabellen von get_pay_table.

Name	Required	Description	Default
`dimension`	No	Nur diese Dimension; ohne Angabe alle

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare readOnly, idempotent, closed-world and non-destructive, so the safety profile needs no repetition. The description adds that values come with labels and that omitting the dimension yields everything, but says nothing about result size, ordering, or response shape, which matters for a lookup tool with no output schema.

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

Conciseness4/5

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

One sentence, front-loaded with the purpose, with zero filler. The long parenthetical dimension list is dense but each item earns its place by naming a supported filter.

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 one-parameter, read-only lookup with complete annotations and full schema coverage, the description covers what the tool is and what it feeds. The remaining gap is the German-label to English-enum mapping, which could cause a wrong dimension choice.

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% and the enum plus its 'ohne Angabe alle' default is already documented, so the baseline is 3. The description does enumerate the dimensions in German, but the enum codes are English (state, field, pay_scheme), and the mapping between the two vocabularies is left implicit.

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

Purpose4/5

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

The description states the resource precisely: valid values with labels for the filters of search_jobs and the tables of get_pay_table, which cleanly separates it from the sibling search/get tools. A literal verb like 'list'/'retrieve' is missing, but the noun phrase makes the operation unambiguous.

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?

Naming search_jobs and get_pay_table as the consumers of these values gives an agent clear context for when to call this tool. There is no explicit 'call this before searching' sequencing advice and no when-not guidance, so it stops short of the top band.

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

searchSuche (ChatGPT)A

Read-onlyIdempotent

Inspect

Volltextsuche in den Stellenangeboten von StaatsJobs.com. Gibt id, title und url zurück; Details mit fetch. Für Filter (Ort, Tarif, Entgeltgruppe …) search_jobs verwenden.

Name	Required	Description	Default
`query`	Yes	Suchbegriffe, z. B. „Bauingenieur Stadtverwaltung München“

Output Schema

Name	Required	Description
`results`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds the useful behavioral note that results are shallow (id, title, url) and that detail requires a follow-up fetch call, which shapes how an agent plans a multi-step query. It is slightly redundant with the output schema, which already documents the return shape.

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 short sentences, zero filler, with the core purpose front-loaded and the routing hints following. Every clause carries actionable information.

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 single-parameter read-only search with an output schema and rich annotations, the description covers purpose, return shape, and sibling routing. Nothing an agent needs in order to call it correctly is missing.

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% and the single query parameter already carries an example, so the schema does the heavy lifting. The description adds no syntax, length, or matching-behavior detail (e.g. whether it is AND/OR, stemming, or German-language specific) beyond what the schema provides, so 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?

States a specific verb and resource ('Volltextsuche in den Stellenangeboten von StaatsJobs.com') and explicitly distinguishes itself from two siblings: fetch for details and search_jobs for filters. An agent can route correctly without opening any schema.

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?

Gives explicit when-to-use-this and when-to-use-alternatives guidance: details go to fetch, structured filters (Ort, Tarif, Entgeltgruppe) go to search_jobs. The exclusion condition is concrete rather than implied.

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

search_jobsStellen suchenA

Read-onlyIdempotent

Inspect

Durchsucht aktuelle Stellenangebote im öffentlichen Dienst in Deutschland. Alle Filter sind optional und werden UND-verknüpft (innerhalb einer Liste ODER). Liefert höchstens 25 Treffer je Seite; weitere Seiten über next_cursor.

Name	Required	Description
`sort`	No	relevanz (Standard mit Suchbegriff), neueste (Standard ohne), frist (Bewerbungsfrist zuerst).
`field`	No	Berufsfelder als Slug; gültige Werte liefert list_filter_values.
`limit`	No	Treffer je Seite (Standard 10, höchstens 25).
`query`	No	Suchbegriffe für Titel, Arbeitgeber und Stellentext, z. B. „Sachbearbeiter Bauamt“. Unterstützt "Phrasen" und -Ausschluss.
`state`	No	Bundesländer als Slug, z. B. „bayern“.
`cursor`	No	next_cursor aus der vorigen Antwort, um die nächste Seite derselben Suche zu laden.
`remote`	No	homeoffice = Homeoffice-Anteil möglich (hybrid oder voll remote), remote = vollständig mobil.
`employer`	No	Arbeitgeber-Slug aus einer früheren Antwort (Feld employer_slug).
`location`	No	Ort oder fünfstellige PLZ, z. B. „Nürnberg“ oder „90402“.
`pay_grade`	No	Entgelt- oder Besoldungsgruppen, z. B. „E 9b“, „A 13“, „S 8a“. Trifft auch Stellen, deren Spanne die Gruppe einschließt.
`radius_km`	No	Umkreis um den Ort in km (Standard 25).
`employment`	No	Dienstverhältnis: beamte (Beamtenverhältnis), tarif (Tarifbeschäftigung), ausbildung, praktikum, dual (duales Studium).
`fixed_term`	No
`pay_scheme`	No	Tarifvertrag bzw. Besoldungsordnung.
`career_track`	No	Laufbahngruppe (Beamte): einfach, mittel, gehoben, hoeher.
`working_time`	No
`employer_type`	No	Art des Arbeitgebers.
`career_changer`	No	Nur Stellen, die ausdrücklich Quereinsteiger ansprechen.
`published_within_days`	No	Nur Anzeigen, die in den letzten n Tagen veröffentlicht wurden.

Output Schema

Name	Required	Description
`page`	Yes
`items`	Yes
`notes`	Yes
`total`	Yes
`search_url`	Yes	Dieselbe Suche als Trefferliste auf StaatsJobs.com
`next_cursor`	Yes

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already establish the read-only, idempotent, non-destructive profile, so the description is free to add what they cannot: a hard cap of 25 results per page and cursor-based paging via next_cursor. Those are concrete behavioral facts an agent needs to plan retrieval and avoid assuming it saw the complete 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?

Three short sentences with zero filler: domain scope first, then filter-combination rule, then paging constraint. Every sentence carries information an agent would otherwise have to guess.

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 19-parameter search tool with an output schema and near-full schema descriptions, the description covers the two things the schema cannot: result-set size and pagination. The remaining gap is not pointing to list_filter_values for valid slugs, which the schema mentions only for the field parameter.

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 89%, so the schema already defines each filter's meaning; the description adds the combination semantics (AND across filters, OR within a list) that the schema does not encode. That is real, non-redundant meaning beyond the parameter definitions, though other behavioral details such as what limit defaults to are left to the schema.

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

Purpose4/5

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

The description states a specific verb and resource ('Durchsucht aktuelle Stellenangebote im öffentlichen Dienst in Deutschland') and scopes it to the German public sector, which distinguishes it from the other search-family tools. It stops short of naming a sibling such as get_job or list_filter_values, so the differentiation is inferred rather than explicit.

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?

It clarifies that all filters are optional and that they combine with AND (OR within a single list), which is genuine usage guidance for multi-filter calls. It never says when to prefer this tool over get_job or search, nor when to call list_filter_values first for valid slugs, so an agent gets context but no routing rules.

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.

2 tool updatesNov 5, 2026

Changedget_job2 fields changed

removedOutput schema / properties / teaser

Removed value: -{
-  "description": "Anfang des Stellentexts (höchstens 400 Zeichen); die vollständige Ausschreibung steht nur auf der Stellenseite",
-  "type": [
-    "string",
-    "null"
-  ]
-}

changedOutput schema / required

Previous value: -[
-  "id",
-  "title",
-  "employer",
-  "city",
-  "state",
-  "url",
-  "teaser",
-  "status"
-]New value: +[
+  "id",
+  "title",
+  "employer",
+  "city",
+  "state",
+  "url",
+  "status"
+]

Changedsearch_jobs2 fields changed

removedOutput schema / properties / items / items / properties / teaser

Removed value: -{
-  "description": "Anfang des Stellentexts (höchstens 400 Zeichen); die vollständige Ausschreibung steht nur auf der Stellenseite",
-  "type": [
-    "string",
-    "null"
-  ]
-}

changedOutput schema / properties / items / items / required

Previous value: -[
-  "id",
-  "title",
-  "employer",
-  "city",
-  "state",
-  "url",
-  "teaser"
-]New value: +[
+  "id",
+  "title",
+  "employer",
+  "city",
+  "state",
+  "url"
+]

2 tool updatesNov 5, 2026

Changedget_job4 fields changed

removedOutput schema / properties / benefits

Removed value: -{
-  "items": {
-    "type": "string"
-  },
-  "type": "array"
-}

removedOutput schema / properties / qualifications

Removed value: -{
-  "items": {
-    "type": "string"
-  },
-  "type": "array"
-}

addedOutput schema / properties / teaser / description

Added value: +"Anfang des Stellentexts (höchstens 400 Zeichen); die vollständige Ausschreibung steht nur auf der Stellenseite"

changedOutput schema / required

Previous value: -[
-  "id",
-  "title",
-  "employer",
-  "city",
-  "state",
-  "url",
-  "status"
-]New value: +[
+  "id",
+  "title",
+  "employer",
+  "city",
+  "state",
+  "url",
+  "teaser",
+  "status"
+]

Changedsearch_jobs2 fields changed

addedOutput schema / properties / items / items / properties / teaser / description

Added value: +"Anfang des Stellentexts (höchstens 400 Zeichen); die vollständige Ausschreibung steht nur auf der Stellenseite"

changedOutput schema / properties / items / items / required

Previous value: -[
-  "id",
-  "title",
-  "employer",
-  "city",
-  "state",
-  "url"
-]New value: +[
+  "id",
+  "title",
+  "employer",
+  "city",
+  "state",
+  "url",
+  "teaser"
+]

6 tool updatesNov 5, 2026
- First observedfetch
- First observedget_job
- First observedget_pay_table
- First observedlist_filter_values
- First observedsearch
- First observedsearch_jobs

Related MCP Connectors

JobJump A
net.jobjump
Jobs, salaries, net pay and labour-market data for Germany from the JobJump job board.
Search Finance Open Data
101
https://jobjump.net/mcp
Rebond, offres d'emploi A
pro.rebond
Offres d'emploi publiques en France : recherche par métier, ville, contrat, télétravail.
Search Open Data Government Data
21
https://rebond.pro/mcp
stellenonline.de Jobsuche A
de.stellenonline
Read-only search across current job listings on stellenonline.de (German job portal).
Search Web Scraping
31
https://www.stellenonline.de/mcp
Vergabeweiser A
de.vergabeweiser
German public tenders and contract awards: search, deadlines, winners, market figures. Open data.
Government Data Open Data
81
https://vergabeweiser.de/mcp

Related MCP Servers

mcp-usajobs
Government Data Search
pipeworx-io
A
license
Not graded
quality
B
maintenance
Search and retrieve US federal job postings from USAJOBS.gov. Includes tools for finding announcements, agencies, pay grades, and occupational series.
Updated 8 days ago (2026-10-29 07:00 UTC)
203 npm
MIT
arbeitsagentur-mcp
Government Data Search Workplace & Productivity
slopmaxxer
A
license
Not graded
quality
B
maintenance
Enables users to search live Bundesagentur für Arbeit public data and manage a local case file with applications, deadlines, letter drafts, and their own Meine BA account.
Updated 3 days ago (2026-11-03 07:16 UTC)
MIT
Berlin Services MCP Server
Government Data Search
MananCoder29
A
license
C
quality
D
maintenance
Enables comprehensive search and browsing of Berlin city services. Also supports PDF form discovery, analysis, and filling with resilient caching.
Updated 8 months ago (2026-02-24 18:00 UTC)
18
6
MIT
Arbeitnow Job Board MCP
Search Open Data
pipeworx-io
A
license
Not graded
quality
B
maintenance
Enables AI agents to browse recent job postings from a keyless European (Germany-heavy) job board, keyword-search them client-side by title, company or tag, and fetch full HTML descriptions for individual listings, with pagination and remote-only filtering.
Updated 7 days ago (2026-10-30 07:28 UTC)
272 npm
MIT

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?