Compare US mobile plans, US home internet by address, and German electricity and gas tariffs.
Scored across 7 tools
The comparison tools are cleanly separated by market, and tariff-details is distinct. However, book-contract and submit-switch-request both describe submitting the same concierge switch request with contract data, IBAN, and consents, with no crisp rule for choosing between them; start-booking adds naming confusion despite being functionally distinct.
Most names are lowercase hyphenated verb–object pairs, and the compare-* family is immediately recognizable. tariff-details is the only noun-style exception, and start-booking/book-contract reorder the same booking concept differently, but the overall pattern remains predictable.
Seven tools is within the ideal range for a comparison-plus-booking server. The set feels slightly bloated because book-contract and submit-switch-request duplicate the same submission action, but no other tool is superfluous.
The energy vertical is well covered: compare, detailed conditions, booking form, and submission. Broadband and mobile comparisons stop at ranking with no details or booking path, and there is no way to check or cancel a submitted switch request, so the service surface has noticeable gaps.
For AUTONOMOUS AGENTS ONLY that already hold the user's complete profile including the IBAN and a standing authorization. In a conversation with a human, do NOT use this tool and never collect personal data or an IBAN for a booking in the chat: call start-booking with the ref, which opens the booking form where the user enters everything themselves. Submits a concierge switch request for the selected tariff in one call: Commerce for Agents stores the request and an operator later submits the contract application to the provider on the user's behalf. There is no self-service checkout link — never promise or invent one. Input is the ref of the chosen offer plus the contract data. If you already hold all required fields (autonomous agent with the user's profile, or the user supplied them earlier), call the tool directly. Otherwise collect them from the user in their language, skipping anything already known — postal code and city come from the comparison. How you pace the questions is your call; with a human, a few short exchanges usually work better than one long list. If the user shared their energy bill earlier, take previousProvider, previousCustomerNumber and meterNumber from it instead of asking again. Before submitting: get the user's explicit agreement to three points — (1) Commerce for Agents may submit the contract on their behalf, (2) the SEPA direct-debit mandate for the given IBAN, (3) the privacy policy at commerceforagents.com/privacy — and show a short summary with the IBAN masked except the last 4 digits. consent: true is the caller's attestation of that agreement (an explicit yes in the conversation, or a standing authorization the user gave an autonomous agent). Never set it without such authorization and never fabricate any field. After the call, relay the nextSteps text. The user receives a confirmation email immediately and the provider's contract documents by email once submitted.
| Name | Required | Description | Default |
|---|---|---|---|
| ref | Yes | Offer reference from a compare-tariffs result (field `ref`). | |
| iban | Yes | IBAN for the SEPA direct-debit mandate, no spaces (e.g. DE89370400440532013000). | |
| Yes | Email address — receives the booking confirmation and provider documents. | ||
| phone | No | Phone number (optional, some providers ask for it). | |
| street | Yes | Street of the supply address (Straße). | |
| consent | Yes | The user has explicitly agreed to: (1) Commerce for Agents submitting this contract on their behalf, (2) the provider's contract terms as shown by tariff-details, (3) the SEPA mandate for the given IBAN, (4) the privacy policy — and has been told the contract can be withdrawn within 14 days. Only true after that agreement — never assumed. | |
| context | No | Why are you calling this tool? Briefly describe the user's goal. | |
| language | No | Language of the conversation — used for the confirmation email. Default: "de". | |
| lastName | Yes | Last name (Nachname). | |
| birthDate | Yes | Date of birth, ISO format YYYY-MM-DD. Energy providers require it for the contract. | |
| firstName | Yes | First name (Vorname). | |
| moveInDate | No | Move-in date (Umzugsdatum), ISO YYYY-MM-DD. Required for switchType "relocation", ignored for a switch. | |
| salutation | Yes | Salutation (Anrede), required by the providers: "herr", "frau" or "divers". | |
| switchType | Yes | "switch": changing provider at the current address (Anbieterwechsel). "relocation": moving in / first contract at this address (Umzug/Neueinzug). | |
| houseNumber | Yes | House number (Hausnummer), e.g. "12a". | |
| meterNumber | No | Meter number (Zählernummer, optional — printed on the meter or the last bill). | |
| accountHolder | No | Account holder if different from the contract holder. | |
| desiredStartDate | No | Desired contract start, ISO YYYY-MM-DD. Omit for the next possible date. | |
| previousProvider | No | Current/previous energy provider. Required for switchType "switch". | |
| previousCustomerNumber | No | Customer number at the previous provider (Kundennummer, optional but speeds up the switch). |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| tariff | Yes | |
| provider | Yes | |
| nextSteps | Yes | |
| requestId | Yes | |
| annualTotalEur | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as destructive/non-idempotent, and the description adds substantial context on top: the request is stored and an operator submits later, confirmation email is immediate while contract documents arrive later, there is no self-service checkout link to promise, and the agent must never fabricate fields. It also clarifies `consent: true` is an attestation of real user agreement.
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?
Front-loaded with the most critical gating information (autonomous agents only, never with humans) and every sentence earns its place for a high-stakes 20-parameter contract tool. However, it is a single dense wall of text; bullet points or short sections would materially improve scannability.
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 high-complexity tool with 11 required parameters, legal consent requirements, and an output schema, the description covers prerequisites, alternatives, the consent flow, data-reuse rules, post-submit expectations (nextSteps, emails), and prohibitions. Nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, but the description adds real meaning beyond the schema: `ref` provenance (from compare-tariffs), reuse of previously supplied bill data for previousProvider/previousCustomerNumber/meterNumber, IBAN masking in the summary, and the exact meaning of `consent` as attestation of explicit agreement.
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 action (submits a concierge switch request for a selected tariff via `ref`) and a distinct resource (Commerce for Agents stores it; an operator submits to the provider). It explicitly differentiates itself from the sibling `start-booking` (human-facing form) and its concierge-vs-self-service framing separates it from `submit-switch-request`.
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 when-to-use (autonomous agent holding full profile, IBAN and standing authorization) and when-not-to-use (human conversation → call start-booking, never collect IBAN in chat). Also provides collection strategy: skip known fields, reuse previously shared bill data, pace questions sensibly, and require explicit three-point consent before submitting.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fixed home internet providers available at a US address, from the FCC National Broadband Map: fiber, cable, DSL, fixed wireless, satellite with max advertised download/upload speeds and a low-latency flag. Keywords: internet providers near me, broadband, ISP, fiber internet, cable internet, home internet comparison. Input: a US street address (preferred) or lat+lon. Optional filters minDownloadMbps and technology. The result has no prices; say so and do not invent prices.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Latitude, if no address is given. | |
| lon | No | Longitude, if no address is given. | |
| address | No | US street address incl. city and state or ZIP. | |
| context | Yes | Why are you calling this tool? Briefly describe the user's goal. | |
| technology | No | Only these technologies. | |
| minDownloadMbps | No | Only providers advertising at least this download speed. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and non-destructive behavior. The description adds genuinely useful behavioral context: results are sourced from the FCC National Broadband Map, include no prices, and the agent must not invent prices. This goes beyond the annotations, though freshness or data limitations are not disclosed.
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 well organized: core output and source first, then input and filters, then the pricing caveat. The keyword list is unnecessary filler, but it does not undermine the overall clarity.
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 no output schema, the description still enumerates the output fields, supported technologies, accepted inputs, optional filters, and the pricing limitation. An agent has enough information to call the tool correctly and set user expectations.
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%, so the schema already documents all six parameters. The description mostly restates the address-or-coordinates input and the two optional filters, adding little beyond what the schema provides. 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 states a specific resource: fixed home internet providers at a US address from the FCC National Broadband Map, along with the key output fields (speeds, low-latency flag). This clearly differentiates it from siblings like compare-mobile-plans and compare-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 for use: home broadband lookup by US address or coordinates, with optional minDownloadMbps and technology filters. It does not explicitly name when not to use it, but the product scope and sibling names make the boundary clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ranks US mobile/cell phone plans (postpaid carriers AT&T/Verizon/T-Mobile and prepaid MVNOs like Mint, Visible, Cricket, Metro, Google Fi, US Mobile, Tello, Boost, Straight Talk, Xfinity Mobile) by 12-month average cost per line (curated, verified catalog; not the whole market). Keywords: cell phone plan, mobile plan comparison, unlimited data plan, family plan, prepaid vs postpaid, best phone plan. Input: number of lines and optional data need, budget per line, prepaid/postpaid preference, must-haves (hotspot, 5g, premium_data, unlimited_data), and preferred network. No address or location is collected — this tool does not check coverage; tell the user to confirm coverage on the carrier's site.
| Name | Required | Description | Default |
|---|---|---|---|
| lines | No | Number of phone lines to price. | |
| context | Yes | Why are you calling this tool? Briefly describe the user's goal. | |
| data_need | No | Minimum data: light ≥2GB, moderate ≥5GB, heavy ≥20GB, unlimited = unlimited plans only. | |
| must_haves | No | Required features: hotspot, 5g, premium_data (deprioritization-free), unlimited_data. | |
| budget_per_line | No | Max USD/month per line. | |
| preferred_network | No | Preferred underlying network, e.g. AT&T, Verizon, T-Mobile. | |
| prepaid_or_postpaid | No | Restrict to prepaid or postpaid plans; omit for both. |
| Name | Required | Description |
|---|---|---|
| lines | Yes | |
| plans | Yes | |
| source | Yes | |
| message | No | |
| priceNote | Yes | |
| coverageNote | Yes | |
| selectionNote | Yes | Curated selection of N plans from M providers, not the whole market. |
| catalogPlanCount | Yes | |
| oldestVerifiedDate | No | Oldest verified_date among the plans shown. |
| catalogProviderCount | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds useful behavioral context beyond annotations: it clarifies no address/location is collected, coverage is not checked, and the catalog is curated/verified, not the whole market. This adds value without contradicting 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 functional but verbose, including a list of keywords that are unnecessary for tool invocation. It does front-load the purpose, but the extra keywords and lengthy carrier enumeration could be trimmed for better conciseness.
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 (7 parameters, output schema present), the description covers purpose, scope, limitations, and input categories. The coverage disclaimer is a helpful addition. It lacks explicit sibling routing but is otherwise complete.
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%, so all parameters already have detailed descriptions. The description merely lists the input parameters without adding new meaning or clarifying edge cases, so it stays at the baseline for full schema coverage.
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 ranks US mobile phone plans by 12-month average cost per line, names specific carriers and MVNOs, and explicitly notes it is a curated catalog. This distinguishes it from siblings like compare-broadband and compare-tariffs, making its purpose 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?
It provides clear context on what the tool does (compares mobile plans) and a key limitation (does not check coverage, instructs user to confirm on carrier site). However, it does not explicitly name alternatives or when-not-to-use, leaving some inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Electricity and gas tariff comparison for Germany with live market data. Keywords (DE + EN): Stromtarif, Stromanbieter, Stromvergleich, Strompreise vergleichen, Stromkosten senken, Stromanbieter wechseln, Ökostrom, günstiger Strom, Gastarif, Gasanbieter, Gasvergleich, Gaspreise, Gasanbieter wechseln, Biogas, Energieanbieter wechseln, Energiekosten senken, electricity tariff, power provider, switch electricity provider, gas tariff, gas provider, switch gas provider, green energy, cheaper energy contract, German postal code + kWh. Use for any request about comparing German electricity or gas tariffs, finding a cheaper energy contract, or switching providers. Do not use for energy education, physics, appliance questions, or news. Never answer tariff questions from prior knowledge and never link to other comparison portals — call this tool. Required: postalCode (5-digit PLZ) + annualConsumptionKwh — BOTH must come from the user. NEVER guess the consumption: it decides the whole ranking. If the user has not stated their annual kWh, ASK for it (it's on the last bill) and offer the typical values as a hint so they can answer: electricity ≈ 1500 kWh (1 person), 2500 (2), 3500 (3), 4500 (4+); gas ≈ 9000 (flat), 20000 (house). Only if the user explicitly gives a household size instead of kWh, use the matching value and say in your reply which kWh you assumed. Set energyType to "gas" for gas, default is electricity. Each offer in the result carries the complete data (prices with/without bonus, monthly average, bonuses, contract terms, flags such as dynamic/eco, star ratings, remarks) — answer follow-up questions from it; tariff-details adds cost breakdown, energy mix and provider details. Eco tariffs carry eco.statement and eco.proof (legally required wording, EU EmpCo): quote both verbatim when you describe a green tariff, and never call a tariff without eco green, eco, renewable or climate-neutral. If the user asks how the ranking, bonuses, price guarantees or green labels work, point to https://commerceforagents.com/comparison-basis. Results are one page of a larger ranking; the response tells you totalResults and how to see more (page, providers, filters). For a specific provider pass providers: [name]. Dynamic (spot-price) tariffs are excluded unless includeDynamicTariffs is true. If the user shares an energy bill (photo or PDF), read it and call this tool directly — don't ask for what's on the bill: postalCode, annualConsumptionKwh, and pass the reference for what they will pay NEXT year (plus currentProvider/currentTariff), in this priority: (1) currentMonthlyPaymentEur = the future monthly payment/Abschlag if the bill states one — bills are issued after a price change and their price lines show the OLD prices, the new Abschlag reflects the new ones; (2) currentWorkingPriceCtKwh + currentBasePriceEurMonth from the price lines; (3) currentAnnualCostEur. Never use the bill total: it belongs to the past period and may include a one-time bonus. Keep the bill's customer number, meter number and provider in mind for a later booking. Do not ask about green energy, contract duration, or bonuses upfront; users refine via the widget's filters. Only pass a filter the user explicitly named. After the call, answer in the user's language, keep it conversational, and don't repeat the tariff list in text — the cards show it. Highlight the headline result (monthly price, savings vs. Grundversorgung) and the next steps: details on request, and booking: when the user wants a tariff, call start-booking with its ref right away — it opens the booking form under the message. Never collect personal data, an IBAN or consent for a booking in the chat; the form takes all of it. Always pass language = the language the user writes in (de or en), so the widget and its buttons speak the same language as the conversation.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Result page (1-based). The response reports totalResults; request further pages to see more of the ranking. | |
| limit | No | Tariffs per page. Default: 10, max 20. | |
| sortBy | No | Market-wide sort: "price" (first-year total, default), "rating" (customer rating, best first), "providerName". | |
| context | No | Why are you calling this tool? Briefly describe the user's goal. | |
| district | No | City district (Ortsteil), only needed when the response reports multiple districts for the postal code and the user's district changes the result. | |
| language | No | Language of the conversation. The widget's texts and its follow-up messages use it; omit only if unsure, then the user's interface locale is used. | |
| bonusMode | No | How one-time bonuses count in prices and ranking. "compliant" (default): only bonuses meeting consumer-protection guidelines; "all": every bonus; "none": prices without any bonus. | |
| greenOnly | No | Only eco tariffs (EU EmpCo definition): electricity from 100% renewable energy proven by guarantees of origin; gas with a declared biogas/hydrogen share. CO2-compensated ("Klimagas", "klimaneutral") tariffs are NOT eco. Default: false. | |
| providers | No | Only offers from these providers (names, e.g. ["Vattenfall", "E WIE EINFACH"]). Use when the user asks about specific providers instead of scanning ranked pages. | |
| energyType | No | Which energy contract to compare: "electricity" (Strom) or "gas". Default: "electricity". | |
| postalCode | Yes | German postal code (Postleitzahl) — 5 digits, e.g. "10115" for Berlin. | |
| regionalOnly | No | Only regional providers / local utilities. Default: false. | |
| currentTariff | No | The user's current tariff name, if known (e.g. from the bill). | |
| goodRatingOnly | No | Only providers with good customer ratings (market operator's threshold). Default: false. | |
| includeDeposit | No | Include tariffs requiring a deposit (Kaution). Default: false. | |
| cancellationMax | No | Maximum cancellation period (Kündigungsfrist). Omit = no filter. | |
| currentProvider | No | The user's current provider, if known (e.g. from the bill). | |
| contractMonthsMax | No | Maximum initial contract duration in months (1, 3, 6, 12 or 24). Default: no limit. | |
| includePrepayment | No | Include tariffs requiring prepayment (Vorauskasse). Default: false. | |
| annualConsumptionKwh | Yes | Annual consumption in kWh as stated by the user (from the last bill) — never guessed. Typical values to help the user answer: electricity ~1500 (1 person), 2500 (2), 3500 (3), 4500 (4+); gas ~9000 (flat), ~20000 (house). | |
| currentAnnualCostEur | No | The user's ONGOING yearly cost on their current contract in EUR: current prices, one-time bonuses EXCLUDED. Do not pass the bill total — a new-customer bonus is paid once, so the total of a bonus year understates what they pay next year. Compute Arbeitspreis × kWh / 100 + 12 × Grundpreis (post-increase prices if the bill announces one), or better: pass currentWorkingPriceCtKwh + currentBasePriceEurMonth and let the server compute it. When given, savings are computed against this instead of the default utility tariff. | |
| includeDynamicTariffs | No | Include dynamic (spot-price) tariffs whose first-year price is only a forecast. Default: false — most German households book fixed-price tariffs. Set true if the user asks for dynamic tariffs. | |
| includePackageTariffs | No | Include kWh-package tariffs (Pakettarife). Default: false. | |
| maxTariffsPerProvider | No | Tariffs per provider in the ranking. Default 1 (best per provider); 0 = all tariffs of every provider. | |
| priceGuaranteeMonthsMin | No | Minimum price-guarantee duration in months. null = no filter (default). | |
| currentBasePriceEurMonth | No | Grundpreis of the user's current contract in EUR per month, gross (a yearly Grundpreis divided by 12). | |
| currentMonthlyPaymentEur | No | The FUTURE monthly payment (Abschlag) stated on the bill for the coming period, e.g. 'Ihr monatlicher Zahlbetrag beträgt zukünftig 159,00 €'. Pass it whenever the bill states one — it already reflects price changes after the billing period, which the bill's Arbeitspreis/Grundpreis lines predate. Takes precedence over the price components. | |
| currentWorkingPriceCtKwh | No | Arbeitspreis of the user's current contract in ct/kWh, gross, as printed on the bill (the new price if an increase is announced). Together with currentBasePriceEurMonth the server computes the ongoing yearly cost itself — preferred over currentAnnualCostEur. |
| Name | Required | Description |
|---|---|---|
| city | Yes | |
| page | Yes | |
| query | Yes | |
| tariffs | Yes | |
| coverageNote | Yes | |
| priceSpanEur | No | |
| totalResults | Yes | |
| referenceNote | No | |
| otherDistricts | No | |
| referenceTariff | No | |
| hiddenDynamicTariffs | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false) already declare the read-only, non-destructive, open-world nature. The description adds substantial behavioral context beyond this: it states results are one page of a larger ranking, dynamic tariffs are excluded unless explicitly requested, eco definitions and proof requirements, the precedence rules for bill parsing (currentMonthlyPaymentEur > price lines > annual cost), and the instruction to never guess consumption. It also clarifies that savings are computed against the default utility tariff unless current cost is provided. No contradictions with 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 long, dense block of text. However, given the tool has 28 parameters, 6 siblings, and complex billing/filter logic, the length is largely justified. It is front-loaded with the core purpose and usage, then proceeds through required inputs, bill parsing, filters, and post-call behavior in a logical order. It could be tightened (e.g., keyword list could be trimmed), but it is structured with clear topical flow and no wasted sentences.
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 this complexity – 28 parameters, an output schema, multiple sibling tools, and nuanced behavioral rules – the description is exceptionally complete. It covers how to obtain required inputs, handle missing data, parse bills, apply filters, interpret results, and guide the user to next steps (tariff-details, start-booking). It even addresses language and widget behavior. Nothing an agent needs to correctly invoke and follow up on is missing, and the output schema is referenced implicitly through the described result structure.
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% and the schema descriptions are already detailed (e.g., currentAnnualCostEur explains bonus exclusion). However, the description adds critical cross-parameter logic not present in the schema: the priority order for extracting current cost from a bill, the condition that postalCode and annualConsumptionKwh must come from the user, the rule to only pass filters the user explicitly named, and the difference between eco and CO2-compensated tariffs. It also provides typical consumption hints and explains how to convert a household size to kWh. This goes far beyond the schema's per-property 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 precise statement of function: 'Electricity and gas tariff comparison for Germany with live market data.' It explicitly differentiates from sibling tools by naming exclusions ('Do not use for energy education, physics, appliance questions, or news') and alternatives (tariff-details for breakdowns, start-booking for booking). The combination of a specific verb, resource, and market scope leaves no ambiguity about what the tool does.
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?
Usage guidance is explicit and actionable: 'Use for any request about comparing German electricity or gas tariffs... Do not use for...' It also details when to ask for missing required inputs, how to handle bill data, when to use providers filters, and when to defer to other tools (e.g., tariff-details, start-booking). The description leaves no doubt about invocation conditions including negative constraints and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Opens the booking form for an offer from a comparison. This call submits, stores and sends NOTHING — it only renders the form; the user decides inside the form whether to file the request. Call it IMMEDIATELY and WITHOUT asking for confirmation, with the ref and the language of the conversation, whenever the user asks for the form or wants a tariff ('Bitte öffne das Buchungsformular', 'open the booking form', 'ich möchte diesen Tarif', 'den nehme ich', 'book #2', 'switch me to this'); a message like that usually comes from the 'Jetzt buchen' button the user just clicked. Do NOT collect any data first and never ask for personal data, an IBAN or consent in the chat: the form below the message takes everything (contract details on the first page, IBAN and consent on the second) and files the request itself. There is no self-service checkout link — never promise or invent one. After the call, say in one sentence that the form is shown below and that the user completes the booking there. Keywords: Buchungsformular öffnen, Tarif buchen, wechseln, Wechsel beauftragen, Vertrag abschließen, Wechselservice, open booking form, book, switch, sign up.
| Name | Required | Description | Default |
|---|---|---|---|
| ref | Yes | Offer reference from a compare-tariffs result (field `ref`). No personal data. | |
| context | No | Why are you calling this tool? Briefly describe the user's goal. | |
| language | No | Language of the conversation; the booking form uses it. Default: de. |
| Name | Required | Description |
|---|---|---|
| ref | Yes | |
| city | No | |
| tariff | Yes | |
| language | Yes | |
| provider | Yes | |
| energyType | Yes | |
| postalCode | Yes | |
| instruction | Yes | |
| monthlyAvgEur | Yes | |
| annualTotalEur | Yes | |
| providerLogoUrl | No | |
| annualConsumptionKwh | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds substantial context beyond this: the tool only renders the form, the user decides whether to file the request inside the form, and the form itself handles data collection and submission. It also documents the absence of a self-service checkout link, which is critical for avoiding false promises.
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 contains dense, valuable operational guidance. It is longer than minimal due to repeated examples and a keyword list, but the behavioral warnings and post-call instructions are worth the length.
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 rich annotations, full parameter documentation, and output schema, the description covers everything needed to invoke the tool safely and correctly: when to call, what to pass, what not to do, and what to say afterward.
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%, so the schema already defines ref, context, and language in detail. The description reinforces that ref and language should be passed and that ref comes from a compare-tariffs result, but it does not add meaningful semantics beyond the schema. 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 clearly identifies the action: 'Opens the booking form for an offer from a comparison.' It also draws a sharp boundary by stating the call 'submits, stores and sends NOTHING,' which distinguishes it from siblings like book-contract or submit-switch-request.
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 triggers with example phrases, instructs to call 'IMMEDIATELY and WITHOUT asking for confirmation,' and specifies what not to do: collect data, ask for personal data/IBAN/consent, or invent a self-service checkout link. It also prescribes the post-call sentence an agent should say.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Files a concierge switch request for an offer from a comparison: contract data, IBAN and the consents in one call. In ChatGPT the booking form inside the tariff card calls this; autonomous MCP clients that hold the user's complete data and authorization call it directly. Stores the request encrypted, sends the confirmation emails, returns only masked data. An operator later submits the contract application to the provider.
| Name | Required | Description | Default |
|---|---|---|---|
| ref | Yes | Offer reference from a compare-tariffs result (field `ref`). | |
| iban | Yes | IBAN as entered in the form; spaces allowed. | |
| Yes | Email address — receives the booking confirmation and provider documents. | ||
| phone | No | Phone number (optional, some providers ask for it). | |
| street | Yes | Street of the supply address (Straße). | |
| context | No | Why are you calling this tool? Briefly describe the user's goal. | |
| language | No | Language of the conversation — used for the confirmation email. Default: "de". | |
| lastName | Yes | Last name (Nachname). | |
| birthDate | Yes | Date of birth, ISO format YYYY-MM-DD. Energy providers require it for the contract. | |
| firstName | Yes | First name (Vorname). | |
| moveInDate | No | Move-in date (Umzugsdatum), ISO YYYY-MM-DD. Required for switchType "relocation", ignored for a switch. | |
| salutation | Yes | Salutation (Anrede), required by the providers: "herr", "frau" or "divers". | |
| switchType | Yes | "switch": changing provider at the current address (Anbieterwechsel). "relocation": moving in / first contract at this address (Umzug/Neueinzug). | |
| houseNumber | Yes | House number (Hausnummer), e.g. "12a". | |
| meterNumber | No | Meter number (Zählernummer, optional — printed on the meter or the last bill). | |
| accountHolder | No | Account holder if different from the contract holder. | |
| authorization | Yes | The three consents the user gave in the form, with the wording versions shown to them. | |
| idempotencyKey | Yes | Random per form instance. A retry with the same key returns the first result instead of filing twice. | |
| desiredStartDate | No | Desired contract start, ISO YYYY-MM-DD. Omit for the next possible date. | |
| previousProvider | No | Current/previous energy provider. Required for switchType "switch". | |
| previousCustomerNumber | No | Customer number at the previous provider (Kundennummer, optional but speeds up the switch). |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| tariff | Yes | |
| provider | Yes | |
| nextSteps | Yes | |
| requestId | Yes | |
| maskedIban | Yes | |
| annualTotalEur | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral detail beyond the annotations: it stores the request encrypted, sends confirmation emails, returns only masked data, and notes that an operator later submits the contract application. This gives the agent a clear picture of side effects and data handling, consistent with the destructive and idempotent hints.
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 four sentences with no filler. It front-loads the core purpose, then adds invocation context, behavioral side effects, and downstream processing. Every sentence contributes useful information.
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 complex tool with 21 parameters, a nested authorization object, and an output schema, the description is complete enough: it explains what the tool does, when to call it, what side effects occur, and what the user sees (masked data). The output schema covers return values, and the annotations cover safety and idempotency.
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%, so the schema already documents every parameter. The description adds only a high-level summary ('contract data, IBAN and the consents in one call') and does not need to explain individual parameters. This matches the baseline for fully covered schemas.
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 uses a specific verb and resource: 'Files a concierge switch request for an offer from a comparison.' It clearly identifies the operation and its inputs (contract data, IBAN, consents). It does not explicitly differentiate from siblings like book-contract or start-booking, though the 'from a comparison' and 'booking form inside the tariff card' context helps.
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 invocation context: the booking form inside the tariff card calls this in ChatGPT, while autonomous MCP clients with complete user data and authorization call it directly. It does not explicitly state when not to use it or name alternative tools, so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full conditions for one tariff from a previous compare-tariffs result: price composition, price guarantee scope, contract duration/prolongation/cancellation, deposit, energy-source mix, customer ratings, and for eco tariffs the required eco statement + proof (quote verbatim). Keywords: Tarifdetails, Vertragsbedingungen, Preisgarantie, Kündigungsfrist, Vertragslaufzeit, AGB, tariff conditions, contract details. Input is the ref of an offer from compare-tariffs. Call when the user asks about a specific tariff's conditions before deciding. Answer in the user's language.
| Name | Required | Description | Default |
|---|---|---|---|
| ref | Yes | Offer reference from a compare-tariffs result (field `ref`). | |
| context | Yes | Why are you calling this tool? Briefly describe the user's goal. | |
| language | No | Language of the conversation (for the eco statement and proof texts). Default: de. |
| Name | Required | Description |
|---|---|---|
| eco | No | |
| ref | Yes | |
| tariff | Yes | |
| remarks | No | |
| contract | Yes | |
| provider | Yes | |
| energyType | Yes | |
| costBreakdown | Yes | |
| energySources | No | |
| annualTotalEur | Yes | |
| customerRatings | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, open-world behavior. The description adds meaningful behavioral details beyond that: the requirement to 'quote verbatim' eco statements/proofs and to 'Answer in the user's language.' No contradiction with annotations exists.
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 first sentence is dense and informative, and the when-to-call guidance earns its place. However, the long multilingual keyword list ('Tarifdetails, Vertragsbedingungen, Preisgarantie...') is redundant filler that adds no functional guidance 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?
Given the output schema exists and annotations cover side effects, the description covers the essential contextual needs: where the ref comes from, when to invoke the tool, what content is returned, and language behavior. It is not missing critical call prerequisites, though the keyword block adds noise.
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%, so the schema already documents ref, context, and language well. The description mostly restates the ref provenance ('Input is the ref of an offer from compare-tariffs') already present in the schema, adding little new parameter-level meaning.
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-like purpose: 'Full conditions for one tariff from a previous compare-tariffs result' and enumerates the exact content areas. It clearly distinguishes this tool from compare-tariffs (which compares) and from booking/switch tools by scoping it to one tariff's conditions.
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 call: 'Call when the user asks about a specific tariff's conditions before deciding.' It also anchors input to a prior compare-tariffs result. However, it does not explicitly state when not to use it or name alternative tools for other intents, so it falls just 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
compare-mobile-plansbook-contractcompare-broadbandcompare-tariffsstart-bookingsubmit-switch-requesttariff-detailsAI agents compare and sign up for Texas utility plans: electricity, internet, gas, water, trash.
Compare Japan's household fixed costs: electricity, city gas, fiber and mobile plans, with bundles.
Search U.S. cell plans, compare supported costs, find wireless news, and get switching guidance.
US telecom availability and intelligence by address, with FCC provenance. Fiber-first.
Add one secure layer between your agents and this server.
