GUTHMANN® Berlin Real Estate

Berlin Conservation Areas

berlin_conservation_areas

Read-onlyIdempotent

Berlin social conservation areas (Milieuschutzgebiete, §172 BauGB). 124 areas in 6 categories with polygon geometry.

Parameters:

kategorie_id: filter by category ("erhaltungsgebiet" | "erweiterung" | "aufstellungsbeschluss" | "untersuchungsgebiet" | "beobachtungsgebiet" | "aufgehoben")
erweiterungen: "true" to embed extensions as a nested array inside their main area
include: comma-separated geo attributes; available: "centroid". Polygons are provided as GeoJSON URLs in geometry_urls
lat/lon: WGS84 point lookup. Returns only areas containing the point (typically 0 or 1 match). lat and lon must be provided together.

Key response fields: array of { id, name, kategorie_id, kategorie_name, parent_id, beschreibung (description), datum (date), flaeche_km2 (area in km²), geometry_urls, centroid?, erweiterungen? (extensions) }

Use for: "Is this address in a social conservation area?" (with lat/lon), overview of all Milieuschutz areas.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "berlin_conservation_areas"
  }
}

Input Schema

Name	Required	Description	Default
`lat`	No	Breitengrad (WGS84) für Punkt-Lookup. Liefert nur Gebiete, die den Punkt enthalten. Muss zusammen mit lon angegeben werden.
`lon`	No	Längengrad (WGS84) für Punkt-Lookup. Liefert nur Gebiete, die den Punkt enthalten. Muss zusammen mit lat angegeben werden.
`include`	No	Optionale Geo-Attribute (komma-getrennt). Verfügbar: centroid. Polygone stehen als GeoJSON-URLs in geometry_urls bzw. unter meta.links.geometry als Sammeldatei.
`kategorie_id`	No	Filter nach Kategorie
`erweiterungen`	No	Erweiterungen als nested Array im Hauptgebiet einbetten	false

Schema Changelog

Changes observed during successful MCP inspections.

Changed10 schema fields changedNov 6, 2026

addedInput schema / properties / erweiterungen / default
```
Added value: +"false"
```

changedInput schema / properties / erweiterungen / description

Previous value: -"Erweiterungen als nested Array einbetten"New value: +"Erweiterungen als nested Array im Hauptgebiet einbetten"

changedInput schema / properties / include / description

Previous value: -"Geo-Attribute: centroid. Polygone kommen als GeoJSON-URLs in geometry_urls"New value: +"Optionale Geo-Attribute (komma-getrennt). Verfügbar: centroid. Polygone stehen als GeoJSON-URLs in geometry_urls bzw. unter meta.links.geometry als Sammeldatei."

removedInput schema / properties / include / enum
```
Removed value: -[
-  "centroid"
-]
```

changedInput schema / properties / lat / description

Previous value: -"Breitengrad WGS84 für Punkt-Lookup (mit lon)"New value: +"Breitengrad (WGS84) für Punkt-Lookup. Liefert nur Gebiete, die den Punkt enthalten. Muss zusammen mit lon angegeben werden."

addedInput schema / properties / lat / maximum
```
Added value: +90
```
addedInput schema / properties / lat / minimum
```
Added value: +-90
```

changedInput schema / properties / lon / description

Previous value: -"Längengrad WGS84 für Punkt-Lookup (mit lat)"New value: +"Längengrad (WGS84) für Punkt-Lookup. Liefert nur Gebiete, die den Punkt enthalten. Muss zusammen mit lat angegeben werden."

addedInput schema / properties / lon / maximum
```
Added value: +180
```
addedInput schema / properties / lon / minimum
```
Added value: +-180
```

AddedSep 1, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare read-only, idempotent, non-destructive and open-world, so safety needs no restating. The description adds genuinely useful behavior the annotations don't: polygons are returned as GeoJSON URLs rather than inline, extensions can be embedded as a nested array, and the point lookup typically returns 0 or 1 match, which sets correct expectations about result size.

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 identity and scope sentence, then clean parameter and response sections. The parameter bullets restate some schema text, but that repetition serves agents facing German-only schema descriptions, so the cost is justified rather than wasted.

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 no output schema, the description compensates by enumerating key response fields (id, name, kategorie_id, parent_id, beschreibung, datum, flaeche_km2, geometry_urls, centroid, erweiterungen) plus the GeoJSON URL handling. For a 5-parameter, all-optional read tool, an agent has everything needed to call it and interpret the result.

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 baseline is 3, but the description exceeds it: it enumerates all six kategorie_id enum values, explains the erweiterungen nesting effect, lists the only available include attribute (centroid), and states the lat/lon pairing constraint and expected match cardinality. This meaningfully clarifies intent beyond the German-language schema strings.

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?

Names a specific resource with legal grounding (Milieuschutzgebiete, §172 BauGB), dataset size (124 areas, 6 categories) and output form (polygon geometry). It is clearly a list/query tool, but never names the sibling berlin_conservation_area_details, so the boundary with single-area lookup has to be inferred.

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 'Use for:' block gives two concrete usage patterns — point-in-area checks via lat/lon and a full overview — which is more than most list tools offer. It stops short of explicit when-not guidance (e.g., use berlin_conservation_area_details for a single area by id, or avoid the unfiltered call when only one category is needed).

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

All GUTHMANN® Berlin Real Estate 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.