Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@GDI Catalogue MCP Search GDI-DE catalogue for noise in Ingolstadt and show the first record's links."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Kleiner, lesender MCP-Connector für Geodatenkatalog.de / GDI-DE. Nutzt ausschließlich CSW 2.0.2 mit Dublin-Core-Ausgabe und das offizielle Python-MCP-SDK über stdio. Kein offizieller GDI-DE-/BKG-Dienst.
Voraussetzungen: Python ≥3.11 und uv.
Repository klonen und im Projektverzeichnis ausführen:
uv sync --frozen
uv run --frozen python test_server.pyuv.lock enthält die aufgelösten Abhängigkeiten.
Related MCP server: geonetwork-mcp
Im MCP-Client den Python-Interpreter und das Skript mit absoluten Pfaden registrieren:
{
"mcpServers": {
"gdi-de": {
"command": "/absolute/path/gdi-geonetwork-mcp/.venv/bin/python",
"args": ["/absolute/path/gdi-geonetwork-mcp/server.py"]
}
}
}Der Client startet den Prozess über stdio; kein Docker oder Port erforderlich. Bei Verschieben des Projekts Pfade aktualisieren.
Beispielprompt:
Suche im GDI-DE-Katalog nach Lärm in Ingolstadt. Zeig mir anschließend die Metadaten und Ressourcenlinks eines Treffers.
Tool | Eingaben | Ausgabe |
|
| Quelle, Trefferzahl, nächste Seite, Metadaten |
|
| Dublin-Core-Metadaten, Themen, Rechte, Ressourcenlinks, Metadaten-Bounding-Boxes |
search_records nutzt CSW GetRecords, get_record nutzt GetRecordById. query ist eine Wortsuche, keine rohe CQL-Abfrage. Wörter werden per AND und AnyText LIKE kombiniert; CQL-Wildcards % und _ bleiben wirksam. next_record=0 bedeutet Ende.
Ressourcenlinks werden nicht automatisch geöffnet. Ein Metadaten-Footprint beweist keine lokale Datenabdeckung. Keine Downloads, Kartenanalyse, räumliche Suchparameter, Schreibfunktionen, Uploads oder Harvesting.
Standard: https://gdk.gdi-de.org/gdi-de/srv/ger/csw.
Für einen anderen CSW-Katalog CSW_URL in der Prozessumgebung setzen (im obigen Client-Beispiel über env). Die URL wird ausschließlich vom Betreiber konfiguriert, nicht als Tool-Parameter angeboten. Andere Kataloge sind nicht getestet; CSW 2.0.2 und Dublin-Core-Ausgabe müssen unterstützt werden.
Offline-Tests prüfen Eingabevalidierung, CQL-Escaping, Metadaten, Pagination, XML-Sicherheit und Antwortgrößenlimit.
uv run --frozen python test_server.py --live--live startet einen echten MCP-Prozess und prüft Suche, Record-Abruf, Pagination und Toolfehler; Internet nötig. Timeouts oder andere Anbieterfehler werden nicht als Erfolg gewertet.
Livetest bestanden: GDI-DE-CSW-Suche „Lärm Ingolstadt“ mit 17 Treffern, Record-Abruf, Pagination und Toolfehler über MCP stdio geprüft. Frühere Tests liefen zeitweise in CSW-Suchtimeouts; die Verfügbarkeit hängt vom Anbieter ab. Es gibt keinen alternativen Suchpfad oder automatischen Fallback.
HTTP-Zeitlimit 30 Sekunden, maximal 5 MiB Antwort, keine automatischen Redirects oder Wiederholungen. Sichere XML-Verarbeitung ohne DTD/Entities. Katalogfehler und ungültige Eingaben erscheinen als MCP-Toolfehler. Keine Credentials erforderlich oder gespeichert; geschützte Kataloge werden nicht unterstützt.
GDI-DE stellt die Kataloginhalte über standardisierte Schnittstellen zur freien Verfügung. Daraus folgt keine pauschale Freigabe der verlinkten Geodaten. Für deren Nutzung gelten die jeweiligen Anbieterbedingungen; Quellenvermerke und rechtliche Hinweise beachten. Leere Rechtefelder sind keine Nutzungserlaubnis.
Retrieve a record's Dublin Core metadata, resource links and metadata bounding boxes by its exact returned ID. Links are not verified/downloaded; a footprint does not prove local data coverage.
| Name | Required | Description | Default |
|---|---|---|---|
| record_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and non-destructive, so safety is covered. The description adds real behavioral context beyond that: links are not verified or downloaded, and a link footprint does not prove local data coverage — an important caveat about how to interpret the result.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler, and the primary purpose is front-loaded ahead of the interpretive caveat. Every clause adds information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with an output schema and full annotations, the definition covers purpose plus the one interpretive caveat an agent needs. It stops short of stating what happens on an invalid or missing ID, which is the only notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must carry the parameter meaning, and it does: record_id must be an 'exact returned ID', clarifying it is an identifier previously returned by a lookup rather than an arbitrary string or name. No format example or error behavior is given, but the core semantic constraint is present.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Retrieve) and resource (a record) plus the exact content returned: Dublin Core metadata, resource links, and bounding boxes. The phrase 'by its exact returned ID' signals this is a fetch-by-identifier lookup distinct from search_records, though it never names that sibling outright.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: the agent infers it should call this after search_records has produced an ID. There is no explicit when-to-use/when-not or named alternative, so an agent must reason about the relationship to search_records on its own.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search CSW metadata with words (e.g. 'Lärm Ingolstadt'), not raw CQL. limit 1–50, start is 1-based. Use next_record to paginate; zero means end. Call get_record for metadata and links.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| start | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, open-world and non-destructive, so safety is covered. The description adds genuinely new behavior beyond them: pagination via next_record and the convention that a zero result signals the end of the list. It does not mention rate limits or auth, but for a read-only search that is a minor omission.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short clauses, each front-loaded with its key constraint: input form, limits, pagination, and sibling routing. No filler sentences and nothing repeated from the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value explanation is correctly omitted, and the description covers input form, parameter bounds and pagination. It could say slightly more about what a match against CSW metadata returns at a glance, but nothing needed to call the tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must carry the parameters, and it does: limit is constrained to 1–50, start is documented as 1-based, and query is defined semantically (words, not CQL) with an example. Only the default values (limit 10, start 1) are left to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (search) and resource (CSW metadata), and pins down the expected input form as natural words rather than raw CQL, with a concrete example query. It is immediately distinguishable from the sibling get_record, which is named as the retrieval counterpart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when not to use it (raw CQL is wrong input), how to continue a result set (use next_record, zero means end), and when to switch to the sibling (get_record for metadata and links). Routing and pagination conditions are spelled out rather than left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0get_recordsearch_recordsScored across 2 tools
search_records is for discovery via keywords and pagination, while get_record retrieves a specific record by its exact ID. The two purposes are clearly separated with no overlap, so an agent can easily choose the correct tool.
Both tools follow a consistent snake_case verb_noun pattern: search_records and get_record. The plural/singular noun difference reflects the operation (search many vs. get one) and does not break the pattern.
With only two tools, the surface feels thin for a CSW catalogue even though the two provided operations are focused. The count is borderline per the rubric for 1–2 tools, lacking additional conveniences like capabilities or spatial search.
The core read-only lifecycle of discovery (search) and retrieval by ID (get_record) is fully covered, including pagination hints. Minor gaps remain, such as no direct spatial/bbox search or get_capabilities operation, but agents can work around these using keyword search.
GovData.de MCP — Germany's national open-data portal (CKAN API).
Search public procurement notices from 17 sources across Germany, the EU and the UK. Read-only.
data.overheid.nl MCP — the Netherlands national open-data portal (CKAN API).
Search public Australian environmental evidence with provenance across authoritative catalogues.
