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.