InfraNode

City Overview

get_city_overview

Read-onlyIdempotent

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.

Input Schema

TableJSON 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

TableJSON Schema

Name	Required	Description	Default
`data`	Yes
`meta`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedAug 17, 2026
- addedOutput schema / $defs / ToolMeta / properties / note
```
Added value: +{
+  "type": "string"
+}
```

Changed1 schema field changedJul 7, 2026

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

Changed12 schema fields changedJul 2, 2026
- 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"
```
AddedJun 24, 2026

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.

All InfraNode tools Inspect

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.