Skip to main content
Glama

Listings with Railway Land

assetfy_db_rail_listings
Read-onlyIdempotent

Listings FOR SALE (zum Verkauf) — Grundstücke, Gewerbeobjekte, Häuser and BVVG land from the Assetfy listing stock (real_estates_*) — that involve railway land: alte Gleisanlagen, Gleise, Gleisanschluss, Anschlussgleis, Bahngelände, Bahnbrache, ehemaliger Güterbahnhof, Bahntrasse, Bahndamm, Stellwerk, Lokschuppen. This is the tool that joins the property market with railway and cadastral data; it answers "Grundstücke zum Verkauf mit alten Gleisanlagen", "Gewerbefläche mit Gleisanschluss kaufen", "ehemaliges Bahngelände zu verkaufen". Every hit carries its evidence: (1) the listing names railway facilities — the title, for BVVG also the description; "Bahnhofsnähe", "Bahnhofstraße" or "S-Bahn" do not count; (2) the parcel (Flurstück) under the listing coordinate has the actual use (tatsächliche Nutzung) Bahnverkehr — only where the coordinate is not a locality geocode shared with other listings, and checked against the advertised plot area; (3) the nearest operating line from the Infrastrukturregister (ISR) of DB InfraGO — railway land without an operating line within 100 m points to disused, dismantled, siding or station tracks, and the NRW cadastre adds the state "außer Betrieb, stillgelegt"; (4) where the listing has an exact address with house number (as for the exact markers on the Assetfy map, but not when the geocoder put a business or institution in front of the street — that is the address of a POI, not of the property), its distance to the nearest operating line counts by itself: up to 100 m "stark", up to 500 m "mittel" — proximity to a line, not proof of tracks on the plot. evidenz is "stark", "mittel" or "schwach"; "schwach" — a railway parcel at the coordinate that is much larger than the listing or cannot be compared because the listing states no plot area (usually a geocode on the neighbouring track), or a railway term only in a long BVVG description (usually the transport connection) — is left out unless include_weak is set. Nationwide by default, or within a Landkreis, bbox or radius. The cadastral check runs where the state cadastre in the database carries the actual use; elsewhere only the listing text counts, and the result lists which states were checked. No source says whether tracks are still on site — confirm with the exposé and the aerial image (assetfy_get_aerial_image at the listing coordinate). For railway land that is not on the market use assetfy_db_rail_corridor_parcels or assetfy_db_find_parcels_by_use with nutzungsart "Bahnverkehr".

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": "assetfy_db_rail_listings"
  }
}

Input Schema

NameRequiredDescriptionDefault
latNo
lonNo
bboxNoBounding box [west, south, east, north] in WGS84 degrees — the way to say "north of Berlin": a box from the city boundary northwards.
limitNo
typesNoMarkets to search: landbuy (Grundstück), officebuy (Gewerbe/Büro), agriculture (BVVG land), housebuy (Haus). Apartments and garages have no plot of their own to check.
evidenceNoWhich evidence a hit must have: text = the listing names railway facilities, cadastre = railway parcel under the listing coordinate, proximity = exact address within 500 m of an operating line, any = any of them.any
radius_mNoRadius around lat/lon in metres.
landkreisNoLandkreis or kreisfreie Stadt by name ("Oberhavel", "Landkreis Oberhavel", "Frankfurt am Main") or 5-digit AGS ("12065"). The search area is its official boundary.
include_weakNoAlso return hits whose only evidence is weak: a railway parcel at the coordinate that is much larger than the listing or has no plot area to compare (mostly geocodes on a neighbouring track, occasionally a part of railway land being sold), or a railway term only in a BVVG description.
price_max_eurNo
plot_area_max_m2No
plot_area_min_m2NoMinimum plot area of the listing (Grundstücksfläche).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so safety is covered, but the description adds substantial behavioral context beyond that: the four evidence types, how 'schwach' evidence is excluded unless include_weak is set, that the cadastral check only runs where the cadastre carries actual use, that results list which states were checked, and the caveat that no source confirms tracks are still on site.

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

Conciseness3/5

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

The purpose is front-loaded in the first clause, but the definition then collapses into a very long single-paragraph run-on mixing evidence rules, geographic scope and alternatives. Most content earns its place given the complexity, but the lack of structure makes it heavier than it needs to be.

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 12-parameter tool with no output schema and a genuinely intricate evidence model, the description covers what an agent needs: evidence semantics, weak-hit filtering, geographic scoping, cadastral-coverage limitations, return-content caveats and alternative tools. Nothing essential to correct invocation is missing.

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 58%, so the schema documents roughly half the parameters. The description compensates by explaining the evidence-grading model (stark/mittel/schwach), the include_weak filter, and the meaning of types (landbuy/officebuy/agriculture/housebuy), which map onto those params. It does not document lat, lon, limit or price_max_eur, but adds real semantic value for the complex parameters.

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 precise verb+resource — listings FOR SALE involving railway land — and explicitly frames its role as the tool that joins the property market with railway and cadastral data. It also names the sibling tools to use when railway land is not on the market, so an agent can tell it apart without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use (railway-land listings for sale, exemplified by concrete queries) and when-not-to-use, routing non-market railway land to assetfy_db_rail_corridor_parcels or assetfy_db_find_parcels_by_use. It also states the geographic scoping options (nationwide, Landkreis, bbox, radius), leaving little to inference.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.