Skip to main content
Glama
Sign In

Sky Solar

by de.skysolar
OverviewDiscussionsAdmin

Start a 3D picture of the plan (solar roof check)

roof_picture_start
Read-only

An image (PNG, or JPEG when large) of the plan behind a solar roof check link, drawn by the solar roof check page itself in 3D, from a fixed, named view: front (the start view the page opens with, three-quarters from above), above (straight down, north up), north, east, south or west (from that side, 35° up, about square on to a roof face), or sun (the roof's sun map, "Sonnendach", from above). The same plan and view give the same picture (within a calendar year, while the map data stays the same): the camera follows the house, the sun stands at 21 June, 13:00, nothing moves, no cat and no editing marks, the plan's fine print as on the page. So variants of a plan compare side by side, which screenshots of the page do not (its view moves). Size up to 1600 × 1000 pixels (default). Answers at once with a job_id: the server draws the 3D in software, which takes 30 to 150 seconds. Then call roof_picture_status every 10 seconds until done, and roof_picture_file to get the picture (a JPEG instead of a PNG when the PNG would be over about 1.4 MB). The picture is kept for 15 minutes under the random job_id; nothing else is stored.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "link": "<link>"
    },
    "name": "roof_picture_start"
  }
}

Input Schema

NameRequiredDescriptionDefault
linkYesA solar roof check link (https://pv.skysolar.de/dachcheck/#d=…), as plan_roof, edit_roof or the solar roof check page gave it.
viewNoWhich view: front (the start view the solar roof check page opens with: three-quarters from above, square on to the main south-facing roof); above (straight down from above, north up); north (from the north, 35° up (about square on to a roof face, and over the neighbours)); east (from the east, 35° up); south (from the south, 35° up); west (from the west, 35° up); sun (the roof's sun ("Sonnendach") on the plain white model, straight down from above, north up: the warmer a spot, the more sun over the year). Default front.front
widthNoWidth in pixels, 640 to 1600 (default 1600).
heightNoHeight in pixels, 400 to 1000 (default 1000).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.3/5.0
Behavior5/5

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

Going well beyond the annotations, it discloses that the call is asynchronous (returns a job_id immediately), that rendering takes 30–150 seconds, that output is PNG or JPEG depending on the ~1.4 MB threshold, that the image is retained only 15 minutes under a random job_id, and that nothing else is stored. It also pins down determinism (fixed camera, sun at 21 June 13:00, stable within a calendar year) which explains why results are comparable.

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 information is front-loaded and mostly earns its place, but the first sentence runs to roughly ninety words with stacked parentheticals, and flourishes like 'no cat and no editing marks' and 'the plan's fine print as on the page' add color at the cost of density. The async workflow instructions could be split out more cleanly.

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?

There is no output schema, so the description must carry the return contract, and it does: immediate job_id, polling cadence, terminal fetch tool, image format variability, and retention window. For an asynchronous render job with four well-documented parameters, nothing an agent needs in order to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With schema coverage at 100%, the schema already documents link, view (with per-value explanations), width and height. The description largely restates the view list and the 1600 × 1000 maximum rather than adding new constraint meaning, so the baseline of 3 is appropriate.

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 opening states a concrete verb and resource — an image (PNG, or JPEG when large) of the plan behind a solar roof check link, rendered in 3D by the page itself — and enumerates the exact views. It is clearly distinguishable from siblings such as roof_report_pdf (a document) and roof_picture_file (retrieval of an already-drawn image).

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 description gives an explicit reason to prefer this over ad-hoc screenshots ('So variants of a plan compare side by side, which screenshots of the page do not') and lays out the full follow-up sequence: poll roof_picture_status every 10 seconds, then fetch via roof_picture_file. It does not, however, contrast against roof_report_pdf when a full report rather than a picture is wanted, and gives no explicit when-not-to-use case.

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

All Sky Solar toolsInspect
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.

Resources