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.
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. Übergib den vom Nutzer genannten Wert unverändert. JEDE Länge zwischen 8 und 33 Zeichen ist gültig (z. B. AT001000, AT001000000 oder eine volle 33-stellige Zählpunktbezeichnung) — NICHT nur exakt 8 oder exakt 33. Das Backend extrahiert automatisch die ersten 8 Zeichen (AT + 6 Ziffern) und ignoriert den Rest. 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 dem genannten Wert 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 | Beliebige Länge zwischen 8 und 33 Zeichen — unverändert weitergeben, nicht auf exakt 8 oder 33 Zeichen bestehen. |
| Name | Required | Description |
|---|---|---|
| zaehlpunkt_prefix | Yes | |
| netzbetreiber_name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and destructiveHint annotations, the description discloses key backend behavior: the first 8 characters are extracted automatically, the rest is ignored, any length between 8 and 33 is accepted, and NOT_FOUND means the value is not an Austrian operator. This substantially clarifies expected runtime behavior and error semantics.
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 and front-loads the most important behavioral constraint (only reactive use). There is some repetition around the 8/33-character rule and the warning not to reject values, but the emphasis is arguably intentional to prevent a costly agent error. It remains appropriately sized for the guardrails it communicates.
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 fully covers the tool's trigger condition, input handling, output examples, and NOT_FOUND interpretation. Given the simple single-parameter schema, output schema, and safety annotations, nothing essential is missing for an agent to invoke this 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?
The schema already documents min/max length and the instruction not to insist on exactly 8 or 33 characters. The description adds crucial semantics: pass the user's value through unchanged, do not reject based on length, and know that the backend handles extraction. This goes well beyond the structured 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 clearly states the tool's function: it returns the Austrian network operator name for a given Zählpunktbezeichnung (e.g. AT001000 → Wiener Netze). This is a specific lookup operation with a distinct resource, and it is easily distinguishable from the sibling tools, which handle tariffs, quotes, requirements, and articles.
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 use when the user voluntarily and unsolicited provides their Zählpunktbezeichnung, and never proactively ask for this field. It also specifies exact handling of NOT_FOUND results, telling the agent to communicate that the value does not belong to any Austrian network operator rather than being vague.
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. KEIN Vergleich mit Preisen anderer Anbieter — stattdessen kurz auf den Mehrwert hinweisen. IMMER, sofort zusammen mit diesen Werten (nicht erst später, nicht nur auf Nachfrage) — egal ob es eine Wechsel- oder eine Neueinzugs-/Neuanmeldungs-Anfrage ist: NUR falls billing_cycle_options 'monthly' enthält (aktuell nur bei Strom, NICHT bei Gas — dort ist es technisch nicht möglich) auf die monatliche Verbrauchsabrechnung hinweisen — damit man immer nur das zahlt, was man tatsächlich verbraucht hat, keine ärgerliche Nachzahlung bei der Jahresabrechnung. Ein Satz reicht, aber NIEMALS weglassen, wenn monatliche Abrechnung verfügbar ist. 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 declare the tool read-only, and the description adds a wealth of behavioral detail: exactly four values must be output, no calculation steps may be shown, the disclaimer must be passed word-for-word, details are only provided on request, and a concrete past error is cited as a cautionary example. This goes far beyond what annotations convey.
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 extremely long and dense, with many rules, conditions, examples, and repeated warnings. It is structured decently via numbered output values, CAPS for emphasis, and clear sections, and every sentence carries operational value, but it is far from concise. A tighter organization with a shorter imperative spec would serve agents just as well.
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 complexity, the description is remarkably complete: it specifies exact output values, wording, disclaimers, optional details, fuel-type differences, monthly billing conditions, downstream switch-offer behavior, and explicit boundaries against recalculation and comparison. Since an output schema exists, return-value documentation is not needed in the description. The main gap is tariff_id input semantics, but that is minor in light of the overwhelming completeness.
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?
Input schema coverage is 0%, and the description provides some semantic meaning: annual consumption as the basis for the estimate, and Strom/Gas as the energy types. However, the optional tariff_id parameter is never explained, and the description's parameter mentions are largely incidental to output formatting rather than input documentation. Some value is added, but not enough to fully compensate for missing schema descriptions.
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: 'Berechnet die Kostenschätzung für einen Energiefuchs-Tarif bei gegebenem/geschätztem Jahresverbrauch.' It clearly identifies the tool as producing a cost estimate for a tariff, which is distinct from sibling tools like estimate_consumption (consumption estimation) or search_tariffs (tariff search). The title also reinforces this.
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 provides extensive when/when-not guidance: show details only if the user explicitly asks, only mention monthly billing if billing_cycle_options contains 'monthly' (explicitly not for gas), never compare prices, and never automatically call start_switch—only after the user agrees. It also explicitly references search_tariffs and explains that even if it provided raw price components, the agent must not recalculate.
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 only say readOnlyHint=true and destructiveHint=false. The description adds substantial behavioral context: content is from FlexEnergy, not self-researched; it must be attributed as 'Quelle: flexenergy.at'; the source_url value must be shown instead of raw input; and external URLs fail with a clear no-fabrication policy. This goes far beyond the 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 long but dense, with WICHTIG and KRITISCH markers that help an agent prioritize instructions. It earns its length, though there is minor repetition of the path restriction and attribution requirement, which keeps it from a perfect score.
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 tool with an output schema and safety annotations, the description covers input provenance, domain restriction, exact error behavior, source attribution, and link display rules. Nothing essential is missing for correct and safe use.
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 baseline is 3. The description adds meaning beyond the schema: the URL must come from search_flexenergy_ratgeber, must be under flexenergy.at/ratgeber/, and the source_url returned must be used for display. These constraints materially aid correct invocation.
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: 'Lädt den Inhalt eines konkreten FlexEnergy-Ratgeber-Artikels' (loads the content of a specific article). It also scopes the tool by requiring a URL from search_flexenergy_ratgeber and restricting to flexenergy.at/ratgeber/, clearly differentiating it from search and other sibling tools.
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 explicitly says the URL comes from search_flexenergy_ratgeber, establishing when the tool should be used. It also gives an explicit when-not: any URL outside flexenergy.at/ratgeber/ returns an error, and the agent must not pretend to read it, must not fabricate content, and should tell the user there is no access. This is direct usage guidance with clear exclusions.
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?
The annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral detail beyond that: it returns only 'Titel + URL als Trefferliste', not full content, and is limited to public ratgeber pages. This clarifies what the agent can expect from the result.
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 clause adds value: scope, excluded use case, alternative tools, return shape, and next-step action. Key constraints are front-loaded with 'AUSSCHLIESSLICH' and 'NICHT', making the boundaries immediately visible.
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 search tool with annotations covering safety and an output schema present, the description is complete. It tells the agent what to search, what not to search, what the response contains, and which sibling to use for the next step.
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 baseline is 3, but the description adds domain context by giving examples of suitable query topics like 'Smart Meter' and 'Wechsel' and excludes price-focused queries. This helps the agent form better queries than the bare 'Suchbegriff' schema description alone.
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: 'Durchsucht AUSSCHLIESSLICH den öffentlichen FlexEnergy-Ratgeber' and gives the URL scope. It explicitly contrasts itself with quote/search_tariffs and read_flexenergy_ratgeber_article, so an agent can distinguish it from sibling tools without inspecting schemas.
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 states exactly when to use it ('für spezifischere Hintergrundfragen jenseits von Tarifen/Preisschätzung') and when not to ('NICHT für Preisfragen verwenden'), naming quote/search_tariffs as the alternative. It also tells the agent to follow up with read_flexenergy_ratgeber_article for content, which is strong routing guidance.
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.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Add one secure layer between your agents and this server.
Each tool maps to a distinct step in the user journey: estimating consumption, retrieving requirements, looking up the network operator, quoting a tariff, searching/reading guides, listing tariffs, and starting a switch. Although search_flexenergy_ratgeber and read_flexenergy_ratgeber_article are related, their search-vs-read boundary is clear.
Most tools follow a clear verb_object snake_case pattern (estimate_consumption, search_tariffs, start_switch). The main deviation is 'quote', which lacks an explicit object and is somewhat ambiguous as verb vs noun; otherwise the naming is consistent.
Eight tools is well-scoped for a focused energy-advisory and switching assistant. Each tool supports a distinct part of the conversation without redundant utilities or excessive surface area.
The tool surface covers the full core flow: estimate usage, search tariffs, calculate a quote, provide switch link, plus supporting lookup and content-reading tools. There are no obvious dead ends or missing operations for the stated purpose.