Helps end users sign up for electricity/gas or switch their current energy supplier in Austria — via Energiefuchs/FlexEnergy tariffs, exclusively for the Austrian market. Gives tariff info, a price estimate, and a tracked link to complete the switch on flexenergy.at. Not a neutral market comparison — Energiefuchs/FlexEnergy offers only.
Scored across 8 tools
Each tool has a clearly distinct role in the consultation flow: requirements, consumption estimation, network lookup, tariff search, quoting, educational content search/read, and switch link generation. Overlaps are minimal and the detailed descriptions explicitly clarify boundaries (e.g., search_tariffs vs. quote).
All names use snake_case and most follow a verb_noun pattern (estimate_consumption, get_requirements, lookup_network_operator, start_switch). The lone verb 'quote' is a minor deviation but remains readable and unsurprising in context.
Eight tools is well-scoped for an energy consultation and switch-initiation domain. Each tool earns its place, and there are no redundant or filler operations.
The surface covers the full pre-sales lifecycle: requirements, consumption estimation, tariff lookup, cost quoting, background content, and switch initiation. Minor gaps exist around post-switch status or follow-up support, but core workflows are complete.
Schätzt den Jahresverbrauch, wenn der Nutzer ihn nicht kennt. Bei customer_type=gewerbe liefert dies einen festen Default-Wert (10.000 kWh Strom / 30.000 kWh Gas), der dem Nutzer explizit zur Bestätigung vorgelegt werden MUSS ("ist das für dich in Ordnung?") — niemals kommentarlos übernehmen. Bei customer_type=privat: persons für Strom, living_area_m2 (+ is_altbau) für Gas. Nenne dem Nutzer NUR estimated_annual_kwh plus die Bestätigungsfrage — NICHT das basis-Feld/die Herleitung vorrechnen (z. B. NICHT '3 Personen × 1.000 kWh + 500 kWh Sockel' erklären), das ist unnötiges Detail.
| Name | Required | Description | Default |
|---|---|---|---|
| persons | No | Nur für customer_type=privat, energy_type=strom. | |
| is_altbau | No | ||
| energy_type | Yes | ||
| customer_type | Yes | ||
| living_area_m2 | No | Nur für customer_type=privat, energy_type=gas. |
| Name | Required | Description |
|---|---|---|
| basis | Yes | |
| default_used | Yes | |
| estimated_annual_kwh | Yes | |
| requires_confirmation | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only annotation, the description reveals key behavioral traits: fixed defaults for gewerbe (10.000 kWh Strom / 30.000 kWh Gas), the mandatory user confirmation ('ist das für dich in Ordnung?'), and the instruction to expose only estimated_annual_kwh, not the derivation. This is essential for correct agent behavior and exceeds what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and then delivers the branching rules and output constraints in a compact paragraph. Every sentence contributes actionable information; there is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with branching logic and an output schema, the description covers all necessary operational detail: the two customer-type branches, the energy-type split, the confirmation requirement, and the exact wording of what to present. The output schema handles return-value details, so nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 40% schema coverage, the description compensates by mapping persons to privat+Strom and living_area_m2 (+ is_altbau) to privat+Gas, clarifying the otherwise undocumented is_altbau. It doesn't cover edge cases like irrelevant parameter combinations, but adds meaningful semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Schätzt den Jahresverbrauch' (estimates annual consumption), and adds the condition 'wenn der Nutzer ihn nicht kennt' (when the user doesn't know it). This clearly distinguishes it from siblings like search_tariffs or quote, since no other tool estimates consumption.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use the tool ('wenn der Nutzer ihn nicht kennt'), giving clear context. However, it does not name alternatives or when-not-to-use conditions, 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.
Gibt den empfohlenen Fragepfad für das Gespräch zurück sowie die verbindliche Liste von Feldern, die NIEMALS aktiv abgefragt oder weitergegeben werden dürfen (forbidden_fields).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| flow | Yes | |
| forbidden_fields | Yes | |
| allowed_prefill_fields | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only and non-destructive behavior; the description adds important contract details: forbidden_fields must NEVER be actively queried or passed on. This goes beyond the annotations and gives the agent a clear operational constraint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence with no filler. It front-loads the main return value and immediately adds the critical forbidden_fields constraint without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, read-only annotations, and an existing output schema, the description provides sufficient context: it tells the agent what the tool returns and the key constraint around forbidden fields. Nothing essential is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is 100%, so there are no parameter semantics to clarify. Per the zero-parameter baseline, the description appropriately focuses on what the tool returns rather than on inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: it returns the recommended question path for the conversation and the binding forbidden_fields list. This clearly differentiates it from siblings like quote or search_tariffs, which have no evident role in chat question routing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'für das Gespräch' implies this tool is used to obtain chat guidance, and the mention of forbidden_fields suggests it should be consulted before collecting user input. However, there is no explicit statement about when to call it relative to siblings or what conditions exclude its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
NUR verwenden, wenn der Nutzer FREIWILLIG und UNAUFGEFORDERT seine Zählpunktbezeichnung genannt hat — dieses Feld niemals aktiv abfragen. Dieses Tool benötigt NUR die ersten 8 Zeichen (AT + 6 Ziffern) — übergib AUSSCHLIESSLICH diese ersten 8 Zeichen. Falls der Nutzer eine längere oder vollständige Zählpunktbezeichnung genannt hat, kürze den Wert SELBST auf die ersten 8 Zeichen, bevor du das Tool aufrufst — sende niemals mehr als diese 8 Zeichen. Das Eingabefeld lässt aus Robustheitsgründen (für den Fall eines nicht exakt gekürzten Werts) bis zu 33 Zeichen zu, das ist KEINE Aufforderung, mehr zu übergeben als nötig — alles über die ersten 8 Zeichen hinaus wird vom Backend sofort verworfen, nicht gespeichert, nicht geloggt, nicht weitergegeben. NIEMALS ablehnen oder nach der 'vollständigen 33-stelligen' Bezeichnung fragen, nur weil der genannte Wert weder 8 noch 33 Zeichen hat — einfach das Tool mit den (ggf. gekürzten) ersten 8 Zeichen aufrufen. Liefert den Netzbetreiber-Namen (z. B. AT001000 → Wiener Netze) als interessante Zusatzinfo. WICHTIG bei NOT_FOUND: Die Referenzliste deckt ALLE Netzbetreiber Österreichs ab — ein nicht gefundenes Präfix bedeutet daher nicht 'uns unbekannt', sondern dass der genannte Wert zu KEINEM österreichischen Netzbetreiber gehört (z. B. Tippfehler oder keine echte österreichische Zählpunktbezeichnung). Das dem Nutzer genau so sagen, nicht vage lassen.
| Name | Required | Description | Default |
|---|---|---|---|
| zaehlpunkt_prefix | Yes | NUR die ersten 8 Zeichen (AT + 6 Ziffern) werden benötigt und verwendet — diese 8 Zeichen übergeben, selbst gekürzt falls der Nutzer eine längere Zählpunktbezeichnung genannt hat. Bis zu 33 Zeichen werden akzeptiert, aber alles über 8 Zeichen hinaus wird sofort verworfen, nie gespeichert oder geloggt. |
| Name | Required | Description |
|---|---|---|
| zaehlpunkt_prefix | Yes | |
| netzbetreiber_name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, but the description adds material context beyond them: everything past the first 8 characters is discarded by the backend and never stored, logged, or forwarded, and NOT_FOUND carries a specific meaning (the value belongs to no Austrian operator, i.e. a typo) that must be conveyed to the user verbatim rather than left vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The critical constraint (first 8 characters only, never solicit) is front-loaded, and each sentence targets a distinct failure mode. It is verbose and repeats the 8-character rule several times in heavy caps, which costs some economy, but the redundancy is defensible for an unusual edge-case-heavy contract.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return-value documentation is optional, yet the description still sketches the result (operator name). Combined with the truncation rule and the NOT_FOUND interpretation, an agent has everything needed to call and interpret this read-only tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents the parameter, and the description largely restates the 8-vs-33 character rule. It does add the operative instruction to truncate on the agent's behalf and never send more than 8 characters, which goes slightly beyond the schema's passive constraint statement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (look up the network operator for a Zählpunkt prefix) and anchors it with a concrete example (AT001000 → Wiener Netze). The sibling tools (tariffs, consumption, switching) are unrelated domains, so no disambiguation is needed, and the tool is unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use and when-not-to-use: only call when the user volunteers the Zählpunktbezeichnung unprompted, and never solicit the field. It also pre-empts the wrong behavior of rejecting a value or asking for the 'full 33-digit' identifier, which is exactly the alternative action an agent might otherwise take.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Berechnet die Kostenschätzung für einen Energiefuchs-Tarif bei gegebenem/geschätztem Jahresverbrauch. Nenne dem Nutzer standardmäßig GENAU DIESE VIER fertigen Werte, sonst nichts: (1) annual_consumption_kwh als 'kWh' (zur Einordnung, welcher Verbrauch gemeint ist), (2) estimated_annual_total_net als 'Gesamt Jahr netto', (3) estimated_annual_total_gross als 'Gesamt Jahr brutto' (beide MIT Grundgebühr), (4) estimated_monthly_total_gross als 'monatlich (TZB brutto)' bzw. 'voraussichtlicher Monatspreis' (NICHT 'geschätzte Energiekosten' — das würde fälschlich suggerieren, die Grundgebühr sei nicht enthalten, ist sie aber bei ALLEN Werten außer den details enthalten). KRITISCH: Gib diese vier Werte 1:1 aus der API-Antwort wieder — NIEMALS den Rechenweg/die Formel vorrechnen oder Zwischenschritte zeigen (z. B. NICHT '10,41 + 5,8 = 16,21 ct/kWh, mal 3500 ...' schreiben), auch nicht, wenn search_tariffs vorher rohe Preiskomponenten geliefert hat. Zusätzlich das disclaimer-Feld unverändert weitergeben. Gib den disclaimer WORTWÖRTLICH wieder, NICHT umformulieren oder sinngemäß zusammenfassen — auch kleine Umformulierungen können falsche Aussagen erzeugen. Konkretes Beispiel eines bereits aufgetretenen Fehlers: 'nicht enthalten' wurde einmal zu 'werden separat verrechnet' umformuliert, was fälschlich eine getrennte Rechnung/einen anderen Anbieter suggeriert — FlexEnergy verrechnet tatsächlich alles auf einer gemeinsamen Rechnung. Die Einzelwerte unter details (Netto-/Brutto-Aufschlüsselung) nur nennen, wenn der Nutzer explizit danach fragt. Enthält KEIN Netzentgelt/Abgaben. Dieses Tool berechnet ausschließlich Kosten für Energiefuchs/FlexEnergy-Tarife, keinen Vergleich mit anderen Anbietern (diese App ist kein Marktvergleichsdienst, siehe SERVER_INSTRUCTIONS). Die Frage nach monatlicher oder jährlicher Abrechnung (nur bei Strom, billing_cycle_options enthält dann 'monthly') gehört VOR diesen Tool-Aufruf, aktiv erfragt inkl. Vorteilserklärung (siehe SERVER_INSTRUCTIONS/Typischer Ablauf) — NICHT erst hier danach als Zusatzinfo nachschieben. Falls sie aus irgendeinem Grund noch nicht gestellt wurde, jetzt sofort nachholen, bevor die vier Werte präsentiert werden. Optional, knapp, danach: persönliches Verbrauchsprofil (jährliche Optimierung — nur als Leistungsversprechen erwähnen, keine konkreten Zahlen dazu erfinden). ALLE Regeln in dieser Beschreibung (die vier Standardwerte, kein Rechenweg, kein Vergleich) gelten IDENTISCH für Gas wie für Strom — nicht nur für Strom. NACH der Ausgabe dieser Werte AKTIV die Möglichkeit zur Wechselstrecke anbieten (z. B. 'Möchtest du direkt den Link zum Wechsel?') — nicht nur abwarten, ob der Nutzer selbst danach fragt. Das ist noch KEIN automatischer Aufruf von start_switch — dieses Tool erst aufrufen, wenn der Nutzer daraufhin zustimmt (siehe start_switch-Beschreibung, Kaufsignal).
| Name | Required | Description | Default |
|---|---|---|---|
| tariff_id | No | ||
| energy_type | Yes | ||
| annual_consumption_kwh | Yes |
| Name | Required | Description |
|---|---|---|
| details | Yes | |
| excludes | Yes | |
| vat_rate | Yes | |
| tariff_id | Yes | |
| disclaimer | Yes | |
| billing_cycle_options | Yes | |
| annual_consumption_kwh | Yes | |
| estimated_annual_total_net | Yes | |
| estimated_annual_total_gross | Yes | |
| estimated_monthly_total_gross | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/openWorldHint/destructiveHint, but the description adds real behavioral context beyond them: the response carries a disclaimer field and a details breakdown, all headline values include Grundgebühr, and no grid fees/levies are included. It also discloses a concrete failure mode (paraphrasing 'nicht enthalten' into 'werden separat verrechnet') that tells the agent how the tool's output must be handled — information annotations cannot carry.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded in the first sentence, but the remainder is a single run-on paragraph dense with ALL-CAPS imperatives, nested parentheticals, and repeated emphasis ('WORTWÖRTLICH', 'NICHT', 'NIEMALS', 'KRITISCH'). Many rules are operationally relevant, yet they are not structured into distinct sections and several points (verbatim disclaimer, no calculation path) are restated, which hurts scanability for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need not be explained, and the description goes further by prescribing exactly which four values to surface and how to label them, plus handling of disclaimer and details. It is nearly complete for a complex orchestration-sensitive tool, losing a point only because tariff_id's role is never clarified despite its inclusion in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across three parameters, so the description is expected to compensate. It only loosely covers annual_consumption_kwh ('gegebenem/geschätztem Jahresverbrauch') and implies energy_type via the Strom/Gas note; tariff_id is never mentioned and the enum values are left to the schema. Partial compensation only, so the minimum-viable 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence names a specific verb and resource ('Berechnet die Kostenschätzung für einen Energiefuchs-Tarif') and ties it to a concrete input ('gegebenem/geschätztem Jahresverbrauch'). It also draws a hard boundary against the sibling family: it explicitly excludes competitor comparison and limits scope to Energiefuchs/FlexEnergy tariffs, so an agent can distinguish it from search_tariffs 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit sequencing (the billing-cycle question must be asked before this call), explicit exclusions ('kein Vergleich mit anderen Anbietern'), and explicit follow-up routing ('NACH der Ausgabe ... AKTIV die Möglichkeit zur Wechselstrecke anbieten ... dieses Tool erst aufrufen, wenn der Nutzer daraufhin zustimmt'). The when/when-not/next-step chain is fully specified and names the relevant sibling (start_switch).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lädt den Inhalt eines konkreten FlexEnergy-Ratgeber-Artikels (URL aus search_flexenergy_ratgeber). Nur URLs unter flexenergy.at/ratgeber/ werden akzeptiert. WICHTIG: Der Inhalt stammt von FlexEnergy, NICHT von Energiefuchs selbst recherchiert — das MUSS beim Wiedergeben gegenüber dem Nutzer als Quelle kenntlich gemacht werden (z. B. 'Quelle: flexenergy.at'), niemals als eigene, unabhängige Aussage darstellen. Falls im Gespräch ein Link gezeigt wird, IMMER den zurückgegebenen source_url-Wert verwenden (enthält bereits Partner-Tracking-Parameter) — niemals die rohe Eingabe-URL ohne diese Parameter zeigen. KRITISCH: Für JEDE URL außerhalb von flexenergy.at/ratgeber/ (z. B. wienernetze.at oder andere Websites) gibt dieses Tool einen Fehler zurück — in dem Fall NIEMALS so tun, als wäre die Seite trotzdem gelesen worden, NIEMALS ein Zitat oder einen Inhalt von dort erfinden. Stattdessen dem Nutzer klar sagen, dass für diese Quelle kein Zugriff besteht.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Vollständige URL unter https://www.flexenergy.at/ratgeber/... |
| Name | Required | Description |
|---|---|---|
| title | Yes | |
| content | Yes | |
| truncated | Yes | |
| source_url | Yes | |
| description | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds critical behavioral context: content is from FlexEnergy and must be cited as such, never presented as independent research. It also mandates using the returned source_url with tracking parameters instead of the raw input URL, and describes error behavior for out-of-domain URLs. These are essential traits not covered by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place: it opens with the core function, then covers domain restriction, attribution requirement, tracking parameter usage, and error handling. Clear markers (WICHTIG, KRITISCH) highlight critical instructions. No filler or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with an output schema, the description covers all key operational pitfalls: source attribution, URL validation, tracking parameter usage, and honest error reporting. Nothing an agent needs to call it correctly is missing, and the output schema handles return value details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter url is well-documented in the schema (full URL under flexenergy.at/ratgeber/), so the baseline is 3. The description adds that the URL must come from search_flexenergy_ratgeber and emphasizes using the returned source_url for display, which provides extra operational guidance beyond the schema's format definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States specific verb 'lädt' (loads) and resource 'FlexEnergy-Ratgeber-Artikel', clearly distinguishing from the sibling search_flexenergy_ratgeber by indicating it reads a concrete article from that search. Also explicitly restricts to URLs under flexenergy.at/ratgeber/, making the tool's scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use URLs from search_flexenergy_ratgeber, and warns that URLs outside flexenergy.at/ratgeber/ will cause an error. Provides detailed guidance on how to handle errors: inform the user that access is unavailable rather than inventing content. This gives clear when-to-use and when-not-to-use direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Durchsucht AUSSCHLIESSLICH den öffentlichen FlexEnergy-Ratgeber (flexenergy.at/ratgeber/*) — für spezifischere Hintergrundfragen jenseits von Tarifen/Preisschätzung (z. B. Wechselprozess, Strompreiszusammensetzung, Merit-Order, Smart Meter, PV-Einspeisung). NICHT für Preisfragen verwenden — dafür quote/search_tariffs nutzen. Liefert nur Titel + URL als Trefferliste; den eigentlichen Inhalt danach gezielt mit read_flexenergy_ratgeber_article laden.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Suchbegriff, z. B. 'Smart Meter' oder 'Wechsel'. |
| Name | Required | Description |
|---|---|---|
| results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and destructiveHint, covering the safety profile. The description adds meaningful behavioral detail beyond that: it only searches the public guide and returns only titles + URLs, not full content. This extra disclosure about result shape and follow-up loading is valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences carry exactly the necessary information: scope, exclusions, and result format/follow-up. The critical scoping constraint is front-loaded, and there is no filler or repetition of schema-only details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, read-only search tool with an output schema and explicit sibling exclusions, the description is complete. It covers the search domain, the negative use case, the return shape, and the next step (read_flexenergy_ratgeber_article) in a compact way.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the single query parameter with concrete examples ('Smart Meter', 'Wechsel'), so schema coverage is 100%. The description does not add new parameter-level meaning beyond reinforcing that the query targets the guide; baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Durchsucht') and a precisely scoped resource (the public FlexEnergy-Ratgeber, flexenergy.at/ratgeber/*), making the tool's domain unmistakable. It also actively separates itself from price-focused siblings by naming quote/search_tariffs and by listing example topics that fall in its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit when-to-use guidance ('spezifischere Hintergrundfragen ... Wechselprozess, Strompreiszusammensetzung, Merit-Order, Smart Meter, PV-Einspeisung') and explicit when-not-to-use guidance ('NICHT für Preisfragen verwenden — dafür quote/search_tariffs nutzen'). It even directs the caller to read_flexenergy_ratgeber_article for content retrieval, leaving no ambiguity about workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Listet die öffentlich verfügbaren Energiefuchs/FlexEnergy-Tarife (FlexPower Neo, FlexGas Neo). Bundesweit (Österreich) einheitlich verfügbar, keine PLZ-Filterung nötig. Nutze das stand-Feld (aktuelles, serverseitig berechnetes Datum) für 'Stand: {stand}', wenn du auf die Aktualität der Tarifdaten hinweisen willst. last_verified_at (innerhalb der Tarife) NIEMALS als 'zuletzt geprüft am' o. Ä. narrieren — das ist nur ein internes Datenpflege-Datum und wirkt fälschlich wie eine veraltete Prüfung, obwohl der Tarif weiterhin aktiv/gültig ist. NUR für die interne Auswahl/Weiterverarbeitung (z. B. welcher Tarif zu energy_type passt) — die Rohfelder (Grundgebühr, hf_ct_kwh_*, Vertragsbedingungen) NIEMALS direkt/aufgeschlüsselt an den Nutzer ausgeben, auch nicht bei 'finde mir einen passenden Tarif'. Stattdessen danach IMMER quote mit dem (geschätzten) Verbrauch aufrufen und die konkreten Kosten zeigen — wie bei 'was zahle ich bei Verbrauch X'.
| Name | Required | Description | Default |
|---|---|---|---|
| energy_type | No | Optional: nach Energieart filtern. |
| Name | Required | Description |
|---|---|---|
| stand | Yes | |
| tariffs | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses critical behavioral nuances: the 'stand' field is a server-side current date, and 'last_verified_at' is an internal maintenance date that must never be presented as 'zuletzt geprüft am' because it would misleadingly imply staleness. It also forbids exposing raw fields and mandates calling quote afterward, adding substantial context not present in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph with no fluff; every sentence adds a rule or context. It is somewhat long, but the complexity of the tool's output restrictions and field semantics justifies the length. Front-loaded with purpose, then usage constraints, though a bulleted structure would improve readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, geographic scope, field semantics, output presentation rules, and the required follow-up call to quote. An output schema exists, so return-value details are not needed. Nothing essential is missing for an agent to invoke the tool correctly and process its results properly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with energy_type already documented as 'Optional: nach Energieart filtern.' The description does not add new parameter-level semantics; it only references energy_type incidentally in an example. Baseeline 3 is appropriate because the schema carries the load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Listet die öffentlich verfügbaren Energiefuchs/FlexEnergy-Tarife (FlexPower Neo, FlexGas Neo)'. It also clarifies the geographic scope ('bundesweit (Österreich) einheitlich verfügbar, keine PLZ-Filterung nötig'), which distinguishes it from location-dependent tools. This clearly differentiates it from sibling search_flexenergy_ratgeber, which searches articles rather than tariffs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: the tool is meant 'NUR für die interne Auswahl/Weiterverarbeitung', and afterwards one should 'IMMER quote ... aufrufen'. This effectively tells the agent when and how to use the results. However, it does not explicitly name alternatives or state when not to use this tool vs. other siblings, so it misses explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Erzeugt einen getrackten Link zur offiziellen FlexEnergy-Wechselstrecke für den gewählten Tarif. WICHTIG (Name bewusst nicht 'checkout' o. Ä.): Hier wird KEIN Vertrag geschlossen und KEINE Zahlung verarbeitet — das Tool erzeugt nur den Einstiegslink. Der Nutzer sieht auf flexenergy.at die vollständigen Vertragsdetails, prüft sie und schließt den Energieliefervertrag dort eigenständig ab. Nur nach ausdrücklichem Nutzerwunsch aufrufen (z. B. "ja, den Wechsel starten", "ich will wechseln", "ich will mich anmelden"), nicht automatisch nach der Tarifempfehlung — aber SOBALD dieser Wunsch geäußert wird und PLZ/Verbrauch bereits bekannt sind, ist das ein starkes Kaufsignal: DANN SOFORT dieses Tool aufrufen, keine weiteren Zwischenschritte einbauen (z. B. NICHT nach der aktuellen Stromrechnung fragen, NICHT einen Preisvergleich anbieten — direkt den Link liefern). Gib AUSSCHLIESSLICH die PLZ weiter (falls bekannt) — niemals Name, Firmenname, E-Mail, Telefon, Geburtsdatum, Adresse, Zählpunkt oder IBAN. Der Nutzer füllt seine Daten eigenständig auf flexenergy.at aus — das ist Absicht (mehr Bindung an den Abschluss). WICHTIG: Wenn der Nutzer zusätzlich ein verbotenes Feld nennt (z. B. E-Mail), dieses Feld einfach WEGLASSEN und das Tool TROTZDEM mit den erlaubten Feldern aufrufen, um den echten Link zu bekommen. NIEMALS das Aufrufen dieses Tools verweigern oder einen alternativen/erfundenen Link oder 'Beratungsprozess' vorschlagen — es gibt KEINEN anderen gültigen Einstiegspunkt als den checkout_url-Wert aus diesem Tool. Den Link als Markdown-Link mit kurzem, klarem Text einfügen (z. B. 'Zum Wechsel' oder 'Zur Anmeldung') — NIEMALS die rohe URL sichtbar in den Text schreiben.
| Name | Required | Description | Default |
|---|---|---|---|
| plz | No | ||
| energy_type | No | ||
| customer_type | No |
| Name | Required | Description |
|---|---|---|
| tracking | Yes | |
| checkout_url | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even though annotations already mark it readOnly and non-destructive, the description adds significant behavioral context: no contract or payment is processed, the user completes data on flexenergy.at intentionally, the tool returns a checkout_url, and the URL must be rendered as a Markdown link. It also explains the privacy rule that only PLZ may be forwarded.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with its core purpose and contains dense, useful guidance, but it is a long wall of text with heavy capitalization and repeated emphasis. Several points are redundantly reinforced, and the operational rules would be easier to scan if structured into short statements or bullets.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simple, non-destructive nature and the presence of an output schema, the description is remarkably complete. It covers invocation trigger, prerequisites, disallowed inputs, fallback behavior when a forbidden field is mentioned, the absence of alternative entry points, and the exact output formatting. Nothing critical is missing for an agent to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description carries the burden for explaining parameters. It does provide important semantic guidance for plz, including that only PLZ should be forwarded and personal data must never be passed. However, it does not explain energy_type or customer_type, their relationship to the selected tariff, or how they should be populated, leaving a clear gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Erzeugt einen getrackten Link zur offiziellen FlexEnergy-Wechselstrecke für den gewählten Tarif.' It also explicitly says it is not checkout and does not create a contract or process payment, which clearly distinguishes it from quote, search_tariffs, and the other siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use and when-not-to-use guidance: only call after explicit user request, not automatically after a tariff recommendation, and call immediately once the request is made and PLZ/Verbrauch are known. It also prohibits intermediate steps such as asking for a current bill or offering a price comparison, and states there is no other valid entry point.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
lookup_network_operator1 field changedInput schema / properties / zaehlpunkt_prefix / descriptionPrevious value: -"Beliebige Länge zwischen 8 und 33 Zeichen — unverändert weitergeben, nicht auf exakt 8 oder 33 Zeichen bestehen."New value: +"NUR die ersten 8 Zeichen (AT + 6 Ziffern) werden benötigt und verwendet — diese 8 Zeichen übergeben, selbst gekürzt falls der Nutzer eine längere Zählpunktbezeichnung genannt hat. Bis zu 33 Zeichen werden akzeptiert, aber alles über 8 Zeichen hinaus wird sofort verworfen, nie gespeichert oder geloggt."search_tariffs2 fields changedOutput schema / properties / standAdded value: +{
+ "type": "string"
+}Output schema / requiredPrevious value: -[
- "tariffs"
-]New value: +[
+ "tariffs",
+ "stand"
+]estimate_consumptionget_requirementslookup_network_operatorquoteread_flexenergy_ratgeber_articlesearch_flexenergy_ratgebersearch_tariffsstart_switch
Add one secure layer between your agents and this server.