InfraNode

Server Details

Keyless open data for 84 German cities: 12 lean read-only MCP tools covering 67 data types.

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
Uptime: 99.9% over 63 days
Last Tested: 2026-10-19 19:29
Transport: Streamable HTTP · MCP 2025-11-25
URL
Repository: street1983nk/infranode
GitHub Stars: 14
Server Listing: InfraNode

TDQS

A4/5.0

Scored 2026-10-18 18:00 across 12 tools

Disambiguation3/5

The generic get_city_resource covers all 80 data types including air, weather, transit and stations, so it substantially overlaps the specialized air_quality, weather, pois, transit_departures and station_board_* tools. The descriptions do cross-reference each other well to guide selection, but offering three ways to get the same weather/air data leaves genuine ambiguity.

Naming Consistency3/5

Names are uniformly snake_case, which is good, but conventions are mixed: some are verb_noun (get_city, get_city_resource, list_cities), while many are bare nouns (air_quality, weather, pois, sources, station_board_arrivals) or bare verbs (compare). Readable but not a predictable pattern.

Tool Count4/5

12 tools is a reasonable, well-scoped count for a broad German city/data aggregator. It is slightly heavier than needed because several specialized tools partially duplicate the universal accessor, but each still earns its place for convenience.

Completeness5/5

Coverage is excellent: discovery (list_cities), an all-in-one overview, a 80-type generic accessor, multi-city comparison, source/attribution listing, and specialized live-data tools. The not_covered status handling avoids dead ends, and the read-only surface fits a data-aggregation domain.

Available Tools

12 tools

air_qualityAir QualityA

Read-onlyIdempotent

Inspect

Get official air quality for a German city (PM10, NO2 and more).

Sourced from the Umweltbundesamt (UBA). Read-only. For live nearest-station hourly readings use get_city_resource(slug, resource='air') instead.

ParametersJSON Schema

Name	Required	Description	Default
`slug`	Yes	City identifier, e.g. 'berlin' or 'hamburg'. Resolved leniently: the German name with or without umlauts, any casing, a common English exonym or short form also works (München/munich/munchen -> muenchen, cologne -> koeln, frankfurt -> frankfurt-am-main). An unknown name returns 404 with a 'Meintest du ...?' suggestion. list_cities gives the canonical slugs.

Output Schema

ParametersJSON Schema

Name	Required	Description
`data`	Yes
`meta`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds the specific data source (UBA), which provides source transparency. No additional behavioral details (e.g., rate limits) are given, but the annotation coverage is strong.

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 concise sentences: first states purpose and pollutants; second provides source and alternative tool. Front-loaded with the main action, no filler.

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 one-parameter tool with a rich schema and output schema, the description covers the data source, scope, and key data returned. It also references the sibling for different use cases, making it self-contained.

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%, with detailed resolution logic for the slug parameter. The tool description does not add parameter-level details beyond the schema, 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?

The description clearly states the action ('Get'), the resource ('official air quality'), the scope ('German city'), and specific pollutants ('PM10, NO2 and more'). It distinguishes this tool from the sibling `get_city_resource` by contrasting data source (UBA vs. live nearest-station hourly readings).

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 states when to use (for official city air quality) and when not, providing the exact alternative call: `get_city_resource(slug, resource='air')` for live hourly readings. Also notes the data source (Umweltbundesamt).

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

compareCompare CitiesA

Read-onlyIdempotent

Inspect

Compare ONE resource across MULTIPLE cities in a single response.

Fans the resource out over the listed cities and returns a per-city source_status (ok/disabled/no_data/error/not_found), so a missing or failing city source does not spoil the whole answer. Read-only.

ParametersJSON Schema

Name	Required	Description	Default
`cities`	Yes	Comma-separated list of city slugs, e.g. 'berlin,koeln,hamburg' (max. 28 cities).
`resource`	Yes	Resource to compare. Supported: 'weather' (DWD), 'air' (UBA air quality), 'indicators' (INKAR socioeconomic indicators incl. unemployment rate and EV charging coverage), 'demographics', 'unemployment', 'tourism', 'charging-status' (live EV charging occupancy, aggregates only) and 'weather-warnings' (official DWD warning level per city).

Output Schema

ParametersJSON Schema

Name	Required	Description
`data`	Yes
`meta`	Yes

TDQS

A4.1/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, covering safety. The description adds valuable context by explaining the per-city source_status handling (e.g., no_data, error) and that missing sources don't spoil the answer, but it doesn't detail any other behavioral aspects like rate limits or response structure beyond the 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.

Conciseness5/5

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

The description is concise, with a clear opening line that summarizes the core function, followed by two sentences that explain the fan-out behavior and resilience. No redundant information; every sentence adds value, and the structure is front-loaded.

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 high-confidence schema (100% coverage), rich annotations (read-only, idempotent, non-destructive), and an output schema, the description completes the picture by clarifying the per-city status handling and scope. It's fully adequate for an agent to decide when and how to use this tool versus alternatives.

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%, so the schema already documents both parameters with examples (e.g., city slugs, supported resources). The description reinforces the meaning of 'resource' by listing supported values, but since the schema already provides this, the additional value is limited, aligning with the baseline of 3.

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?

The description clearly states the tool compares ONE resource across MULTIPLE cities, distinguishing it from single-city tools like get_city_resource or weather. It specifies the output format (per-city source_status) and explicitly notes read-only behavior, making the purpose unambiguous and distinct from siblings.

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?

The description implies usage for comparing a resource across cities and notes that it fans out over listed cities, preventing one failing city from spoiling the result. It doesn't explicitly state when not to use it or name alternatives, but the mission from siblings (e.g., get_city_resource for single-city) is clear, and the 'read-only' note discourages misuse for mutable operations.

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

get_cityCity Base DataA

Read-onlyIdempotent

Inspect

Get base data for a German city (population, area, coordinates).

Sourced from Wikidata. Read-only. Useful as a first lookup to confirm a city exists and get its core attributes. For a broader question about the city (what data is available at all) use get_city_overview instead.

ParametersJSON Schema

Name	Required	Description	Default
`slug`	Yes	City identifier, e.g. 'berlin' or 'hamburg'. Resolved leniently: the German name with or without umlauts, any casing, a common English exonym or short form also works (München/munich/munchen -> muenchen, cologne -> koeln, frankfurt -> frankfurt-am-main). An unknown name returns 404 with a 'Meintest du ...?' suggestion. list_cities gives the canonical slugs.

Output Schema

ParametersJSON Schema

Name	Required	Description
`data`	Yes
`meta`	Yes

TDQS

A4.3/5.0

Behavior3/5

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

The description adds value by stating the data source ('Sourced from Wikidata') and explicitly calling out the read-only nature, which aligns with and reinforces the annotations (readOnlyHint: true, destructiveHint: false). However, it doesn't disclose further behavioral traits like what happens on error or if the city is not found, though the parameter schema does mention a 404 response with suggestions. The core safety profile is well-covered by annotations, so the description provides adequate context without being overly redundant.

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?

The description is extremely concise, consisting of two short sentences. The first sentence clearly states the purpose and core data delivered. The second paragraph is front-loaded with the most critical context (data source, read-only) immediately after. Every sentence provides necessary information without redundancy.

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?

Given the tool's low complexity (1 parameter, 100% schema coverage, clear annotations, and an output schema for return values), the description is complete enough. It covers what the tool does, its data source, its scope, and when to use an alternative. The output schema handles the return values, so the description doesn't need to explain them.

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?

The schema description coverage is 100%, with a detailed description of the 'slug' parameter including lenient resolution rules and examples. The description itself doesn't add significant meaning about the parameter beyond what the schema already provides, so a baseline score of 3 is appropriate.

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?

The description uses a specific verb ('Get') and resource ('base data') and explicitly lists the returned fields (population, area, coordinates). It distinguishes itself from its sibling 'get_city_overview' by stating this is a 'first lookup' for core attributes vs. a broader overview.

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?

The description provides clear guidance on when to use this tool ('first lookup', 'confirm a city exists') and explicitly states when not to use it ('for a broader question... use get_city_overview instead'). It also mentions the data source and read-only nature.

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

get_city_overviewCity OverviewA

Read-onlyIdempotent

Inspect

Get a ONE-CALL overview of everything InfraNode knows about a German city.

Start here for any city question. Returns: the city's base data, a CATALOG of all 80 available data types (weather, air quality, public transit, trains, traffic, charging, parking, solar, energy, demographics, taxes, accidents, tourism, heritage, trees, population density, playgrounds, post boxes and many more), each with its coverage status and the exact tool to call next (for most data types that is get_city_resource(slug, resource=<type>)), plus a small live highlights snapshot (current weather, air quality and train departures). Data types not yet covered for this city show where they ARE available so you can pivot. InfraNode keeps adding data and cities, so the catalog grows over time. Read-only.

ParametersJSON Schema

Name	Required	Description	Default
`slug`	Yes	City identifier, e.g. 'berlin' or 'hamburg'. Resolved leniently: the German name with or without umlauts, any casing, a common English exonym or short form also works (München/munich/munchen -> muenchen, cologne -> koeln, frankfurt -> frankfurt-am-main). An unknown name returns 404 with a 'Meintest du ...?' suggestion. list_cities gives the canonical slugs.

Output Schema

ParametersJSON Schema

Name	Required	Description
`data`	Yes
`meta`	Yes

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, open-world), and the description adds substantial behavior beyond them: uncovered data types report where they ARE available so the agent can pivot, the catalog grows over time as cities/data are added, and the highlights snapshot is only a small subset of live data. This is real operational context for deciding whether one call suffices.

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?

Front-loaded with the core proposition and 'Start here', with the return payload immediately after. The long parenthetical enumeration of ~18 data types out of 80 is somewhat padded, though it does convey breadth; a shorter 'weather, transit, demographics, ...and 60 more' would earn the same understanding.

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?

An output schema exists so return values needn't be detailed, yet the description still frames what the catalog contains and how to act on it, plus the coverage-gap pivot behavior. For a single-parameter, read-only discovery tool, nothing an agent needs 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 description coverage is 100% and the slug field already documents lenient resolution, umlaut/casing/exonym handling, and the 404 'Meintest du ...?' suggestion. The description only references the slug incidentally in the get_city_resource signature, so it adds little beyond the schema — 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 ('get a ONE-CALL overview of everything InfraNode knows about a German city') and enumerates the concrete payload: base data, a catalog of 80 data types with coverage status, next-step tool names, and a live highlights snapshot. It is clearly distinguished from siblings get_city (base data only) and get_city_resource (single data type), so an agent can choose without opening schemas.

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?

'Start here for any city question' is an explicit entry-point instruction, and it routes onward by naming get_city_resource(slug, resource=<type>) as the follow-up for most data types, plus list_cities for slugs. There is no explicit when-not statement (e.g. skip this if you already know the exact data type), which keeps it just short of a 5.

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

get_city_resourceCity Data by TypeA

Read-onlyIdempotent

Inspect

Fetch ANY per-city data type by its key (generic accessor, 80 data types).

One tool for the whole breadth of InfraNode: live data (air, traffic, transit stops, parking, charging, water-level, flood, sharing, fuel-prices, station-departures/-arrivals/stations, ...), statistics (demographics, unemployment, tourism, accidents, crime-stats, indicators, land-values, tax-rates, insolvencies, ...), multi-year TIME SERIES (sustainability: SDG indicators per municipality, one value per year from 2006 to 2023, so trends can be answered without stitching snapshots), infrastructure and environment (solar, solar-roofs, district-heating, energy, heritage, tree-cadastre, playgrounds, public-toilets, markets, education, ...) and more. Discover the valid keys and per-city coverage with get_city_overview(slug) or the infranode://catalog resource; the resource enum lists every key. Uncovered types return source_status="not_covered" (plus where they ARE available), never an error. Read-only.

ParametersJSON Schema

Name	Required	Description	Default
`slug`	Yes	City identifier, e.g. 'berlin' or 'hamburg'. Resolved leniently: the German name with or without umlauts, any casing, a common English exonym or short form also works (München/munich/munchen -> muenchen, cologne -> koeln, frankfurt -> frankfurt-am-main). An unknown name returns 404 with a 'Meintest du ...?' suggestion. list_cities gives the canonical slugs.
`resource`	Yes	Data type key to fetch, exactly as listed by get_city_overview / the infranode://catalog resource (the 'type' field), e.g. 'charging', 'parking', 'demographics', 'solar', 'district-heating'.

Output Schema

ParametersJSON Schema

Name	Required	Description
`data`	Yes
`meta`	Yes

TDQS

A3.7/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, open-world behavior, so the description's 'Read-only' adds nothing. The genuinely valuable additions are the disclosed outcome semantics: uncovered types return source_status="not_covered" with where the data IS available, and never raise an error. That is real behavioral context an agent needs, beyond what annotations provide.

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?

The opening sentence is front-loaded and states the core contract immediately. The long parenthetical inventory of data types and trailing 'and more' is somewhat padded, but it earns its place by aiding discovery given the 80-key enum. Slightly verbose but well ordered.

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 values, and it correctly focuses on the routing/discovery story: which keys exist, how to find them, and how uncovered types behave. The missing piece is disambiguation from the overlapping specialized siblings, which for a catch-all tool is the one thing an agent most needs.

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 resource enum enumerates all keys, so the schema already carries parameter meaning. The description reinforces that keys match the 'type' field from get_city_overview/the catalog and that the enum lists every key, but adds no syntax or format detail beyond the schema. 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 and resource ('Fetch ANY per-city data type by its key') and characterizes itself as a generic accessor spanning live data, statistics, time series, and infrastructure. It clearly identifies itself as the broad catch-all, but it does not resolve overlap with siblings that cover the same domains (air_quality, weather, transit_departures, pois), leaving the agent to guess when the specialized tool is preferable.

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 tells the agent to discover valid keys via get_city_overview(slug) or the infranode://catalog resource, which is useful navigation, and notes that uncovered types return source_status="not_covered" rather than an error. However, it never states when to prefer this generic accessor over the specialized siblings (air_quality, weather, station boards), so the usage boundary is only implied.

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

list_citiesList CitiesA

Read-onlyIdempotent

Inspect

List all covered cities (slug, federal state, population, coverage).

Takes no arguments. Call this first to discover valid city slugs before invoking any city-scoped tool. Read-only.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`data`	Yes
`meta`	Yes

TDQS

A4.7/5.0

Behavior4/5

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

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds the behavioral trait that the tool returns slug, federal state, population, and coverage – context not in the annotations. It also states it takes no arguments, which matches the schema. The only minor gap is not explicitly confirming the return format (e.g., array of objects), but the output schema likely handles that.

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?

The description is four short sentences, each earning its place. The first sentence states purpose and output. The second and third sentences give usage guidance. The fourth confirms safety. No wasted words.

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?

Given zero parameters, full annotation coverage, and a provided output schema, the description is complete. It tells the agent what the tool does, what it returns, how to use it (call first, no args), and why it's important (discovery for city-slug-dependent tools). No gaps remain.

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 description coverage is 100% and there are zero parameters, so the baseline is 4. The description correctly confirms no arguments are needed, which adds value by reinforcing the schema's emptiness and explaining the tool's role in the workflow.

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?

The description uses a clear verb ('List') and specifies the resource ('all covered cities'). It explicitly states the fields returned (slug, federal state, population, coverage), distinguishing it from sibling tools that likely operate on a single city (e.g., get_city) or require a city slug as input.

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?

The description provides explicit guidance: it takes no arguments and should be called first to discover valid city slugs before invoking any city-scoped tool. This clearly tells the agent when to use it (initial discovery) and for what purpose (obtaining slugs for subsequent tools), effectively differentiating it from all sibling tools that require a city parameter.

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

poisPoints of InterestA

Read-onlyIdempotent

Inspect

Get points of interest in a German city, filtered by type.

Sourced from OpenStreetMap. Read-only.

ParametersJSON Schema

Name	Required	Description	Default
`slug`	Yes	City identifier, e.g. 'berlin' or 'hamburg'. Resolved leniently: the German name with or without umlauts, any casing, a common English exonym or short form also works (München/munich/munchen -> muenchen, cologne -> koeln, frankfurt -> frankfurt-am-main). An unknown name returns 404 with a 'Meintest du ...?' suggestion. list_cities gives the canonical slugs.
`type`	Yes	POI type from the API allowlist, one of: hospital, school, pharmacy, restaurant, police, kindergarten.

Output Schema

ParametersJSON Schema

Name	Required	Description
`data`	Yes
`meta`	Yes

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint as false, so the description only needs to add context. It adds 'Sourced from OpenStreetMap' and 'Read-only', which reinforces the non-destructive nature and provides data provenance. No contradictions with annotations.

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?

The description is extremely concise with two short sentences plus a two-word sentence, all front-loaded with the core functionality. Every sentence provides essential information without redundancy or filler.

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?

Given the tool's simplicity (2 parameters, high schema coverage, clear annotations, and an output schema), the description is complete enough. It covers the main action, optional filtering, and data origin. One could argue it lacks explanation of the output format, but the presence of an output schema mitigates that need.

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 meaning by explaining that 'slug' is resolved leniently (umlauts, exonyms) and mentions a helpful error suggestion, and that 'type' is from an API allowlist with examples – going beyond the schema's basic parameter 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 clearly states 'Get points of interest in a German city, filtered by type', specifying the verb 'get' with resource 'points of interest' and scoping to German cities with type filtering. It differentiates from siblings like 'get_city' and 'list_cities' by focusing on POIs, though it does not explicitly distinguish from other location-based 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 provides context for when to use (getting POIs by city and type) but offers no guidance on when not to use it or alternatives. Sibling tools like 'compare' or 'sources' could serve different purposes, but no exclusions are mentioned.

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

sourcesData SourcesA

Read-onlyIdempotent

Inspect

List all data sources with license, attribution and availability.

Takes no arguments. Shows which upstream sources InfraNode bundles and whether each is currently active. Read-only.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`data`	Yes
`meta`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already provide readOnlyHint, destructiveHint, idempotentHint. The description adds that it 'shows which upstream sources InfraNode bundles and whether each is currently active,' which gives useful behavioral context beyond annotations. No contradiction.

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?

The description is three short sentences with no redundancy. Every sentence adds value: first states what is listed, second confirms no arguments, third adds behavioral insight.

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?

Given 0 parameters, rich annotations, and presence of output schema (which will describe return structure), the description covers all essential behavioral aspects: data listed, argument needs, purpose. Complete for this simple tool.

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?

Input schema has 0 parameters, so no parameter documentation is needed. The description's claim 'takes no arguments' is basic but sufficient confirmation for the agent.

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?

The description clearly states the tool lists data sources and specifies the included attributes (license, attribution, availability). It distinguishes itself from sibling tools like 'air_quality' or 'weather' which likely access specific data, not the source catalog.

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?

The description says 'takes no arguments,' which sets boundaries. However, it does not explicitly state when to use this tool instead of siblings, e.g., to discover available datasets before querying specific ones. The 'read-only' note subtly implies safe usage.

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

station_board_arrivalsStation Board: ArrivalsA

Read-onlyIdempotent

Inspect

Get live arrivals for ANY railway station by its EVA number.

Mirror of station_board_departures for arriving trains (all categories, real-time delays, disruption messages). Get the EVA from get_city_resource(slug, resource='stations'). Read-only.

ParametersJSON Schema

Name	Required	Description	Default
`eva`	Yes	Station EVA number (digits only) from get_city_resource(slug, resource='stations'), e.g. '8000105' (Frankfurt Hbf).

Output Schema

ParametersJSON Schema

Name	Required	Description
`data`	Yes
`meta`	Yes

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds valuable behavioral context beyond annotations: it specifies the feed includes all train categories, real-time delays, and disruption messages. No contradictions with annotations are present.

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, focused sentences. First sentence states the core purpose with emphasis on any station. Second clarifies the sibling relationship. Third provides a prerequisite. No unnecessary words; every sentence earns its place.

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?

Given the tool has a single parameter, full schema coverage, an output schema (not shown but present), and comprehensive annotations, the description provides sufficient context. It covers data type (live arrivals), scope (any station), supported features (delays, disruptions), and how to get the required input.

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% with a detailed parameter description. The description adds further value by explicitly instructing how to obtain the EVA number from 'get_city_resource', which is a helpful cross-reference that goes beyond the schema's own explanation.

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?

The title 'Station Board: Arrivals' and description clearly state the tool retrieves live arrivals for railway stations by EVA number. It explicitly distinguishes itself from the sibling 'station_board_departures' by calling itself its mirror for arriving trains, making purpose and differentiation unmistakable.

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?

The description explicitly states when to use: to get live arrivals. It contrasts with departures by referencing the mirror relationship, advises on obtaining the EVA parameter via 'get_city_resource', and declares the tool read-only. This provides clear usage context and alternatives.

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

station_board_departuresStation Board: DeparturesA

Read-onlyIdempotent

Inspect

Get live departures for ANY railway station by its EVA number.

Covers all train categories including local/regional (S/RB/RE) and long distance, with real-time delays, cancellations and disruption messages. Get the EVA from get_city_resource(slug, resource='stations'). Read-only.

ParametersJSON Schema

Name	Required	Description	Default
`eva`	Yes	Station EVA number (digits only) from get_city_resource(slug, resource='stations'), e.g. '8011160' (Berlin Hbf).

Output Schema

ParametersJSON Schema

Name	Required	Description
`data`	Yes
`meta`	Yes

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. Description adds context about real-time delays, cancellations, and disruption messages, and states 'Read-only', which is consistent. It provides extra behavioral context beyond what annotations convey.

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 with no wasted words. First sentence states purpose, second adds coverage details, third provides parameter sourcing. Information is front-loaded and every sentence earns its place.

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?

Given the single parameter with high schema coverage, an output schema (present), and rich annotations, the description is fully sufficient. It covers the tool's purpose, data scope, and parameter retrieval without gaps.

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%, so baseline is 3. The description reiterates how to get the EVA number from get_city_resource, which the schema already includes. No new parameter semantics are added beyond the schema.

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?

Description clearly states 'Get live departures for ANY railway station by its EVA number', specifying a specific verb and resource. It distinguishes from sibling 'station_board_arrivals' by focusing on departures, and covers train categories and real-time data, leaving no ambiguity.

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?

Description explains when to use (get live departures) and how to obtain the required parameter from another tool. However, it does not explicitly differentiate from siblings like 'transit_departures' or state when not to use this tool, leaving room for confusion about alternatives.

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

transit_departuresTransit DeparturesA

Read-onlyIdempotent

Inspect

Get live public-transport departures with real-time delays for a stop.

Sourced from GTFS-RT/HVV/VGN. Unlike the static stop list (get_city_resource(slug, resource='transit')), this returns minute-fresh departures including delay for ONE stop. A stop_id is required: fetch the city's transit stops first to discover valid stop IDs, then pass one here. Read-only.

ParametersJSON Schema

Name	Required	Description	Default
`slug`	Yes	City identifier, e.g. 'berlin' or 'hamburg'. Resolved leniently: the German name with or without umlauts, any casing, a common English exonym or short form also works (München/munich/munchen -> muenchen, cologne -> koeln, frankfurt -> frankfurt-am-main). An unknown name returns 404 with a 'Meintest du ...?' suggestion. list_cities gives the canonical slugs.
`stop_id`	No	Required stop ID to fetch departures for. Discover a city's stop IDs with get_city_resource(slug, resource='transit') first (each stop carries its id). Format: DELFI 'de:<AGS>:<id>' or a numeric gtfs.de stop id. NOTE: this is NOT the trip_stop_id (nor its deprecated alias stop_id) from station_departures/station_arrivals, whose value identifies one stop of one train run (e.g. '-1203677609210685804-2607251113-13'); passing it returns no_data with a corrective note instead of departures.

Output Schema

ParametersJSON Schema

Name	Required	Description
`data`	Yes
`meta`	Yes

TDQS

A5/5.0

Behavior5/5

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

Beyond annotations (readOnly, destructive, idempotent), the description adds: data source (GTFS-RT/HVV/VGN), clarifies it returns minute-fresh data, and warns about incorrect stop_id formats (not trip_stop_id). This adds valuable behavioral context beyond what annotations already declare.

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 concise sentences that front-load purpose, then provide context and usage. Every sentence adds value with no redundancy.

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?

Given an output schema exists (so return values are covered), the description thoroughly explains the tool's purpose, data source, prerequisite steps, and common pitfalls. Sibling tools are provided for differentiation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds critical context: stop_id is required despite default null, explains how to obtain valid stop IDs, and includes a detailed note on what NOT to pass (trip_stop_id). This goes beyond the schema's own descriptions.

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?

The description clearly states 'Get live public-transport departures with real-time delays for a stop', specifying the verb (get), resource (departures), and scope (one stop). It distinguishes itself from siblings like `get_city_resource(resource='transit')` by contrasting static vs live data.

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 tells when to use this tool vs. the static stop list via `get_city_resource`. It also provides a prerequisite: 'fetch the city's transit stops first to discover valid stop IDs, then pass one here.' No guidance on when not to use, but the sibling list includes other journey tools, and the description clearly sets scope.

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

weatherWeatherA

Read-onlyIdempotent

Inspect

Get current weather observations for a German city.

Sourced from the Deutscher Wetterdienst (DWD): temperature, wind, precipitation and related fields. Read-only, current conditions only (not a forecast). For warnings use get_city_resource(slug, resource='weather-warnings'). For a broader question about the city (not just weather) use get_city_overview instead, which already includes a live weather highlight.

ParametersJSON Schema

Name	Required	Description	Default
`slug`	Yes	City identifier, e.g. 'berlin' or 'hamburg'. Resolved leniently: the German name with or without umlauts, any casing, a common English exonym or short form also works (München/munich/munchen -> muenchen, cologne -> koeln, frankfurt -> frankfurt-am-main). An unknown name returns 404 with a 'Meintest du ...?' suggestion. list_cities gives the canonical slugs.

Output Schema

ParametersJSON Schema

Name	Required	Description
`data`	Yes
`meta`	Yes

TDQS

A4.5/5.0

Behavior3/5

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

Annotations already provide strong behavioral cues: readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds value by confirming it's read-only and specifying 'current conditions only (not a forecast)', but doesn't elaborate on rate limits, response size, or any edge cases beyond what annotations imply. With such comprehensive annotations, the description's added behavioral context is moderate.

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?

The description is compact (three sentences), front-loads the core purpose in the first sentence, and uses clear, direct language. Every sentence serves a distinct purpose: defining the tool, clarifying scope, and providing usage guidance with alternatives. No wasted words.

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?

Given the tool has only one required parameter, comprehensive annotations, and an output schema (context signal), the description covers all essential aspects: purpose, data source, scope, and alternatives. It is fully adequate for an agent to decide when and how to invoke this tool 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%, meaning the `slug` parameter is well-documented in the schema itself. The description reinforces this with concrete examples and resolves leniency details (umlauts, English exonyms), which adds meaningful nuance beyond the schema's basic description. The extra context about error handling (404 with suggestion) further enriches parameter understanding.

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?

The description clearly states the tool gets current weather observations for a German city, specifies the data source (Deutscher Wetterdienst) and the fields (temperature, wind, precipitation). It distinguishes this from a forecast tool, and the verb 'Get' combined with 'current weather observations' precisely describes the 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?

The description explicitly states when to use this tool (for current weather) and provides concrete alternatives: for weather warnings use get_city_resource, for a broader city overview use get_city_overview. This clearly guides the agent away from misuse, especially given the sibling tools listed.

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.

1 tool updateOct 18, 2026

Changedget_city_resource1 field changed

changedInput schema / properties / resource / enum

Previous value: -[
-  "accidents",
-  "air",
-  "air-uba",
-  "base",
-  "bathing-water",
-  "bike-counts",
-  "bike-parking",
-  "business-registrations",
-  "care",
-  "charging",
-  "charging-status",
-  "childcare",
-  "civil-protection-warnings",
-  "construction",
-  "council-papers",
-  "crime-stats",
-  "demographics",
-  "district-heating",
-  "drinking-water",
-  "education",
-  "education-stats",
-  "election",
-  "energy",
-  "events",
-  "fire-danger",
-  "flood",
-  "fuel-prices",
-  "geo",
-  "government-offices",
-  "health",
-  "heritage",
-  "holidays",
-  "hospitals-atlas",
-  "indicators",
-  "insolvencies",
-  "integration",
-  "labour-market",
-  "land-values",
-  "markets",
-  "mobility-points",
-  "municipal-finance",
-  "office-wait-times",
-  "overview",
-  "parcel-lockers",
-  "park-and-ride",
-  "parking",
-  "parking-onstreet",
-  "playgrounds",
-  "pollen-uv",
-  "population-density",
-  "population-structure",
-  "population-trend",
-  "post-boxes",
-  "post-offices",
-  "power-load",
-  "power-price",
-  "public-tenders",
-  "public-toilets",
-  "public-wifi",
-  "recycling-centres",
-  "road-events",
-  "sharing",
-  "social-situation",
-  "solar",
-  "solar-roofs",
-  "station-arrivals",
-  "station-departures",
-  "station-facilities",
-  "stations",
-  "sustainability",
-  "tax-rates",
-  "tourism",
-  "traffic",
-  "transit",
-  "tree-cadastre",
-  "unemployment",
-  "vehicle-registrations",
-  "water-level",
-  "weather",
-  "weather-warnings",
-  "webcams"
-]New value: +[
+  "accidents",
+  "air",
+  "air-uba",
+  "base",
+  "bathing-water",
+  "bike-counts",
+  "bike-parking",
+  "business-registrations",
+  "care",
+  "charging",
+  "charging-status",
+  "childcare",
+  "civil-protection-warnings",
+  "construction",
+  "council-papers",
+  "crime-stats",
+  "demographics",
+  "district-heating",
+  "drinking-water",
+  "education",
+  "education-stats",
+  "election",
+  "energy",
+  "events",
+  "fire-danger",
+  "flood",
+  "fuel-prices",
+  "geo",
+  "government-offices",
+  "health",
+  "heritage",
+  "holidays",
+  "hospitals-atlas",
+  "indicators",
+  "insolvencies",
+  "integration",
+  "labour-market",
+  "land-values",
+  "markets",
+  "mobility-points",
+  "municipal-finance",
+  "office-wait-times",
+  "overview",
+  "parcel-lockers",
+  "park-and-ride",
+  "parking",
+  "parking-onstreet",
+  "playgrounds",
+  "pollen-uv",
+  "population-density",
+  "population-structure",
+  "population-trend",
+  "post-boxes",
+  "post-offices",
+  "power-load",
+  "power-price",
+  "public-tenders",
+  "public-toilets",
+  "public-wifi",
+  "recycling-centres",
+  "road-events",
+  "sharing",
+  "social-situation",
+  "solar",
+  "solar-roofs",
+  "station-arrivals",
+  "station-departures",
+  "station-facilities",
+  "stations",
+  "sustainability",
+  "tax-rates",
+  "tourism",
+  "traffic",
+  "transit",
+  "tree-cadastre",
+  "unemployment",
+  "vehicle-registrations",
+  "water-level",
+  "weather",
+  "weather-warnings"
+]

12 tool updatesAug 17, 2026
- Changedair_quality1 field changed
  - addedOutput schema / $defs / ToolMeta / properties / note
```
Added value: +{
+  "type": "string"
+}
```
- Changedcompare1 field changed
  - addedOutput schema / $defs / ToolMeta / properties / note
```
Added value: +{
+  "type": "string"
+}
```
- Changedget_city1 field changed
  - addedOutput schema / $defs / ToolMeta / properties / note
```
Added value: +{
+  "type": "string"
+}
```
- Changedget_city_overview1 field changed
  - addedOutput schema / $defs / ToolMeta / properties / note
```
Added value: +{
+  "type": "string"
+}
```
- Changedget_city_resource1 field changed
  - addedOutput schema / $defs / ToolMeta / properties / note
```
Added value: +{
+  "type": "string"
+}
```
- Changedlist_cities1 field changed
  - addedOutput schema / $defs / ToolMeta / properties / note
```
Added value: +{
+  "type": "string"
+}
```
- Changedpois1 field changed
  - addedOutput schema / $defs / ToolMeta / properties / note
```
Added value: +{
+  "type": "string"
+}
```
- Changedsources1 field changed
  - addedOutput schema / $defs / ToolMeta / properties / note
```
Added value: +{
+  "type": "string"
+}
```
- Changedstation_board_arrivals1 field changed
  - addedOutput schema / $defs / ToolMeta / properties / note
```
Added value: +{
+  "type": "string"
+}
```
- Changedstation_board_departures1 field changed
  - addedOutput schema / $defs / ToolMeta / properties / note
```
Added value: +{
+  "type": "string"
+}
```
- Changedtransit_departures1 field changed
  - addedOutput schema / $defs / ToolMeta / properties / note
```
Added value: +{
+  "type": "string"
+}
```
- Changedweather1 field changed
  - addedOutput schema / $defs / ToolMeta / properties / note
```
Added value: +{
+  "type": "string"
+}
```

1 tool updateAug 11, 2026

Changedget_city_resource1 field changed

changedInput schema / properties / resource / enum

Previous value: -[
-  "accidents",
-  "air",
-  "air-uba",
-  "base",
-  "bathing-water",
-  "bike-counts",
-  "bike-parking",
-  "business-registrations",
-  "care",
-  "charging",
-  "charging-status",
-  "childcare",
-  "civil-protection-warnings",
-  "construction",
-  "council-papers",
-  "crime-stats",
-  "demographics",
-  "district-heating",
-  "drinking-water",
-  "education",
-  "education-stats",
-  "election",
-  "energy",
-  "events",
-  "fire-danger",
-  "flood",
-  "fuel-prices",
-  "geo",
-  "government-offices",
-  "health",
-  "heritage",
-  "holidays",
-  "hospitals-atlas",
-  "icu-live",
-  "indicators",
-  "insolvencies",
-  "integration",
-  "labour-market",
-  "land-values",
-  "markets",
-  "mobility-points",
-  "municipal-finance",
-  "office-wait-times",
-  "overview",
-  "parcel-lockers",
-  "park-and-ride",
-  "parking",
-  "parking-onstreet",
-  "playgrounds",
-  "pollen-uv",
-  "population-density",
-  "population-structure",
-  "population-trend",
-  "post-boxes",
-  "post-offices",
-  "power-load",
-  "power-price",
-  "public-tenders",
-  "public-toilets",
-  "public-wifi",
-  "recycling-centres",
-  "road-events",
-  "sharing",
-  "social-situation",
-  "solar",
-  "solar-roofs",
-  "station-arrivals",
-  "station-departures",
-  "station-facilities",
-  "stations",
-  "sustainability",
-  "tax-rates",
-  "tourism",
-  "traffic",
-  "transit",
-  "tree-cadastre",
-  "unemployment",
-  "vehicle-registrations",
-  "water-level",
-  "weather",
-  "weather-warnings",
-  "webcams"
-]New value: +[
+  "accidents",
+  "air",
+  "air-uba",
+  "base",
+  "bathing-water",
+  "bike-counts",
+  "bike-parking",
+  "business-registrations",
+  "care",
+  "charging",
+  "charging-status",
+  "childcare",
+  "civil-protection-warnings",
+  "construction",
+  "council-papers",
+  "crime-stats",
+  "demographics",
+  "district-heating",
+  "drinking-water",
+  "education",
+  "education-stats",
+  "election",
+  "energy",
+  "events",
+  "fire-danger",
+  "flood",
+  "fuel-prices",
+  "geo",
+  "government-offices",
+  "health",
+  "heritage",
+  "holidays",
+  "hospitals-atlas",
+  "indicators",
+  "insolvencies",
+  "integration",
+  "labour-market",
+  "land-values",
+  "markets",
+  "mobility-points",
+  "municipal-finance",
+  "office-wait-times",
+  "overview",
+  "parcel-lockers",
+  "park-and-ride",
+  "parking",
+  "parking-onstreet",
+  "playgrounds",
+  "pollen-uv",
+  "population-density",
+  "population-structure",
+  "population-trend",
+  "post-boxes",
+  "post-offices",
+  "power-load",
+  "power-price",
+  "public-tenders",
+  "public-toilets",
+  "public-wifi",
+  "recycling-centres",
+  "road-events",
+  "sharing",
+  "social-situation",
+  "solar",
+  "solar-roofs",
+  "station-arrivals",
+  "station-departures",
+  "station-facilities",
+  "stations",
+  "sustainability",
+  "tax-rates",
+  "tourism",
+  "traffic",
+  "transit",
+  "tree-cadastre",
+  "unemployment",
+  "vehicle-registrations",
+  "water-level",
+  "weather",
+  "weather-warnings",
+  "webcams"
+]

1 tool updateAug 1, 2026

Changedget_city_resource1 field changed

changedInput schema / properties / resource / enum

Previous value: -[
-  "accidents",
-  "air",
-  "air-uba",
-  "base",
-  "bathing-water",
-  "bike-counts",
-  "business-registrations",
-  "care",
-  "charging",
-  "charging-status",
-  "childcare",
-  "civil-protection-warnings",
-  "construction",
-  "council-papers",
-  "crime-stats",
-  "demographics",
-  "district-heating",
-  "drinking-water",
-  "education",
-  "education-stats",
-  "election",
-  "energy",
-  "events",
-  "fire-danger",
-  "flood",
-  "fuel-prices",
-  "geo",
-  "government-offices",
-  "health",
-  "heritage",
-  "holidays",
-  "hospitals-atlas",
-  "icu-live",
-  "indicators",
-  "insolvencies",
-  "integration",
-  "labour-market",
-  "land-values",
-  "markets",
-  "mobility-points",
-  "municipal-finance",
-  "office-wait-times",
-  "overview",
-  "parcel-lockers",
-  "park-and-ride",
-  "parking",
-  "parking-onstreet",
-  "playgrounds",
-  "pollen-uv",
-  "population-density",
-  "population-structure",
-  "population-trend",
-  "post-boxes",
-  "post-offices",
-  "power-load",
-  "power-price",
-  "public-tenders",
-  "public-toilets",
-  "public-wifi",
-  "recycling-centres",
-  "road-events",
-  "sharing",
-  "social-situation",
-  "solar",
-  "solar-roofs",
-  "station-arrivals",
-  "station-departures",
-  "station-facilities",
-  "stations",
-  "sustainability",
-  "tax-rates",
-  "tourism",
-  "traffic",
-  "transit",
-  "tree-cadastre",
-  "unemployment",
-  "vehicle-registrations",
-  "water-level",
-  "weather",
-  "weather-warnings",
-  "webcams"
-]New value: +[
+  "accidents",
+  "air",
+  "air-uba",
+  "base",
+  "bathing-water",
+  "bike-counts",
+  "bike-parking",
+  "business-registrations",
+  "care",
+  "charging",
+  "charging-status",
+  "childcare",
+  "civil-protection-warnings",
+  "construction",
+  "council-papers",
+  "crime-stats",
+  "demographics",
+  "district-heating",
+  "drinking-water",
+  "education",
+  "education-stats",
+  "election",
+  "energy",
+  "events",
+  "fire-danger",
+  "flood",
+  "fuel-prices",
+  "geo",
+  "government-offices",
+  "health",
+  "heritage",
+  "holidays",
+  "hospitals-atlas",
+  "icu-live",
+  "indicators",
+  "insolvencies",
+  "integration",
+  "labour-market",
+  "land-values",
+  "markets",
+  "mobility-points",
+  "municipal-finance",
+  "office-wait-times",
+  "overview",
+  "parcel-lockers",
+  "park-and-ride",
+  "parking",
+  "parking-onstreet",
+  "playgrounds",
+  "pollen-uv",
+  "population-density",
+  "population-structure",
+  "population-trend",
+  "post-boxes",
+  "post-offices",
+  "power-load",
+  "power-price",
+  "public-tenders",
+  "public-toilets",
+  "public-wifi",
+  "recycling-centres",
+  "road-events",
+  "sharing",
+  "social-situation",
+  "solar",
+  "solar-roofs",
+  "station-arrivals",
+  "station-departures",
+  "station-facilities",
+  "stations",
+  "sustainability",
+  "tax-rates",
+  "tourism",
+  "traffic",
+  "transit",
+  "tree-cadastre",
+  "unemployment",
+  "vehicle-registrations",
+  "water-level",
+  "weather",
+  "weather-warnings",
+  "webcams"
+]

1 tool updateJul 29, 2026

Changedget_city_resource1 field changed

changedInput schema / properties / resource / enum

Previous value: -[
-  "accidents",
-  "air",
-  "air-uba",
-  "base",
-  "bathing-water",
-  "bike-counts",
-  "business-registrations",
-  "care",
-  "charging",
-  "charging-status",
-  "childcare",
-  "civil-protection-warnings",
-  "construction",
-  "council-papers",
-  "crime-stats",
-  "demographics",
-  "district-heating",
-  "drinking-water",
-  "education",
-  "education-stats",
-  "election",
-  "energy",
-  "events",
-  "fire-danger",
-  "flood",
-  "fuel-prices",
-  "geo",
-  "government-offices",
-  "health",
-  "heritage",
-  "holidays",
-  "hospitals-atlas",
-  "icu-live",
-  "indicators",
-  "insolvencies",
-  "integration",
-  "labour-market",
-  "land-values",
-  "markets",
-  "municipal-finance",
-  "office-wait-times",
-  "overview",
-  "parcel-lockers",
-  "parking",
-  "playgrounds",
-  "pollen-uv",
-  "population-density",
-  "population-structure",
-  "population-trend",
-  "post-boxes",
-  "post-offices",
-  "power-load",
-  "power-price",
-  "public-tenders",
-  "public-toilets",
-  "public-wifi",
-  "recycling-centres",
-  "road-events",
-  "sharing",
-  "social-situation",
-  "solar",
-  "solar-roofs",
-  "station-arrivals",
-  "station-departures",
-  "station-facilities",
-  "stations",
-  "sustainability",
-  "tax-rates",
-  "tourism",
-  "traffic",
-  "transit",
-  "tree-cadastre",
-  "unemployment",
-  "vehicle-registrations",
-  "water-level",
-  "weather",
-  "weather-warnings",
-  "webcams"
-]New value: +[
+  "accidents",
+  "air",
+  "air-uba",
+  "base",
+  "bathing-water",
+  "bike-counts",
+  "business-registrations",
+  "care",
+  "charging",
+  "charging-status",
+  "childcare",
+  "civil-protection-warnings",
+  "construction",
+  "council-papers",
+  "crime-stats",
+  "demographics",
+  "district-heating",
+  "drinking-water",
+  "education",
+  "education-stats",
+  "election",
+  "energy",
+  "events",
+  "fire-danger",
+  "flood",
+  "fuel-prices",
+  "geo",
+  "government-offices",
+  "health",
+  "heritage",
+  "holidays",
+  "hospitals-atlas",
+  "icu-live",
+  "indicators",
+  "insolvencies",
+  "integration",
+  "labour-market",
+  "land-values",
+  "markets",
+  "mobility-points",
+  "municipal-finance",
+  "office-wait-times",
+  "overview",
+  "parcel-lockers",
+  "park-and-ride",
+  "parking",
+  "parking-onstreet",
+  "playgrounds",
+  "pollen-uv",
+  "population-density",
+  "population-structure",
+  "population-trend",
+  "post-boxes",
+  "post-offices",
+  "power-load",
+  "power-price",
+  "public-tenders",
+  "public-toilets",
+  "public-wifi",
+  "recycling-centres",
+  "road-events",
+  "sharing",
+  "social-situation",
+  "solar",
+  "solar-roofs",
+  "station-arrivals",
+  "station-departures",
+  "station-facilities",
+  "stations",
+  "sustainability",
+  "tax-rates",
+  "tourism",
+  "traffic",
+  "transit",
+  "tree-cadastre",
+  "unemployment",
+  "vehicle-registrations",
+  "water-level",
+  "weather",
+  "weather-warnings",
+  "webcams"
+]

1 tool updateJul 28, 2026

Changedget_city_resource1 field changed

changedInput schema / properties / resource / enum

Previous value: -[
-  "accidents",
-  "air",
-  "air-uba",
-  "base",
-  "bathing-water",
-  "bike-counts",
-  "business-registrations",
-  "charging",
-  "charging-status",
-  "civil-protection-warnings",
-  "construction",
-  "council-papers",
-  "crime-stats",
-  "demographics",
-  "district-heating",
-  "drinking-water",
-  "education",
-  "election",
-  "energy",
-  "events",
-  "fire-danger",
-  "flood",
-  "fuel-prices",
-  "geo",
-  "government-offices",
-  "health",
-  "heritage",
-  "holidays",
-  "hospitals-atlas",
-  "icu-live",
-  "indicators",
-  "insolvencies",
-  "land-values",
-  "markets",
-  "office-wait-times",
-  "overview",
-  "parcel-lockers",
-  "parking",
-  "playgrounds",
-  "pollen-uv",
-  "population-density",
-  "post-boxes",
-  "post-offices",
-  "power-load",
-  "power-price",
-  "public-tenders",
-  "public-toilets",
-  "public-wifi",
-  "recycling-centres",
-  "road-events",
-  "sharing",
-  "solar",
-  "solar-roofs",
-  "station-arrivals",
-  "station-departures",
-  "station-facilities",
-  "stations",
-  "sustainability",
-  "tax-rates",
-  "tourism",
-  "traffic",
-  "transit",
-  "tree-cadastre",
-  "unemployment",
-  "vehicle-registrations",
-  "water-level",
-  "weather",
-  "weather-warnings",
-  "webcams"
-]New value: +[
+  "accidents",
+  "air",
+  "air-uba",
+  "base",
+  "bathing-water",
+  "bike-counts",
+  "business-registrations",
+  "care",
+  "charging",
+  "charging-status",
+  "childcare",
+  "civil-protection-warnings",
+  "construction",
+  "council-papers",
+  "crime-stats",
+  "demographics",
+  "district-heating",
+  "drinking-water",
+  "education",
+  "education-stats",
+  "election",
+  "energy",
+  "events",
+  "fire-danger",
+  "flood",
+  "fuel-prices",
+  "geo",
+  "government-offices",
+  "health",
+  "heritage",
+  "holidays",
+  "hospitals-atlas",
+  "icu-live",
+  "indicators",
+  "insolvencies",
+  "integration",
+  "labour-market",
+  "land-values",
+  "markets",
+  "municipal-finance",
+  "office-wait-times",
+  "overview",
+  "parcel-lockers",
+  "parking",
+  "playgrounds",
+  "pollen-uv",
+  "population-density",
+  "population-structure",
+  "population-trend",
+  "post-boxes",
+  "post-offices",
+  "power-load",
+  "power-price",
+  "public-tenders",
+  "public-toilets",
+  "public-wifi",
+  "recycling-centres",
+  "road-events",
+  "sharing",
+  "social-situation",
+  "solar",
+  "solar-roofs",
+  "station-arrivals",
+  "station-departures",
+  "station-facilities",
+  "stations",
+  "sustainability",
+  "tax-rates",
+  "tourism",
+  "traffic",
+  "transit",
+  "tree-cadastre",
+  "unemployment",
+  "vehicle-registrations",
+  "water-level",
+  "weather",
+  "weather-warnings",
+  "webcams"
+]

1 tool updateJul 27, 2026

Changedget_city_resource1 field changed

changedInput schema / properties / resource / enum

Previous value: -[
-  "accidents",
-  "air",
-  "air-uba",
-  "base",
-  "bathing-water",
-  "bike-counts",
-  "business-registrations",
-  "charging",
-  "charging-status",
-  "civil-protection-warnings",
-  "construction",
-  "council-papers",
-  "crime-stats",
-  "demographics",
-  "district-heating",
-  "drinking-water",
-  "education",
-  "election",
-  "energy",
-  "events",
-  "fire-danger",
-  "flood",
-  "fuel-prices",
-  "geo",
-  "government-offices",
-  "health",
-  "heritage",
-  "holidays",
-  "hospitals-atlas",
-  "icu-live",
-  "indicators",
-  "insolvencies",
-  "land-values",
-  "markets",
-  "office-wait-times",
-  "overview",
-  "parcel-lockers",
-  "parking",
-  "playgrounds",
-  "pollen-uv",
-  "population-density",
-  "post-boxes",
-  "post-offices",
-  "power-load",
-  "power-price",
-  "public-tenders",
-  "public-toilets",
-  "public-wifi",
-  "recycling-centres",
-  "road-events",
-  "sharing",
-  "solar",
-  "solar-roofs",
-  "station-arrivals",
-  "station-departures",
-  "station-facilities",
-  "stations",
-  "tax-rates",
-  "tourism",
-  "traffic",
-  "transit",
-  "tree-cadastre",
-  "unemployment",
-  "vehicle-registrations",
-  "water-level",
-  "weather",
-  "weather-warnings",
-  "webcams"
-]New value: +[
+  "accidents",
+  "air",
+  "air-uba",
+  "base",
+  "bathing-water",
+  "bike-counts",
+  "business-registrations",
+  "charging",
+  "charging-status",
+  "civil-protection-warnings",
+  "construction",
+  "council-papers",
+  "crime-stats",
+  "demographics",
+  "district-heating",
+  "drinking-water",
+  "education",
+  "election",
+  "energy",
+  "events",
+  "fire-danger",
+  "flood",
+  "fuel-prices",
+  "geo",
+  "government-offices",
+  "health",
+  "heritage",
+  "holidays",
+  "hospitals-atlas",
+  "icu-live",
+  "indicators",
+  "insolvencies",
+  "land-values",
+  "markets",
+  "office-wait-times",
+  "overview",
+  "parcel-lockers",
+  "parking",
+  "playgrounds",
+  "pollen-uv",
+  "population-density",
+  "post-boxes",
+  "post-offices",
+  "power-load",
+  "power-price",
+  "public-tenders",
+  "public-toilets",
+  "public-wifi",
+  "recycling-centres",
+  "road-events",
+  "sharing",
+  "solar",
+  "solar-roofs",
+  "station-arrivals",
+  "station-departures",
+  "station-facilities",
+  "stations",
+  "sustainability",
+  "tax-rates",
+  "tourism",
+  "traffic",
+  "transit",
+  "tree-cadastre",
+  "unemployment",
+  "vehicle-registrations",
+  "water-level",
+  "weather",
+  "weather-warnings",
+  "webcams"
+]

1 tool updateJul 27, 2026

Changedtransit_departures1 field changed

changedInput schema / properties / stop_id / description

Previous value: -"Required stop ID to fetch departures for. Discover a city's stop IDs with get_city_resource(slug, resource='transit') first (each stop carries its id). Format: DELFI 'de:<AGS>:<id>' or a numeric gtfs.de stop id. NOTE: this is NOT the stop_id from station_departures/station_arrivals, whose value identifies one stop of one train run (e.g. '-1203677609210685804-2607251113-13') and is rejected here with a 400."New value: +"Required stop ID to fetch departures for. Discover a city's stop IDs with get_city_resource(slug, resource='transit') first (each stop carries its id). Format: DELFI 'de:<AGS>:<id>' or a numeric gtfs.de stop id. NOTE: this is NOT the trip_stop_id (nor its deprecated alias stop_id) from station_departures/station_arrivals, whose value identifies one stop of one train run (e.g. '-1203677609210685804-2607251113-13'); passing it returns no_data with a corrective note instead of departures."

1 tool updateJul 25, 2026

Changedtransit_departures1 field changed

changedInput schema / properties / stop_id / description

Previous value: -"Required stop ID to fetch departures for. Discover a city's stop IDs with get_city_resource(slug, resource='transit') first (each stop carries its id). Format: DELFI 'de:<AGS>:<id>' or a numeric gtfs.de stop id."New value: +"Required stop ID to fetch departures for. Discover a city's stop IDs with get_city_resource(slug, resource='transit') first (each stop carries its id). Format: DELFI 'de:<AGS>:<id>' or a numeric gtfs.de stop id. NOTE: this is NOT the stop_id from station_departures/station_arrivals, whose value identifies one stop of one train run (e.g. '-1203677609210685804-2607251113-13') and is rejected here with a 400."

1 tool updateJul 9, 2026

Changedget_city_resource1 field changed

changedInput schema / properties / resource / enum

Previous value: -[
-  "accidents",
-  "air",
-  "air-uba",
-  "base",
-  "bathing-water",
-  "bike-counts",
-  "business-registrations",
-  "charging",
-  "charging-status",
-  "civil-protection-warnings",
-  "construction",
-  "crime-stats",
-  "demographics",
-  "district-heating",
-  "drinking-water",
-  "education",
-  "election",
-  "energy",
-  "events",
-  "fire-danger",
-  "flood",
-  "fuel-prices",
-  "geo",
-  "government-offices",
-  "health",
-  "heritage",
-  "holidays",
-  "hospitals-atlas",
-  "icu-live",
-  "indicators",
-  "insolvencies",
-  "land-values",
-  "markets",
-  "office-wait-times",
-  "overview",
-  "parcel-lockers",
-  "parking",
-  "playgrounds",
-  "pollen-uv",
-  "population-density",
-  "post-boxes",
-  "post-offices",
-  "power-load",
-  "power-price",
-  "public-tenders",
-  "public-toilets",
-  "public-wifi",
-  "recycling-centres",
-  "road-events",
-  "sharing",
-  "solar",
-  "solar-roofs",
-  "station-arrivals",
-  "station-departures",
-  "station-facilities",
-  "stations",
-  "tax-rates",
-  "tourism",
-  "traffic",
-  "transit",
-  "tree-cadastre",
-  "unemployment",
-  "vehicle-registrations",
-  "water-level",
-  "weather",
-  "weather-warnings",
-  "webcams"
-]New value: +[
+  "accidents",
+  "air",
+  "air-uba",
+  "base",
+  "bathing-water",
+  "bike-counts",
+  "business-registrations",
+  "charging",
+  "charging-status",
+  "civil-protection-warnings",
+  "construction",
+  "council-papers",
+  "crime-stats",
+  "demographics",
+  "district-heating",
+  "drinking-water",
+  "education",
+  "election",
+  "energy",
+  "events",
+  "fire-danger",
+  "flood",
+  "fuel-prices",
+  "geo",
+  "government-offices",
+  "health",
+  "heritage",
+  "holidays",
+  "hospitals-atlas",
+  "icu-live",
+  "indicators",
+  "insolvencies",
+  "land-values",
+  "markets",
+  "office-wait-times",
+  "overview",
+  "parcel-lockers",
+  "parking",
+  "playgrounds",
+  "pollen-uv",
+  "population-density",
+  "post-boxes",
+  "post-offices",
+  "power-load",
+  "power-price",
+  "public-tenders",
+  "public-toilets",
+  "public-wifi",
+  "recycling-centres",
+  "road-events",
+  "sharing",
+  "solar",
+  "solar-roofs",
+  "station-arrivals",
+  "station-departures",
+  "station-facilities",
+  "stations",
+  "tax-rates",
+  "tourism",
+  "traffic",
+  "transit",
+  "tree-cadastre",
+  "unemployment",
+  "vehicle-registrations",
+  "water-level",
+  "weather",
+  "weather-warnings",
+  "webcams"
+]

7 tool updatesJul 7, 2026

Changedair_quality1 field changed

changedInput schema / properties / slug / description

Previous value: -"City slug from the list_cities tool, e.g. 'berlin' or 'hamburg'."New value: +"City identifier, e.g. 'berlin' or 'hamburg'. Resolved leniently: the German name with or without umlauts, any casing, a common English exonym or short form also works (München/munich/munchen -> muenchen, cologne -> koeln, frankfurt -> frankfurt-am-main). An unknown name returns 404 with a 'Meintest du ...?' suggestion. list_cities gives the canonical slugs."

Changedget_city1 field changed

changedInput schema / properties / slug / description

Previous value: -"City slug from the list_cities tool, e.g. 'berlin' or 'hamburg'."New value: +"City identifier, e.g. 'berlin' or 'hamburg'. Resolved leniently: the German name with or without umlauts, any casing, a common English exonym or short form also works (München/munich/munchen -> muenchen, cologne -> koeln, frankfurt -> frankfurt-am-main). An unknown name returns 404 with a 'Meintest du ...?' suggestion. list_cities gives the canonical slugs."

Changedget_city_overview1 field changed

changedInput schema / properties / slug / description

Previous value: -"City slug from the list_cities tool, e.g. 'berlin' or 'hamburg'."New value: +"City identifier, e.g. 'berlin' or 'hamburg'. Resolved leniently: the German name with or without umlauts, any casing, a common English exonym or short form also works (München/munich/munchen -> muenchen, cologne -> koeln, frankfurt -> frankfurt-am-main). An unknown name returns 404 with a 'Meintest du ...?' suggestion. list_cities gives the canonical slugs."

Changedget_city_resource1 field changed

changedInput schema / properties / slug / description

Previous value: -"City slug from the list_cities tool, e.g. 'berlin' or 'hamburg'."New value: +"City identifier, e.g. 'berlin' or 'hamburg'. Resolved leniently: the German name with or without umlauts, any casing, a common English exonym or short form also works (München/munich/munchen -> muenchen, cologne -> koeln, frankfurt -> frankfurt-am-main). An unknown name returns 404 with a 'Meintest du ...?' suggestion. list_cities gives the canonical slugs."

Changedpois1 field changed

changedInput schema / properties / slug / description

Previous value: -"City slug from the list_cities tool, e.g. 'berlin' or 'hamburg'."New value: +"City identifier, e.g. 'berlin' or 'hamburg'. Resolved leniently: the German name with or without umlauts, any casing, a common English exonym or short form also works (München/munich/munchen -> muenchen, cologne -> koeln, frankfurt -> frankfurt-am-main). An unknown name returns 404 with a 'Meintest du ...?' suggestion. list_cities gives the canonical slugs."

Changedtransit_departures1 field changed

changedInput schema / properties / slug / description

Previous value: -"City slug from the list_cities tool, e.g. 'berlin' or 'hamburg'."New value: +"City identifier, e.g. 'berlin' or 'hamburg'. Resolved leniently: the German name with or without umlauts, any casing, a common English exonym or short form also works (München/munich/munchen -> muenchen, cologne -> koeln, frankfurt -> frankfurt-am-main). An unknown name returns 404 with a 'Meintest du ...?' suggestion. list_cities gives the canonical slugs."

Changedweather1 field changed

changedInput schema / properties / slug / description

Previous value: -"City slug from the list_cities tool, e.g. 'berlin' or 'hamburg'."New value: +"City identifier, e.g. 'berlin' or 'hamburg'. Resolved leniently: the German name with or without umlauts, any casing, a common English exonym or short form also works (München/munich/munchen -> muenchen, cologne -> koeln, frankfurt -> frankfurt-am-main). An unknown name returns 404 with a 'Meintest du ...?' suggestion. list_cities gives the canonical slugs."

1 tool updateJul 6, 2026

Changedget_city_resource1 field changed

changedInput schema / properties / resource / enum

Previous value: -[
-  "accidents",
-  "air",
-  "air-uba",
-  "base",
-  "bathing-water",
-  "bike-counts",
-  "business-registrations",
-  "charging",
-  "charging-status",
-  "construction",
-  "crime-stats",
-  "demographics",
-  "district-heating",
-  "drinking-water",
-  "education",
-  "election",
-  "energy",
-  "events",
-  "fire-danger",
-  "flood",
-  "fuel-prices",
-  "geo",
-  "government-offices",
-  "health",
-  "heritage",
-  "holidays",
-  "hospitals-atlas",
-  "icu-live",
-  "indicators",
-  "insolvencies",
-  "land-values",
-  "markets",
-  "office-wait-times",
-  "overview",
-  "parcel-lockers",
-  "parking",
-  "playgrounds",
-  "pollen-uv",
-  "population-density",
-  "post-boxes",
-  "post-offices",
-  "power-load",
-  "power-price",
-  "public-tenders",
-  "public-toilets",
-  "public-wifi",
-  "recycling-centres",
-  "road-events",
-  "sharing",
-  "solar",
-  "solar-roofs",
-  "station-arrivals",
-  "station-departures",
-  "station-facilities",
-  "stations",
-  "tax-rates",
-  "tourism",
-  "traffic",
-  "transit",
-  "tree-cadastre",
-  "unemployment",
-  "vehicle-registrations",
-  "water-level",
-  "weather",
-  "weather-warnings",
-  "webcams"
-]New value: +[
+  "accidents",
+  "air",
+  "air-uba",
+  "base",
+  "bathing-water",
+  "bike-counts",
+  "business-registrations",
+  "charging",
+  "charging-status",
+  "civil-protection-warnings",
+  "construction",
+  "crime-stats",
+  "demographics",
+  "district-heating",
+  "drinking-water",
+  "education",
+  "election",
+  "energy",
+  "events",
+  "fire-danger",
+  "flood",
+  "fuel-prices",
+  "geo",
+  "government-offices",
+  "health",
+  "heritage",
+  "holidays",
+  "hospitals-atlas",
+  "icu-live",
+  "indicators",
+  "insolvencies",
+  "land-values",
+  "markets",
+  "office-wait-times",
+  "overview",
+  "parcel-lockers",
+  "parking",
+  "playgrounds",
+  "pollen-uv",
+  "population-density",
+  "post-boxes",
+  "post-offices",
+  "power-load",
+  "power-price",
+  "public-tenders",
+  "public-toilets",
+  "public-wifi",
+  "recycling-centres",
+  "road-events",
+  "sharing",
+  "solar",
+  "solar-roofs",
+  "station-arrivals",
+  "station-departures",
+  "station-facilities",
+  "stations",
+  "tax-rates",
+  "tourism",
+  "traffic",
+  "transit",
+  "tree-cadastre",
+  "unemployment",
+  "vehicle-registrations",
+  "water-level",
+  "weather",
+  "weather-warnings",
+  "webcams"
+]

1 tool updateJul 5, 2026

Changedget_city_resource1 field changed

changedInput schema / properties / resource / enum

Previous value: -[
-  "accidents",
-  "air",
-  "air-uba",
-  "base",
-  "bathing-water",
-  "bike-counts",
-  "business-registrations",
-  "charging",
-  "charging-status",
-  "construction",
-  "crime-stats",
-  "demographics",
-  "district-heating",
-  "drinking-water",
-  "education",
-  "election",
-  "energy",
-  "events",
-  "fire-danger",
-  "flood",
-  "fuel-prices",
-  "geo",
-  "government-offices",
-  "health",
-  "heritage",
-  "holidays",
-  "hospitals-atlas",
-  "icu-live",
-  "indicators",
-  "insolvencies",
-  "land-values",
-  "markets",
-  "overview",
-  "parcel-lockers",
-  "parking",
-  "playgrounds",
-  "pollen-uv",
-  "population-density",
-  "post-boxes",
-  "post-offices",
-  "power-load",
-  "power-price",
-  "public-tenders",
-  "public-toilets",
-  "public-wifi",
-  "recycling-centres",
-  "road-events",
-  "sharing",
-  "solar",
-  "solar-roofs",
-  "station-arrivals",
-  "station-departures",
-  "station-facilities",
-  "stations",
-  "tax-rates",
-  "tourism",
-  "traffic",
-  "transit",
-  "tree-cadastre",
-  "unemployment",
-  "vehicle-registrations",
-  "water-level",
-  "weather",
-  "weather-warnings",
-  "webcams"
-]New value: +[
+  "accidents",
+  "air",
+  "air-uba",
+  "base",
+  "bathing-water",
+  "bike-counts",
+  "business-registrations",
+  "charging",
+  "charging-status",
+  "construction",
+  "crime-stats",
+  "demographics",
+  "district-heating",
+  "drinking-water",
+  "education",
+  "election",
+  "energy",
+  "events",
+  "fire-danger",
+  "flood",
+  "fuel-prices",
+  "geo",
+  "government-offices",
+  "health",
+  "heritage",
+  "holidays",
+  "hospitals-atlas",
+  "icu-live",
+  "indicators",
+  "insolvencies",
+  "land-values",
+  "markets",
+  "office-wait-times",
+  "overview",
+  "parcel-lockers",
+  "parking",
+  "playgrounds",
+  "pollen-uv",
+  "population-density",
+  "post-boxes",
+  "post-offices",
+  "power-load",
+  "power-price",
+  "public-tenders",
+  "public-toilets",
+  "public-wifi",
+  "recycling-centres",
+  "road-events",
+  "sharing",
+  "solar",
+  "solar-roofs",
+  "station-arrivals",
+  "station-departures",
+  "station-facilities",
+  "stations",
+  "tax-rates",
+  "tourism",
+  "traffic",
+  "transit",
+  "tree-cadastre",
+  "unemployment",
+  "vehicle-registrations",
+  "water-level",
+  "weather",
+  "weather-warnings",
+  "webcams"
+]

1 tool updateJul 4, 2026

Changedcompare1 field changed

changedInput schema / properties / resource / description

Previous value: -"Resource to compare. Currently supported: 'weather' (DWD) or 'air' (UBA air quality)."New value: +"Resource to compare. Supported: 'weather' (DWD), 'air' (UBA air quality), 'indicators' (INKAR socioeconomic indicators incl. unemployment rate and EV charging coverage), 'demographics', 'unemployment', 'tourism', 'charging-status' (live EV charging occupancy, aggregates only) and 'weather-warnings' (official DWD warning level per city)."

1 tool updateJul 3, 2026

Changedget_city_resource1 field changed

changedInput schema / properties / resource / enum

Previous value: -[
-  "accidents",
-  "air",
-  "air-uba",
-  "base",
-  "bathing-water",
-  "bike-counts",
-  "business-registrations",
-  "charging",
-  "construction",
-  "crime-stats",
-  "demographics",
-  "district-heating",
-  "drinking-water",
-  "education",
-  "election",
-  "energy",
-  "events",
-  "fire-danger",
-  "flood",
-  "fuel-prices",
-  "geo",
-  "government-offices",
-  "health",
-  "heritage",
-  "holidays",
-  "hospitals-atlas",
-  "icu-live",
-  "indicators",
-  "insolvencies",
-  "land-values",
-  "markets",
-  "overview",
-  "parcel-lockers",
-  "parking",
-  "playgrounds",
-  "pollen-uv",
-  "population-density",
-  "post-boxes",
-  "post-offices",
-  "power-load",
-  "power-price",
-  "public-tenders",
-  "public-toilets",
-  "public-wifi",
-  "recycling-centres",
-  "road-events",
-  "sharing",
-  "solar",
-  "solar-roofs",
-  "station-arrivals",
-  "station-departures",
-  "station-facilities",
-  "stations",
-  "tax-rates",
-  "tourism",
-  "traffic",
-  "transit",
-  "tree-cadastre",
-  "unemployment",
-  "vehicle-registrations",
-  "water-level",
-  "weather",
-  "weather-warnings",
-  "webcams"
-]New value: +[
+  "accidents",
+  "air",
+  "air-uba",
+  "base",
+  "bathing-water",
+  "bike-counts",
+  "business-registrations",
+  "charging",
+  "charging-status",
+  "construction",
+  "crime-stats",
+  "demographics",
+  "district-heating",
+  "drinking-water",
+  "education",
+  "election",
+  "energy",
+  "events",
+  "fire-danger",
+  "flood",
+  "fuel-prices",
+  "geo",
+  "government-offices",
+  "health",
+  "heritage",
+  "holidays",
+  "hospitals-atlas",
+  "icu-live",
+  "indicators",
+  "insolvencies",
+  "land-values",
+  "markets",
+  "overview",
+  "parcel-lockers",
+  "parking",
+  "playgrounds",
+  "pollen-uv",
+  "population-density",
+  "post-boxes",
+  "post-offices",
+  "power-load",
+  "power-price",
+  "public-tenders",
+  "public-toilets",
+  "public-wifi",
+  "recycling-centres",
+  "road-events",
+  "sharing",
+  "solar",
+  "solar-roofs",
+  "station-arrivals",
+  "station-departures",
+  "station-facilities",
+  "stations",
+  "tax-rates",
+  "tourism",
+  "traffic",
+  "transit",
+  "tree-cadastre",
+  "unemployment",
+  "vehicle-registrations",
+  "water-level",
+  "weather",
+  "weather-warnings",
+  "webcams"
+]

72 tool updatesJul 2, 2026
- Removedaccidents
- Changedair_quality12 fields changed
  - removedInput schema / properties / slug / title
```
Removed value: -"Slug"
```
  - removedInput schema / title
```
Removed value: -"air_qualityArguments"
```
  - removedOutput schema / $defs / ToolMeta / description
```
Removed value: -"Envelope-Metadaten: Quelle, Status, Cache, Lizenz und Attribution.\n\nZusatzfelder (z.B. ``covered_cities``, ``radius_m`` bei partieller Abdeckung)\nbleiben dank ``extra=\"allow\"`` erhalten."
```
  - removedOutput schema / $defs / ToolMeta / properties / attribution / title
```
Removed value: -"Attribution"
```
  - removedOutput schema / $defs / ToolMeta / properties / cache_status / title
```
Removed value: -"Cache Status"
```
  - removedOutput schema / $defs / ToolMeta / properties / correlation_id / title
```
Removed value: -"Correlation Id"
```
  - removedOutput schema / $defs / ToolMeta / properties / license / title
```
Removed value: -"License"
```
  - removedOutput schema / $defs / ToolMeta / properties / source / title
```
Removed value: -"Source"
```
  - removedOutput schema / $defs / ToolMeta / properties / source_status / title
```
Removed value: -"Source Status"
```
  - removedOutput schema / $defs / ToolMeta / title
```
Removed value: -"ToolMeta"
```
  - removedOutput schema / properties / data / title
```
Removed value: -"Data"
```
  - removedOutput schema / title
```
Removed value: -"ToolEnvelope"
```
- Removedair_quality_live
- Removedbathing_water
- Removedbike_counts
- Removedbusiness_registrations
- Removedcharging
- Changedcompare13 fields changed
  - removedInput schema / properties / cities / title
```
Removed value: -"Cities"
```
  - removedInput schema / properties / resource / title
```
Removed value: -"Resource"
```
  - removedInput schema / title
```
Removed value: -"compareArguments"
```
  - removedOutput schema / $defs / ToolMeta / description
```
Removed value: -"Envelope-Metadaten: Quelle, Status, Cache, Lizenz und Attribution.\n\nZusatzfelder (z.B. ``covered_cities``, ``radius_m`` bei partieller Abdeckung)\nbleiben dank ``extra=\"allow\"`` erhalten."
```
  - removedOutput schema / $defs / ToolMeta / properties / attribution / title
```
Removed value: -"Attribution"
```
  - removedOutput schema / $defs / ToolMeta / properties / cache_status / title
```
Removed value: -"Cache Status"
```
  - removedOutput schema / $defs / ToolMeta / properties / correlation_id / title
```
Removed value: -"Correlation Id"
```
  - removedOutput schema / $defs / ToolMeta / properties / license / title
```
Removed value: -"License"
```
  - removedOutput schema / $defs / ToolMeta / properties / source / title
```
Removed value: -"Source"
```
  - removedOutput schema / $defs / ToolMeta / properties / source_status / title
```
Removed value: -"Source Status"
```
  - removedOutput schema / $defs / ToolMeta / title
```
Removed value: -"ToolMeta"
```
  - removedOutput schema / properties / data / title
```
Removed value: -"Data"
```
  - removedOutput schema / title
```
Removed value: -"ToolEnvelope"
```
- Removedconstruction
- Removedcrime_stats
- Removeddemographics
- Removeddistrict_heating
- Removeddrinking_water
- Removededucation
- Removedelection
- Removedenergy
- Removedevents
- Removedfire_danger
- Removedflood
- Removedfuel_prices
- Removedgeo
- Changedget_city12 fields changed
  - removedInput schema / properties / slug / title
```
Removed value: -"Slug"
```
  - removedInput schema / title
```
Removed value: -"get_cityArguments"
```
  - removedOutput schema / $defs / ToolMeta / description
```
Removed value: -"Envelope-Metadaten: Quelle, Status, Cache, Lizenz und Attribution.\n\nZusatzfelder (z.B. ``covered_cities``, ``radius_m`` bei partieller Abdeckung)\nbleiben dank ``extra=\"allow\"`` erhalten."
```
  - removedOutput schema / $defs / ToolMeta / properties / attribution / title
```
Removed value: -"Attribution"
```
  - removedOutput schema / $defs / ToolMeta / properties / cache_status / title
```
Removed value: -"Cache Status"
```
  - removedOutput schema / $defs / ToolMeta / properties / correlation_id / title
```
Removed value: -"Correlation Id"
```
  - removedOutput schema / $defs / ToolMeta / properties / license / title
```
Removed value: -"License"
```
  - removedOutput schema / $defs / ToolMeta / properties / source / title
```
Removed value: -"Source"
```
  - removedOutput schema / $defs / ToolMeta / properties / source_status / title
```
Removed value: -"Source Status"
```
  - removedOutput schema / $defs / ToolMeta / title
```
Removed value: -"ToolMeta"
```
  - removedOutput schema / properties / data / title
```
Removed value: -"Data"
```
  - removedOutput schema / title
```
Removed value: -"ToolEnvelope"
```
- Changedget_city_overview12 fields changed
  - removedInput schema / properties / slug / title
```
Removed value: -"Slug"
```
  - removedInput schema / title
```
Removed value: -"get_city_overviewArguments"
```
  - removedOutput schema / $defs / ToolMeta / description
```
Removed value: -"Envelope-Metadaten: Quelle, Status, Cache, Lizenz und Attribution.\n\nZusatzfelder (z.B. ``covered_cities``, ``radius_m`` bei partieller Abdeckung)\nbleiben dank ``extra=\"allow\"`` erhalten."
```
  - removedOutput schema / $defs / ToolMeta / properties / attribution / title
```
Removed value: -"Attribution"
```
  - removedOutput schema / $defs / ToolMeta / properties / cache_status / title
```
Removed value: -"Cache Status"
```
  - removedOutput schema / $defs / ToolMeta / properties / correlation_id / title
```
Removed value: -"Correlation Id"
```
  - removedOutput schema / $defs / ToolMeta / properties / license / title
```
Removed value: -"License"
```
  - removedOutput schema / $defs / ToolMeta / properties / source / title
```
Removed value: -"Source"
```
  - removedOutput schema / $defs / ToolMeta / properties / source_status / title
```
Removed value: -"Source Status"
```
  - removedOutput schema / $defs / ToolMeta / title
```
Removed value: -"ToolMeta"
```
  - removedOutput schema / properties / data / title
```
Removed value: -"Data"
```
  - removedOutput schema / title
```
Removed value: -"ToolEnvelope"
```
- Addedget_city_resource
- Removedgovernment_offices
- Removedhealth
- Removedheritage
- Removedholidays
- Removedhospitals_atlas
- Removedicu_live
- Removedindicators
- Removedinsolvencies
- Removedland_values
- Changedlist_cities11 fields changed
  - removedInput schema / title
```
Removed value: -"list_citiesArguments"
```
  - removedOutput schema / $defs / ToolMeta / description
```
Removed value: -"Envelope-Metadaten: Quelle, Status, Cache, Lizenz und Attribution.\n\nZusatzfelder (z.B. ``covered_cities``, ``radius_m`` bei partieller Abdeckung)\nbleiben dank ``extra=\"allow\"`` erhalten."
```
  - removedOutput schema / $defs / ToolMeta / properties / attribution / title
```
Removed value: -"Attribution"
```
  - removedOutput schema / $defs / ToolMeta / properties / cache_status / title
```
Removed value: -"Cache Status"
```
  - removedOutput schema / $defs / ToolMeta / properties / correlation_id / title
```
Removed value: -"Correlation Id"
```
  - removedOutput schema / $defs / ToolMeta / properties / license / title
```
Removed value: -"License"
```
  - removedOutput schema / $defs / ToolMeta / properties / source / title
```
Removed value: -"Source"
```
  - removedOutput schema / $defs / ToolMeta / properties / source_status / title
```
Removed value: -"Source Status"
```
  - removedOutput schema / $defs / ToolMeta / title
```
Removed value: -"ToolMeta"
```
  - removedOutput schema / properties / data / title
```
Removed value: -"Data"
```
  - removedOutput schema / title
```
Removed value: -"ToolEnvelope"
```
- Removedmarkets
- Removedparcel_lockers
- Removedparking
- Removedplaygrounds
- Changedpois13 fields changed
  - removedInput schema / properties / slug / title
```
Removed value: -"Slug"
```
  - removedInput schema / properties / type / title
```
Removed value: -"Type"
```
  - removedInput schema / title
```
Removed value: -"poisArguments"
```
  - removedOutput schema / $defs / ToolMeta / description
```
Removed value: -"Envelope-Metadaten: Quelle, Status, Cache, Lizenz und Attribution.\n\nZusatzfelder (z.B. ``covered_cities``, ``radius_m`` bei partieller Abdeckung)\nbleiben dank ``extra=\"allow\"`` erhalten."
```
  - removedOutput schema / $defs / ToolMeta / properties / attribution / title
```
Removed value: -"Attribution"
```
  - removedOutput schema / $defs / ToolMeta / properties / cache_status / title
```
Removed value: -"Cache Status"
```
  - removedOutput schema / $defs / ToolMeta / properties / correlation_id / title
```
Removed value: -"Correlation Id"
```
  - removedOutput schema / $defs / ToolMeta / properties / license / title
```
Removed value: -"License"
```
  - removedOutput schema / $defs / ToolMeta / properties / source / title
```
Removed value: -"Source"
```
  - removedOutput schema / $defs / ToolMeta / properties / source_status / title
```
Removed value: -"Source Status"
```
  - removedOutput schema / $defs / ToolMeta / title
```
Removed value: -"ToolMeta"
```
  - removedOutput schema / properties / data / title
```
Removed value: -"Data"
```
  - removedOutput schema / title
```
Removed value: -"ToolEnvelope"
```
- Removedpollen_uv
- Removedpopulation_density
- Removedpost_boxes
- Removedpost_offices
- Removedpower_load
- Removedpower_price
- Removedpublic_tenders
- Removedpublic_toilets
- Removedpublic_wifi
- Removedrecycling_centres
- Removedroad_events
- Removedsharing
- Removedsolar
- Removedsolar_roofs
- Changedsources11 fields changed
  - removedInput schema / title
```
Removed value: -"sourcesArguments"
```
  - removedOutput schema / $defs / ToolMeta / description
```
Removed value: -"Envelope-Metadaten: Quelle, Status, Cache, Lizenz und Attribution.\n\nZusatzfelder (z.B. ``covered_cities``, ``radius_m`` bei partieller Abdeckung)\nbleiben dank ``extra=\"allow\"`` erhalten."
```
  - removedOutput schema / $defs / ToolMeta / properties / attribution / title
```
Removed value: -"Attribution"
```
  - removedOutput schema / $defs / ToolMeta / properties / cache_status / title
```
Removed value: -"Cache Status"
```
  - removedOutput schema / $defs / ToolMeta / properties / correlation_id / title
```
Removed value: -"Correlation Id"
```
  - removedOutput schema / $defs / ToolMeta / properties / license / title
```
Removed value: -"License"
```
  - removedOutput schema / $defs / ToolMeta / properties / source / title
```
Removed value: -"Source"
```
  - removedOutput schema / $defs / ToolMeta / properties / source_status / title
```
Removed value: -"Source Status"
```
  - removedOutput schema / $defs / ToolMeta / title
```
Removed value: -"ToolMeta"
```
  - removedOutput schema / properties / data / title
```
Removed value: -"Data"
```
  - removedOutput schema / title
```
Removed value: -"ToolEnvelope"
```
- Removedstation_arrivals
- Changedstation_board_arrivals13 fields changed
  - changedInput schema / properties / eva / description
```
Previous value: -"Station EVA number (digits only) from the stations tool, e.g. '8000105' (Frankfurt Hbf)."New value: +"Station EVA number (digits only) from get_city_resource(slug, resource='stations'), e.g. '8000105' (Frankfurt Hbf)."
```
  - removedInput schema / properties / eva / title
```
Removed value: -"Eva"
```
  - removedInput schema / title
```
Removed value: -"station_board_arrivalsArguments"
```
  - removedOutput schema / $defs / ToolMeta / description
```
Removed value: -"Envelope-Metadaten: Quelle, Status, Cache, Lizenz und Attribution.\n\nZusatzfelder (z.B. ``covered_cities``, ``radius_m`` bei partieller Abdeckung)\nbleiben dank ``extra=\"allow\"`` erhalten."
```
  - removedOutput schema / $defs / ToolMeta / properties / attribution / title
```
Removed value: -"Attribution"
```
  - removedOutput schema / $defs / ToolMeta / properties / cache_status / title
```
Removed value: -"Cache Status"
```
  - removedOutput schema / $defs / ToolMeta / properties / correlation_id / title
```
Removed value: -"Correlation Id"
```
  - removedOutput schema / $defs / ToolMeta / properties / license / title
```
Removed value: -"License"
```
  - removedOutput schema / $defs / ToolMeta / properties / source / title
```
Removed value: -"Source"
```
  - removedOutput schema / $defs / ToolMeta / properties / source_status / title
```
Removed value: -"Source Status"
```
  - removedOutput schema / $defs / ToolMeta / title
```
Removed value: -"ToolMeta"
```
  - removedOutput schema / properties / data / title
```
Removed value: -"Data"
```
  - removedOutput schema / title
```
Removed value: -"ToolEnvelope"
```
- Changedstation_board_departures13 fields changed
  - changedInput schema / properties / eva / description
```
Previous value: -"Station EVA number (digits only) from the stations tool, e.g. '8011160' (Berlin Hbf)."New value: +"Station EVA number (digits only) from get_city_resource(slug, resource='stations'), e.g. '8011160' (Berlin Hbf)."
```
  - removedInput schema / properties / eva / title
```
Removed value: -"Eva"
```
  - removedInput schema / title
```
Removed value: -"station_board_departuresArguments"
```
  - removedOutput schema / $defs / ToolMeta / description
```
Removed value: -"Envelope-Metadaten: Quelle, Status, Cache, Lizenz und Attribution.\n\nZusatzfelder (z.B. ``covered_cities``, ``radius_m`` bei partieller Abdeckung)\nbleiben dank ``extra=\"allow\"`` erhalten."
```
  - removedOutput schema / $defs / ToolMeta / properties / attribution / title
```
Removed value: -"Attribution"
```
  - removedOutput schema / $defs / ToolMeta / properties / cache_status / title
```
Removed value: -"Cache Status"
```
  - removedOutput schema / $defs / ToolMeta / properties / correlation_id / title
```
Removed value: -"Correlation Id"
```
  - removedOutput schema / $defs / ToolMeta / properties / license / title
```
Removed value: -"License"
```
  - removedOutput schema / $defs / ToolMeta / properties / source / title
```
Removed value: -"Source"
```
  - removedOutput schema / $defs / ToolMeta / properties / source_status / title
```
Removed value: -"Source Status"
```
  - removedOutput schema / $defs / ToolMeta / title
```
Removed value: -"ToolMeta"
```
  - removedOutput schema / properties / data / title
```
Removed value: -"Data"
```
  - removedOutput schema / title
```
Removed value: -"ToolEnvelope"
```
- Removedstation_departures
- Removedstation_facilities
- Removedstations
- Removedtax_rates
- Removedtourism
- Removedtraffic
- Removedtransit
- Changedtransit_departures14 fields changed
  - removedInput schema / properties / slug / title
```
Removed value: -"Slug"
```
  - changedInput schema / properties / stop_id / description
```
Previous value: -"Required stop ID to fetch departures for. Discover a city's stop IDs with the 'transit' tool first (each stop carries its id). Format: DELFI 'de:<AGS>:<id>' or a numeric gtfs.de stop id."New value: +"Required stop ID to fetch departures for. Discover a city's stop IDs with get_city_resource(slug, resource='transit') first (each stop carries its id). Format: DELFI 'de:<AGS>:<id>' or a numeric gtfs.de stop id."
```
  - removedInput schema / properties / stop_id / title
```
Removed value: -"Stop Id"
```
  - removedInput schema / title
```
Removed value: -"transit_departuresArguments"
```
  - removedOutput schema / $defs / ToolMeta / description
```
Removed value: -"Envelope-Metadaten: Quelle, Status, Cache, Lizenz und Attribution.\n\nZusatzfelder (z.B. ``covered_cities``, ``radius_m`` bei partieller Abdeckung)\nbleiben dank ``extra=\"allow\"`` erhalten."
```
  - removedOutput schema / $defs / ToolMeta / properties / attribution / title
```
Removed value: -"Attribution"
```
  - removedOutput schema / $defs / ToolMeta / properties / cache_status / title
```
Removed value: -"Cache Status"
```
  - removedOutput schema / $defs / ToolMeta / properties / correlation_id / title
```
Removed value: -"Correlation Id"
```
  - removedOutput schema / $defs / ToolMeta / properties / license / title
```
Removed value: -"License"
```
  - removedOutput schema / $defs / ToolMeta / properties / source / title
```
Removed value: -"Source"
```
  - removedOutput schema / $defs / ToolMeta / properties / source_status / title
```
Removed value: -"Source Status"
```
  - removedOutput schema / $defs / ToolMeta / title
```
Removed value: -"ToolMeta"
```
  - removedOutput schema / properties / data / title
```
Removed value: -"Data"
```
  - removedOutput schema / title
```
Removed value: -"ToolEnvelope"
```
- Removedtree_cadastre
- Removedunemployment
- Removedvehicle_registrations
- Removedwater_level
- Changedweather12 fields changed
  - removedInput schema / properties / slug / title
```
Removed value: -"Slug"
```
  - removedInput schema / title
```
Removed value: -"weatherArguments"
```
  - removedOutput schema / $defs / ToolMeta / description
```
Removed value: -"Envelope-Metadaten: Quelle, Status, Cache, Lizenz und Attribution.\n\nZusatzfelder (z.B. ``covered_cities``, ``radius_m`` bei partieller Abdeckung)\nbleiben dank ``extra=\"allow\"`` erhalten."
```
  - removedOutput schema / $defs / ToolMeta / properties / attribution / title
```
Removed value: -"Attribution"
```
  - removedOutput schema / $defs / ToolMeta / properties / cache_status / title
```
Removed value: -"Cache Status"
```
  - removedOutput schema / $defs / ToolMeta / properties / correlation_id / title
```
Removed value: -"Correlation Id"
```
  - removedOutput schema / $defs / ToolMeta / properties / license / title
```
Removed value: -"License"
```
  - removedOutput schema / $defs / ToolMeta / properties / source / title
```
Removed value: -"Source"
```
  - removedOutput schema / $defs / ToolMeta / properties / source_status / title
```
Removed value: -"Source Status"
```
  - removedOutput schema / $defs / ToolMeta / title
```
Removed value: -"ToolMeta"
```
  - removedOutput schema / properties / data / title
```
Removed value: -"Data"
```
  - removedOutput schema / title
```
Removed value: -"ToolEnvelope"
```
- Removedweather_warnings
- Removedwebcams

1 tool updateJul 1, 2026

Changedtransit_departures1 field changed

changedInput schema / properties / stop_id / description

Previous value: -"Optional stop ID; omit it to get the city's available departures."New value: +"Required stop ID to fetch departures for. Discover a city's stop IDs with the 'transit' tool first (each stop carries its id). Format: DELFI 'de:<AGS>:<id>' or a numeric gtfs.de stop id."

Related MCP Connectors

Germany Tenders A
io.github.pipeworx-io
Germany public procurement MCP — official German government tenders (keyless).
Government Data Open Data
2
Govdata De A
io.github.pipeworx-io
GovData.de MCP — Germany's national open-data portal (CKAN API).
Government Data Open Data
2
Luxembourg MCP B
io.github.amirdaraee
Keyless MCP access to official Luxembourg public data: laws, statistics, mobility, and more.
Government Data Open Data
4428
Healthdata A
io.github.pipeworx-io
HealthData.gov MCP. Keyless.
Government Data Health & Wellness
442

Related MCP Servers

ViaFrei
Government Data Location Services Travel & Transportation
mavrovde
A
license
A
quality
A
maintenance
Provides MCP tools that let AI assistants query German road, parking, charging, rail, and fuel data, with attribution and licensing constraints included in results.
Updated 2 days ago (2026-10-17 16:53 UTC)
22
1,811 npm
Apache 2.0
germany-mcp-server
Government Data Open Data Search
AiAgentKarl
A
license
B
quality
D
maintenance
MCP server providing AI agents with access to German government open data. 12 tools across 6 categories: Autobahn traffic, DWD weather, NINA disaster warnings, SMARD energy market, Bundestag parliamentary data, and pollen forecasts. All APIs are free, no keys required.
Updated 7 months ago (2026-04-03 16:24 UTC)
16
3
MIT
qune-tech/ocds-mcp
Government Data Search RAG Systems
qune-tech
A
license
A
quality
C
maintenance
MCP server for German public procurement data (OCDS). Semantic search, tender matching, and company profiles — all from your local LLM
Updated 3 months ago (2026-07-26 10:13 UTC)
10
5
MIT
lindas-mcp
Government Data Open Data Databases
malkreide
A
license
A
quality
A
maintenance
MCP server for LINDAS, the linked-data knowledge graph of the Swiss administration, enabling querying of Swiss public data cubes via guarded SPARQL tools.
Updated 23 days ago (2026-09-26 17:25 UTC)
7
51 PyPI
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.

Server Details

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Related MCP Connectors

Related MCP Servers

Glama MCP Gateway

Resources