Skip to main content
Glama

Gridbert

lastgang_heute

Read-onlyIdempotent

Normalband je Viertelstunde (P25/Median/P75 über die letzten 4 Wochen, DESSELBEN Tagtyps — Werktag/Samstag/Sonn-und-Feiertag) + drei Tagesaggregate mit Vergleichswert: Energie heute bisher, Tagesspitze, Monat bisher — jedes als Ist/Normal/Delta-Prozent. 'referenz' nennt IMMER Tagtyp, Fenster und Anzahl der Referenztage — ohne sie ist ein Vergleichswert eine Behauptung, nie unkommentiert lassen. Reicht die Datenlage für ein Aggregat nicht (z.B. Messlücke, zu wenige Referenztage vom selben Tagtyp), ist der jeweilige Normalwert null und der zugehörige '..._grund' erklärt warum — NIE einen Ersatzwert erfinden oder verschweigen, dass er fehlt. 'heute bisher'/'Tagesspitze' vergleichen bewusst NUR bis zur aktuellen Uhrzeit (nicht den ganzen Tag) — der Rest des Tages ist noch nicht gemessen. Braucht eine 15-min-Serie; bei reinen Tageswerten liefert 'referenz' ausreichend=false mit Grund statt eines Fehlers.

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": {
      "serie_ref": "<serie_ref>"
    },
    "name": "lastgang_heute"
  }
}

Input Schema

NameRequiredDescriptionDefault
serie_refYesaus list_load_series/request_data_release

Output Schema

NameRequiredDescriptionDefault
okYesimmer true. Fehler kommen als isError ohne structuredContent zurück (errors.error_result: {ok:false, error_class, fehler}).
dataYesNormalband-Ergebnis (energietools.capabilities.lastgang.normalband.NormalbandCompute, unverändert durchgereicht).
hinweisNoOptionaler Hinweis ans Modell (F14) — Datenstand-Warnung, nächster Schritt, Granularitäts-Caveat. Darf null sein.
workspaceNoNur bei Berater-Accounts: der Arbeitsbereich, in dem dieser Call gelandet ist (dispatch.py stempelt ihn zentral an JEDES Result). Haushalts-Results tragen das Feld nicht.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedOutput schema / properties / data / properties / band / description
      Previous value: -"96 Einträge (Slot 0 = 00:00–00:15, ...), je P25/Median/P75 kWh des Q15-Slots über die Referenztage. null, wenn referenz.ausreichend=false."New value: +"96 Einträge (Slot 0 = 00:00–00:15, ...), je P25/Median/P75 kWh des Viertelstunden-Werts über die Referenztage. null, wenn referenz.ausreichend=false."
    • changedOutput schema / properties / data / properties / heute_luecke_slots / description
      Previous value: -"Anzahl fehlender Q15-Slots seit Tagesbeginn."New value: +"Anzahl fehlender Viertelstunden-Werte seit Tagesbeginn."
  2. Added

TDQS

A4.3/5.0
Behavior5/5

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

Goes well beyond the readOnly/idempotent annotations: it explains that comparisons are restricted to the current time-of-day, that insufficient data yields null normal values with a '..._grund' explanation, and forbids fabricating substitute values. It also documents the graceful-degradation path for daily-only data. Rich behavioral disclosure an agent cannot get from structured fields.

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-loads what the tool produces, then layers the behavioral constraints. Dense but every clause carries a rule (comparison window, null handling, day-type matching). Slightly long and clause-heavy, costing a point.

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?

An output schema exists, so return shapes need not be restated, and the description still explains the interpretive fields ('referenz', '..._grund') and the compare-to-now semantics that the schema cannot convey. Complete for a read-only analytical tool.

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?

Only one parameter with 100% schema coverage, and the schema already points serie_ref at list_load_series/request_data_release. The description adds the meaningful constraint that the referenced series must be a 15-minute series, which is more than the schema states.

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?

States a concrete resource and output: quarter-hour normal bands (P25/Median/P75 over 4 weeks, same day type) plus three daily aggregates with Ist/Normal/Delta comparison. An agent can tell what it returns, though it never names or contrasts sibling tools like analyze_load_profile or load_trend that might overlap.

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?

Gives clear applicability conditions: it needs a 15-minute series, and with daily-only data 'referenz' returns ausreichend=false with a reason instead of an error. That tells the agent when the tool is valid, but it does not explicitly route to an alternative tool when the precondition fails.

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