Skip to main content
Glama

Plan a roof (solar roof check)

plan_roof
Read-onlyIdempotent

Plan solar modules on a house's roof from the Bavarian 3D building model, the aerial photo and the laser scan, exactly as Sky Solar's solar roof check page does: modules, kWp, kWh a year with measured weather, shade loss and self-use with and without a battery, each roof face with tilt and direction, the obstacles found, money a year at public rates (own use and feed-in) for a choice of battery sizes (none, or 4 to 20 kWh; any whole kWh in between on request), the municipal subsidy, the price guide ("from" and a recommendation, only inside Sky Solar's service area) and the payback (on the person's own offer price, else on the guide's recommendation), kWh month by month and per face, the worst shade casters, questions about unsure spots for the person and what else to ask them, notes on likely model errors, and a solar roof check link that opens this plan in 3D for the person to check, change and send an enquiry from. On a new plan (house) where the aerial photo speaks against the roof's outline, the AI outline check runs by itself, as on the page: "applied" says what it changed. A link is read as it is; "notes" says when the outline may still be wrong. Give house (from find_house) for a new plan, or link to read and explain a plan the person already has. Pass the person's answers to the questions with answers. Works outside Sky Solar's service area too and says so. An example, not a quote; the only prices are the report's price guide (price_guide: "from" and a recommendation, a rough guide, never an offer), and the payback counts the person's own offer or, without one, that recommendation.

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

Input Schema

NameRequiredDescriptionDefault
evNoAn electric car is (or will be) charged at home: by default 15,000 km a year, about 2,955 kWh, charged in the evening (edit_roof device sets km, when and how fast).
linkNoA solar roof check link (https://pv.skysolar.de/dachcheck/#d=…), as plan_roof, edit_roof or the solar roof check page gave it.
houseNoThe house id from find_house ("musterhaus" is the example house).
answersNoThe person's answers to the last answer's "questions".
geometryNotrue: add a complete geometry snapshot to the answer (the default stays short): for every face and dormer roof its outline, size, usable box and the eave and slope axes (with compass bearings), every module with its face, position in the face's own metres and orientation, the module fields (rows × columns), and the obstacles with their outlines and clearances. Everything in the same metres the edits take.
heat_pumpNoA heat pump heats the house: by default about 4,500 kWh a year, mostly in winter (edit_roof device sets the person's own figure).
offer_eurNoThe total price on an offer the person already has, euros before any subsidy (0 clears it): the payback then counts it. Without one the payback counts the price guide's recommendation (summary.price_guide). Never pass a price of Sky Solar's as an offer.
roof_stepNoHow demanding the roof is for the price guide: "simple" (one field, plain tiles), "normal", "complex" (several directions, many small fields, Biberschwanz tiles); "auto" (the default) works it out from the plan. Changes the price guide only.
optimizersNoThe person wants module optimizers: they are in both prices of the price guide. Without them the recommendation adds them anyway where the plan shows shade or several directions.
battery_kwhNoBattery size, kWh: 0 for none, or a whole number from 4 to 20 (default 8).
backup_powerNoThe person wants backup power (Notstrom): it is in both prices of the price guide.
battery_typeNoThe battery's type, both DC-coupled hybrid systems: "nv5" (low voltage, the default) charges and discharges at most 5 kW whatever its size; "hv1c" (high voltage) at most 1C, as many kW as it has kWh (10 kWh: 10 kW, 4 kWh: only 4 kW). Only with a battery. It matters at peaks: an e-car charging at more than 5 kW; a household on its own comes out nearly the same with both, with a heat pump too.
consumption_kwhNoThe household's electricity use a year, kWh, without car or heat pump (default 4,500).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / backup_power
      Added value: +{
      +  "description": "The person wants backup power (Notstrom): it is in both prices of the price guide.",
      +  "type": "boolean"
      +}
    • changedInput schema / properties / offer_eur / description
      Previous value: -"The total price on an offer the person already has, euros before any subsidy (0 clears it): the solar roof check link then shows the payback. Never a price of Sky Solar's."New value: +"The total price on an offer the person already has, euros before any subsidy (0 clears it): the payback then counts it. Without one the payback counts the price guide's recommendation (summary.price_guide). Never pass a price of Sky Solar's as an offer."
    • addedInput schema / properties / optimizers
      Added value: +{
      +  "description": "The person wants module optimizers: they are in both prices of the price guide. Without them the recommendation adds them anyway where the plan shows shade or several directions.",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / roof_step
      Added value: +{
      +  "description": "How demanding the roof is for the price guide: \"simple\" (one field, plain tiles), \"normal\", \"complex\" (several directions, many small fields, Biberschwanz tiles); \"auto\" (the default) works it out from the plan. Changes the price guide only.",
      +  "enum": [
      +    "auto",
      +    "simple",
      +    "normal",
      +    "complex"
      +  ],
      +  "type": "string"
      +}
  2. Changed1 schema field changed
    • addedInput schema / properties / battery_type
      Added value: +{
      +  "description": "The battery's type, both DC-coupled hybrid systems: \"nv5\" (low voltage, the default) charges and discharges at most 5 kW whatever its size; \"hv1c\" (high voltage) at most 1C, as many kW as it has kWh (10 kWh: 10 kW, 4 kWh: only 4 kW). Only with a battery. It matters at peaks: an e-car charging at more than 5 kW; a household on its own comes out nearly the same with both, with a heat pump too.",
      +  "enum": [
      +    "nv5",
      +    "hv1c"
      +  ],
      +  "type": "string"
      +}
  3. Changed2 schema fields changed
    • changedInput schema / properties / ev / description
      Previous value: -"An electric car is (or will be) charged at home: about 2,700 kWh a year more."New value: +"An electric car is (or will be) charged at home: by default 15,000 km a year, about 2,955 kWh, charged in the evening (edit_roof device sets km, when and how fast)."
    • changedInput schema / properties / heat_pump / description
      Previous value: -"A heat pump heats the house: about 4,500 kWh a year more."New value: +"A heat pump heats the house: by default about 4,500 kWh a year, mostly in winter (edit_roof device sets the person's own figure)."
  4. Changed1 schema field changed
    • addedInput schema / properties / geometry
      Added value: +{
      +  "description": "true: add a complete geometry snapshot to the answer (the default stays short): for every face and dormer roof its outline, size, usable box and the eave and slope axes (with compass bearings), every module with its face, position in the face's own metres and orientation, the module fields (rows × columns), and the obstacles with their outlines and clearances. Everything in the same metres the edits take.",
      +  "type": "boolean"
      +}
  5. Changed4 schema fields changed
    • changedInput schema / properties / battery_kwh / description
      Previous value: -"Battery size, kWh: one of 0, 5, 8, 10, 15 (default 8)."New value: +"Battery size, kWh: 0 for none, or a whole number from 4 to 20 (default 8)."
    • addedInput schema / properties / battery_kwh / maximum
      Added value: +20
    • addedInput schema / properties / battery_kwh / minimum
      Added value: +0
    • changedInput schema / properties / battery_kwh / type
      Previous value: -"number"New value: +"integer"
  6. Changed2 schema fields changed
    • changedInput schema / properties / link / description
      Previous value: -"A Dachcheck link (https://pv.skysolar.de/dachcheck/#d=…), as plan_roof, edit_roof or the Dachcheck page gave it."New value: +"A solar roof check link (https://pv.skysolar.de/dachcheck/#d=…), as plan_roof, edit_roof or the solar roof check page gave it."
    • changedInput schema / properties / offer_eur / description
      Previous value: -"The total price on an offer the person already has, euros before any subsidy (0 clears it): the Dachcheck link then shows the payback. Never a price of Sky Solar's."New value: +"The total price on an offer the person already has, euros before any subsidy (0 clears it): the solar roof check link then shows the payback. Never a price of Sky Solar's."
  7. Changed1 schema field changed
    • addedInput schema / properties / offer_eur
      Added value: +{
      +  "description": "The total price on an offer the person already has, euros before any subsidy (0 clears it): the Dachcheck link then shows the payback. Never a price of Sky Solar's.",
      +  "maximum": 300000,
      +  "minimum": 0,
      +  "type": "number"
      +}
  8. Added

TDQS

A3.8/5.0
Behavior4/5

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

Beyond the annotations, the description discloses that it works outside the service area and says so, that the AI outline check runs by itself on new plans and reports via "applied", that a link is read as-is, and that the price guide is a rough guide and never an offer. Those are real behavioral facts an agent would otherwise not know. The near-side-effect of the outline check ("what it changed") sits slightly awkwardly against readOnlyHint but is framed as part of the returned plan, not a contradiction.

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

Conciseness2/5

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

The opening sentence runs well over a hundred words as a comma-separated inventory of outputs, burying the actionable instruction (house or link) in the middle of the block. Phrases like "An example, not a quote" are ambiguous and add noise. Structure is poor for an agent that needs the calling rule up front.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 13 optional parameters, no output schema and an open-world read operation, the description compensates by enumerating what the report returns (faces, obstacles, monthly kWh, questions, notes, link) so the agent knows what comes back. It also covers service-area behavior and the answers follow-up. Missing only practical detail such as latency or what happens on an invalid link/house.

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 the baseline is 3, but the description adds meaning on top: it constrains offer_eur ("the payback counts the person's own offer or, without one, that recommendation", "Never pass a price of Sky Solar's as an offer") and explains the answers loop and the house-vs-link choice. Battery sizing, roof_step and optimizers are largely restatements of schema text, which keeps it from a 5.

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?

The description names a specific verb and resource — planning solar modules on a house roof from the Bavarian 3D building model, aerial photo and laser scan — and enumerates the report's contents (kWp, kWh, shade loss, self-use, subsidy, payback, monthly figures). It clearly distinguishes itself from edit_roof and find_house by naming them. The purpose is only recoverable after parsing a very long opening sentence, which costs it the top mark.

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?

Explicit routing is given: "Give house (from find_house) for a new plan, or link to read and explain a plan the person already has", plus "Pass the person's answers to the questions with answers" for the follow-up loop. The mention that edit_roof device sets the car/heat-pump figures implicitly marks edit_roof as the alternative for changes. No explicit when-not-to-use case is stated, so it stops short of 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.

Resources