Skip to main content
Glama

Get Energy Renovation Plan

assetfy_get_renovation_plan
Read-onlyIdempotent

Energetischer Sanierungsplan (energy retrofit plan) for the residential building(s) on one Flurstück: current state (Bauteilflächen, U-Werte, Heizwärme-, End- and Primärenergie, Effizienzklasse A+–H, CO2, Heizkosten), a step-by-step Einzelmaßnahmen-Fahrplan (Dach/oberste Geschossdecke, Kellerdecke, Fenster, Fassade, then Wärmepumpe) and four Effizienzhaus packages (EH 85, 70, 55, 40 EE; EH 70 is the default recommendation), each with costs, Förderung (BAFA BEG EM, KfW 458, KfW 261, status 21.07.2026), savings and payback. The method is the established one — U-Werte by Baualtersklasse (TABULA / Bekanntmachung Datenaufnahme Wohngebäudebestand), heat loss Q = U · A · F with reduction for walls shared with neighbouring buildings, solar and internal gains, heating efficiency, costs = Σ area × cost rate — so no outside methodology page is needed. Areas come from the cadastre and the LoD2 3D model (Grundfläche, perimeter, Trauf-/Firsthöhe); shared walls are measured against the neighbouring buildings. Takes address, gml_id or lat/lon. The Baujahr is required: the cadastre rarely has it, so pass baujahr from the user or the exposé; without it the tool returns success false and asks for it. Pass what the user knows (energietraeger, keller, dachgeschoss, wohnflaeche_m2, wohneinheiten, bereits_saniert) — every assumption the tool had to make is listed under annahmen. The result always includes the aerial image of the building: look at it and check the points in luftbild_pruefen (PV already on the roof, dormers, extensions, attached neighbours), and call again with corrected parameters if the image contradicts an assumption. A rough estimate, not an Energieausweis or KfW proof — say so and name the Energieeffizienz-Experte as the next step.

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_get_renovation_plan"
  }
}

Input Schema

NameRequiredDescriptionDefault
latNo
lonNo
gml_idNoALKIS gml_id of the Flurstück.
kellerNoCellar. Default: unbeheizt when the cadastre records underground storeys, else kein.
addressNoStreet address, resolved server-side, e.g. "Rägeliner Straße 5, 12683 Berlin".
baujahrNoYear of construction. Required unless the cadastre has it.
bauweiseNoOverrides the measured shared walls, e.g. when the aerial image shows otherwise.
gebaeude_idNoOnly this building (id from a previous result or assetfy_get_parcel_profile). Default: every residential building on the Flurstück.
dachgeschossNoIs the attic heated living space? Default: beheizt when the roof is high enough (≥ 3.5 m from eaves to ridge), else unbeheizt.
selbstnutzerNoOwner-occupier — unlocks the Klimageschwindigkeits- and Einkommensbonus for the heat pump.
wohneinheitenNoNumber of dwellings. Otherwise estimated (1 up to 250 m², then 75 m² each).
energietraegerNoCurrent heating. Default erdgas (assumed, listed under annahmen).
wohnflaeche_m2NoLiving area per building, if known (exposé). Otherwise estimated from the heated volume.
bereits_saniertNoComponents already renovated (set to EnEV-2009 level and left out of the plan).
verbrauch_kwh_aNoMeasured annual consumption of the existing heating in kWh (heating bill). Calibrates savings and payback to real consumption; without it they rest on the calculated demand, which for unrenovated houses is typically 30–50 % above consumption.
energiepreis_eur_kwhNoCurrent price per kWh of the existing heating, if known.
haushaltseinkommen_eurNoTaxable household income per year, for the Einkommensbonus (≤ 30,000 / 40,000 / 50,000 €).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only declare the safe-read profile (readOnly/idempotent/non-destructive/openWorld), but the description discloses far more: the explicit failure mode when Baujahr is absent, that every inferred value is surfaced under 'annahmen', default-inference rules (energietraeger default erdgas, wohneinheiten estimation), the guaranteed aerial image return and the luftbild_pruefen checklist, and the calibration caveat that calculated demand runs 30–50% above consumption for unrenovated houses.

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 content is dense but delivered as one unbroken paragraph that interleaves purpose, methodology justification, input rules and the image-verification loop, which makes it hard to scan. Length is partly defensible for a 17-parameter analytical tool, yet the methodology sentence ('U-Werte by Baualtersklasse... no outside methodology page is needed') is reassurance rather than instruction and could be cut.

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 17 parameters, no required fields and no output schema, the description carries full burden and meets it: it enumerates the result contents, names a returned field (luftbild_pruefen) and the annahmen section, documents fallback defaults, and closes with the correct next step (Energieeffizienz-Experte). Nothing an agent needs to call or interpret the tool 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 88%, so the baseline is 3, and the description earns above that by adding meaning the schema cannot: why baujahr is mandatory and where to source it, why passing user-known values reduces assumptions, and that each skipped input becomes a documented assumption. Some parameters (energiepreis_eur_kwh, haushaltseinkommen_eur thresholds) are left to the schema alone.

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 names a specific deliverable (an energy retrofit plan for residential buildings on one Flurstück) and enumerates its concrete contents: current-state metrics, a step-by-step measure roadmap, and four Effizienzhaus packages with costs, funding and payback. No sibling tool produces anything comparable, so an agent can identify this as the analysis endpoint rather than a raw-data lookup.

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?

It states entry points (address, gml_id or lat/lon), the hard prerequisite (Baujahr is effectively required or the call returns success false), what optional knowledge to supply, and the post-call loop of inspecting the aerial image and re-calling with corrected parameters. It also draws a clear boundary ('not an Energieausweis or KfW proof'). It does not name sibling tools as alternatives, so it stops 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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.