Commerce for Agents

Server Details

Compare US mobile plans, VPNs, travel eSIMs, home internet by address, and German energy tariffs.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 100.0% over 19 days
Last Tested: 2026-10-16 17:24
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.2/5.0

Scored 2026-10-04 21:35 across 9 tools

Disambiguation2/5

Most comparison tools target distinct domains, but book-contract and submit-switch-request both appear to file the same concierge switch request with contract data, IBAN, and consent. The descriptions do not clearly delineate when to use one over the other, creating a real risk of misselection.

Naming Consistency4/5

The set mostly follows a readable kebab-case verb_noun pattern: compare-*, book-contract, start-booking, submit-switch-request. The only notable deviation is tariff-details, which is noun_noun rather than verb-led, but overall the convention is stable.

Tool Count5/5

Nine tools is well-scoped for a comparison-and-booking agent: five distinct comparison verticals, two detail/booking-form tools, and two submission tools. Each tool appears to earn its place, with no severe bloat or thinness.

Completeness4/5

The surface covers comparison across broadband, eSIM, mobile, energy, and VPN, plus tariff details and booking/submission workflows. Minor gaps remain around booking status, cancellation, or post-submission management, but core autonomous commerce workflows are covered.

Available Tools

9 tools

book-contractRequest Energy Contract (Concierge Switch)A

Destructive

Inspect

Files a concierge switch request with the complete contract data in one call. Intended for autonomous agents that already hold the user's full profile, IBAN and a standing authorization; in a conversation with a person, start-booking opens a form in which the user enters these data. Commerce for Agents stores the request encrypted and an operator submits the contract application to the provider; the user receives a confirmation email at once and the provider's contract documents later. There is no self-service checkout link. Input: the ref of the chosen offer plus the contract data. Postal code and city come from the comparison; previousProvider, previousCustomerNumber and meterNumber are printed on the last energy bill. consent: true attests that the user explicitly agreed to (1) Commerce for Agents submitting the contract on their behalf, (2) the SEPA direct-debit mandate for the given IBAN and (3) the privacy policy at commerceforagents.com/privacy, either by an explicit yes in the conversation or by a standing authorization given to the agent. The response contains nextSteps for the user.

ParametersJSON Schema

Name	Required	Description
`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).
`email`	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. True only after that agreement.
`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).

Output Schema

ParametersJSON Schema

Name	Required	Description
`status`	Yes
`tariff`	Yes
`provider`	Yes
`nextSteps`	Yes
`requestId`	Yes
`annualTotalEur`	Yes

TDQS

A4.9/5.0

Behavior5/5

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

Beyond the destructiveHint annotation, the description discloses the full workflow: encrypted storage, operator submission to the provider, immediate confirmation email, and later contract documents. It also details the consent requirements, including the 14-day withdrawal notice, which is critical for a binding action.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but every sentence earns its place. It front-loads the main action and intended audience before workflow details, and it groups parameter sources usefully without repeating every schema field.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a high-stakes 19-parameter tool with a rich schema and output schema, the description covers preconditions, workflow, timing, consent, and response contents. Nothing essential for selecting or invoking the tool correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds meaningful context beyond the schema: postal code and city come from the comparison, previousProvider/previousCustomerNumber/meterNumber are found on the last energy bill, and consent:true attests to specific legal agreements.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

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: 'Files a concierge switch request with the complete contract data in one call.' It clearly distinguishes itself from sibling start-booking by stating that book-contract is for autonomous agents, while start-booking opens a form for a person.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly states when to use this tool (autonomous agent already holds full profile, IBAN, standing authorization) and contrasts it with start-booking for conversation-driven data entry. It also names a non-option: 'There is no self-service checkout link.'

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

compare-broadbandFind US Internet Providers at an Address

Read-onlyIdempotent

Inspect

For questions like “what internet providers are at my address?”, “is fiber available?”, “fast home internet near me?”, “Starlink vs cable?”, or “moving to an address, what internet can I get?”, look up US fixed broadband provider availability and speed by address or coordinates. Returns FCC availability and maximum advertised speeds by census block (not building-level), ranked by low latency, then speed. Address is sent to the US Census Bureau Geocoder to identify the census block; starting prices ("from $X/mo", with conditions, source and check date) only for major national providers. Filter by minimum download speed or technology.

ParametersJSON Schema

Name	Required	Description
`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.
`technology`	No	Only these technologies.
`minDownloadMbps`	No	Only providers advertising at least this download speed.

compare-esimsCompare Travel eSIMs

Read-onlyIdempotent

Inspect

Use this when the user wants a travel eSIM, compares eSIM data plans for a trip abroad, or asks for the cheapest eSIM for a country. Ranks a curated catalog of country eSIM packages (Airalo, Saily, Ubigi, Holafly, Nomad) by USD list price among packages valid for the whole trip with at least the data needed, listing each provider's cheapest package first and then the remaining packages by price, and shows price per GB and per day with a provider link. Destinations: AU, BR, CA, CO, DE, ES, FR, GB, GR, IT, JP, KR, MX, NL, PT, TH, TR, US. Inputs: destination (country code), days, optional data_gb, unlimited and providers. No personal data is used. Keywords: travel eSIM, eSIM for Japan, cheapest eSIM, international data plan, roaming.

ParametersJSON Schema

Name	Required	Description
`days`	Yes	Trip length in days; packages must be valid at least this long.
`data_gb`	No	Minimum data needed in GB (default 1). Ignored when unlimited is true.
`providers`	No	Only these providers, e.g. ["Airalo", "Saily"].
`unlimited`	No	true: only unlimited-data packages; false: exclude them; omitted: unlimited packages also qualify.
`destination`	Yes	Destination country, ISO 3166-1 alpha-2 (e.g. JP, US, GB). Supported: AU, BR, CA, CO, DE, ES, FR, GB, GR, IT, JP, KR, MX, NL, PT, TH, TR, US.

Output Schema

ParametersJSON Schema

Name	Required	Description
`days`	Yes
`basis`	Yes
`closest`	No	When nothing qualifies: the largest package that lasts the trip.
`message`	No
`results`	Yes
`excluded`	Yes
`disclosure`	Yes
`destination`	Yes
`catalogVerifiedOldest`	No

compare-mobile-plansCompare US Mobile Phone Plans

Read-onlyIdempotent

Inspect

Compares and ranks US mobile phone plans, cheapest first, from a curated catalog of carrier and prepaid (MVNO) plans, each price checked on the provider's own page, by 12-month average cost per line, with any promo price shown alongside. The catalog is a selection, not the whole market; each result states how many plans and providers it covers and the oldest price-check date. Inputs: number of lines, and optionally data need, budget per line, prepaid or postpaid, must-have features and preferred network. No address or location is used, so network coverage is not checked; each result carries a coverage note. Keywords: cheapest phone plan, compare cell phone plans, cell phone plan, mobile plan comparison, switch carriers, unlimited data plan, family plan, prepaid vs postpaid.

ParametersJSON Schema

Name	Required	Description
`lines`	No	Number of phone lines to price.
`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.

Output Schema

ParametersJSON Schema

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

compare-tariffsCompare German Energy TariffsA

Read-onlyIdempotent

Inspect

Compares German electricity and gas tariffs with live market data for a postal code and an annual consumption, and returns one page of the ranked market: prices with and without bonus, monthly average, savings against the local default supplier (Grundversorgung) or the user's current contract, contract terms, price guarantee, eco status and customer ratings. Covers tariff comparison only, not general energy questions. Prices come live from the market data and can change at any time. Keywords: Stromvergleich, Gasvergleich, Stromtarif, Gastarif, Stromanbieter wechseln, Gasanbieter wechseln, Ökostrom, Strompreise, Energiekosten senken, electricity tariff, gas tariff, switch energy provider, Germany. Inputs: postalCode (5 digits) and annualConsumptionKwh. Both come from the user: the ranking is only valid for the household's actual consumption, which is printed on the last bill, and the tool has no default for it. The typical values by household size in the parameter description help a user who does not know the figure; a comparison run on a household size alone is approximate. energyType selects gas; electricity is the default. Without filters the result covers the whole market. An energy bill contains every input: postal code, annual consumption, and the reference for the savings comparison, which is the future monthly payment (Abschlag) if the bill states one, otherwise the Arbeitspreis and Grundpreis lines (see the current* parameters). The bill total belongs to the past period and may include a one-time bonus, so it is not a reference. The bill's provider, customer number and meter number are the fields the booking form asks for later. Each offer carries its complete data (prices, bonuses, contract terms, flags such as dynamic or eco, ratings, remarks); tariff-details adds the cost breakdown, energy mix and provider details. Only offers with an eco object are eco tariffs. Their eco.statement and eco.proof are legally required wording (EU EmpCo, Directive 2024/825): quote both verbatim when describing a green tariff. Offers without eco are not green, eco, renewable or climate-neutral. The ranking method, bonus handling, price guarantees and eco labels are explained at https://commerceforagents.com/comparison-basis. The response states totalResults and how to reach the rest of the ranking (page, providers, filters). Dynamic (spot-price) tariffs are included only with includeDynamicTariffs. The result renders as tariff cards with filters (eco, contract length, price guarantee, bonus handling, providers) below the message, so the list does not need repeating in text. Each offer has a ref: tariff-details shows its full conditions, and start-booking opens the booking form in which the user enters the contract data, IBAN and consent. language sets the language of the cards and their buttons.

ParametersJSON Schema

Name	Required	Description
`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".
`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"]). Restricts the ranking to these providers.
`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	The household's actual annual consumption in kWh, from the user or their last bill; no default. The ranking depends on it. Typical values by household size: 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. Not 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, since most German households book fixed-price 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 €'. 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.

Output Schema

ParametersJSON Schema

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

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/openWorld, and the description adds real behavioral context on top: prices are live and can change at any time, the ranking is only valid for the household's actual consumption which has no default, bonuses are counted via bonusMode, dynamic tariffs are forecast-only and excluded by default, and the result renders as interactive tariff cards with filters rather than needing textual repetition. It also warns that only offers with an `eco` object are green and that eco.statement/proof must be quoted verbatim.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and scope are front-loaded in the first sentence, and most sentences carry actionable detail. It is nonetheless a long wall of prose for a single description, with some restatement (eco rules, bill-reference logic) and a keyword list that reads as retrieval padding rather than tool guidance, so it falls short of a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values need not be described, yet the description still covers the pieces an agent needs: required vs. optional inputs, filter defaults, paging via totalResults, and the booking follow-up fields (provider, customer number, meter number). For a 27-parameter, open-world comparison tool this is complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% so the baseline is 3, but the description adds cross-parameter meaning the schema cannot: it identifies which values must come from the user, explains that annualConsumptionKwh has no default and drives the ranking, and lays out the precedence of currentMonthlyPaymentEur over the Arbeitspreis/Grundpreis components for the savings baseline. It reinforces rather than repeats the schema's per-field docs.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb+resource+scope: 'Compares German electricity and gas tariffs with live market data for a postal code and an annual consumption, and returns one page of the ranked market,' then enumerates exactly what comes back (prices with/without bonus, savings vs Grundversorgung, contract terms, eco, ratings). It explicitly distinguishes itself from siblings by naming tariff-details (cost breakdown, energy mix) and start-booking (booking form), so an agent can route without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit exclusion ('Covers tariff comparison only, not general energy questions'), names the alternatives and their conditions (tariff-details for breakdown/provider details, start-booking for the contract data/IBAN/consent step), and states that dynamic tariffs appear only with includeDynamicTariffs. It also specifies when the current* savings-reference parameters apply versus ignoring the bill total.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

compare-vpnCompare VPN Plans

Read-onlyIdempotent

Inspect

Use this when the user wants to compare VPN subscriptions, find the cheapest VPN, or choose a VPN for streaming or torrenting. Ranks a curated catalog of US-priced (USD) VPN plans (NordVPN, Surfshark, ExpressVPN, Proton VPN, Private Internet Access, CyberGhost), cheapest first, by effective monthly cost over the preferred term including renewals, and shows the upfront price, renewal price, devices, money-back days, audited no-logs (with auditor), jurisdiction and RAM-only servers; privacy facts not confirmed on the provider's own pages are marked unconfirmed. Prices are US/USD prices; local checkout prices may differ. The catalog is a selection, not the whole market; each result states the oldest price-check date. Inputs, all optional: term_months (1, 12, 24 or 36), min_devices, needs (streaming, p2p; plans where the feature is unconfirmed are excluded), country (only adds a note when not US) and checkout (default false: pricing-page links; true: plan-preselected checkout links). No personal data is used. Keywords: best VPN, cheapest VPN, VPN comparison, VPN deals, VPN for streaming, VPN for torrenting.

ParametersJSON Schema

Name	Required	Description
`needs`	No	Required features: streaming, p2p (torrenting).
`country`	No	Two-letter country code. Prices are always US prices in USD; for a country other than US the result says local checkout prices may differ.
`checkout`	No	Default false: return pricing-page links. Set true to return plan-preselected provider checkout links instead.
`min_devices`	No	Minimum simultaneous devices needed.
`term_months`	No	Preferred subscription length in months: 1, 12, 24 or 36.

Output Schema

ParametersJSON Schema

Name	Required	Description
`plans`	Yes
`source`	Yes
`message`	No
`priceNote`	Yes
`disclosure`	Yes
`currencyNote`	Yes
`selectionNote`	Yes	How many plans are shown, from how many providers, out of the curated catalog.
`missingTermNote`	No	Providers with no plan for the requested term.
`unconfirmedNote`	No	Providers left out of a needs filter because the feature is unconfirmed, not because it is missing.
`oldestVerifiedDate`	No

start-bookingOpen Booking FormA

Read-onlyIdempotent

Inspect

Opens the booking form for one offer from a comparison, identified by its ref; the form renders below the message. Read-only: the call submits, stores and sends nothing, and takes no personal data. In the form the user enters the contract details (page 1), then the IBAN and consent (page 2), and files the request there. Messages such as 'Bitte öffne das Buchungsformular', 'ich möchte diesen Tarif', 'den nehme ich', 'book #2' or 'switch me to this', usually sent by the card's 'Jetzt buchen' button, ask for this form. language sets the language of the form. There is no self-service checkout link. Keywords: Buchungsformular, Tarif buchen, wechseln, Wechsel beauftragen, Vertrag abschließen, open booking form, book, switch, sign up.

ParametersJSON Schema

Name	Required	Description	Default
`ref`	Yes	Offer reference from a compare-tariffs result (field `ref`). No personal data.
`language`	No	Language of the conversation; the booking form uses it. Default: de.

Output Schema

ParametersJSON Schema

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

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint and idempotentHint, and the description reinforces this by stating it 'submits, stores and sends nothing, and takes no personal data'. It adds useful behavior beyond annotations: the form renders below the message, has a two-page flow, and there is no self-service checkout link.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the main action and read-only behavior, and the trigger examples are useful. The trailing keyword list is somewhat redundant, but overall each sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the rich annotations, full schema coverage, and presence of an output schema, the description covers the tool's purpose, side-effect profile, trigger phrases, form flow, language behavior, and absence of a checkout link. Nothing critical is missing for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 both ref and language. The description adds only light reinforcement, noting ref identifies the offer and language controls the form language, but it does not materially extend the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

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 'opens the booking form for one offer from a comparison, identified by its ref'. It also clarifies the tool is read-only and that the form renders below the message, 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.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives strong when-to-use signals: example user messages ('book #2', 'switch me to this'), the card's 'Jetzt buchen' button, and the note that there is no self-service checkout link. It does not explicitly list alternative tools and when not to use them, but the usage context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

submit-switch-requestSubmit Energy Switch RequestA

DestructiveIdempotent

Inspect

Files a concierge switch request for an offer from a comparison: contract data, IBAN and the consents in one call. The booking form opened by start-booking calls it; autonomous MCP clients that hold the user's complete data and authorization can call it directly. Stores the request encrypted, sends the confirmation emails and returns only masked data. An operator later submits the contract application to the provider.

ParametersJSON Schema

Name	Required	Description
`ref`	Yes	Offer reference from a compare-tariffs result (field `ref`).
`iban`	Yes	IBAN as entered in the form; spaces allowed.
`email`	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).
`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).

Output Schema

ParametersJSON Schema

Name	Required	Description
`status`	Yes
`tariff`	Yes
`provider`	Yes
`nextSteps`	Yes
`requestId`	Yes
`maskedIban`	Yes
`annualTotalEur`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

Annotations declare readOnlyHint=false, destructiveHint=true, idempotentHint=true, openWorldHint=true. The description adds value by stating it 'stores the request encrypted, sends the confirmation emails and returns only masked data', and that an operator later submits the contract application. This discloses side effects (email sending) and storage behavior beyond what annotations convey. No contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences with no fluff. The first sentence states the purpose and scope, the second gives usage context, and the third describes behavior and downstream action. Front-loaded with the core function, every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 20 parameters, nested objects, and an output schema, the description covers the essential aspects: purpose, usage scenario, side effects, and the follow-up operator action. It does not detail the output schema (which exists) or error cases, but that's acceptable. It could mention that switchType includes relocation, but the schema covers that. Overall complete enough for an agent to call correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so every parameter already has a description. The description only summarizes the parameter groups ('contract data, IBAN and the consents in one call') which adds minimal extra meaning. Baseline 3 is appropriate; the schema carries the semantic load.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool 'files a concierge switch request for an offer from a comparison' – a specific verb (files) and resource (switch request) with context. It distinguishes itself from siblings by mentioning the relationship with start-booking and the direct-call option for autonomous clients, so an agent can tell it apart.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use it: either via the booking form opened by start-booking, or directly by autonomous clients that hold complete data and authorization. This implies the requirement for authorization but doesn't explicitly list alternatives or exclusions (e.g., 'do not call without an offer ref'). It also notes the operator later submits the contract application, giving flow context. Clear enough but not exhaustive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

tariff-detailsEnergy Tariff Details

Read-onlyIdempotent

Inspect

Returns the full conditions of one tariff from a compare-tariffs result, identified by its ref: price composition, scope of the price guarantee, contract duration, renewal and cancellation terms, deposit, energy-source mix, customer ratings, and for eco tariffs the required eco statement and proof. Texts come in the requested language. Keywords: Tarifdetails, Vertragsbedingungen, Preisgarantie, Kündigungsfrist, Vertragslaufzeit, AGB, tariff conditions, contract details.

ParametersJSON Schema

Name	Required	Description	Default
`ref`	Yes	Offer reference from a compare-tariffs result (field `ref`).
`language`	No	Language of the conversation (for the eco statement and proof texts). Default: the language of the compare-tariffs result the ref comes from.

Output Schema

ParametersJSON Schema

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

1 tool updateOct 15, 2026

Changedcompare-esims1 field changed

changedInput schema / properties / destination / description

Previous value: -"Destination country, ISO 3166-1 alpha-2 (e.g. JP, US, GB, FR, IT, ES, TH, MX)."New value: +"Destination country, ISO 3166-1 alpha-2 (e.g. JP, US, GB). Supported: AU, BR, CA, CO, DE, ES, FR, GB, GR, IT, JP, KR, MX, NL, PT, TH, TR, US."

3 tool updatesOct 15, 2026
- Changedcompare-esims2 fields changed
  - addedOutput schema / properties / closest / properties / offerTargetUrl
```
Added value: +{
+  "description": "Where offerUrl redirects to.",
+  "type": "string"
+}
```
  - addedOutput schema / properties / results / items / properties / offerTargetUrl
```
Added value: +{
+  "description": "Where offerUrl redirects to.",
+  "type": "string"
+}
```
- Changedcompare-mobile-plans1 field changed
  - addedOutput schema / properties / plans / items / properties / offerTargetUrl
```
Added value: +{
+  "description": "Where offerUrl redirects to.",
+  "type": "string"
+}
```
- Changedcompare-vpn1 field changed
  - addedOutput schema / properties / plans / items / properties / offerTargetUrl
```
Added value: +{
+  "description": "Where offerUrl redirects to.",
+  "type": "string"
+}
```

1 tool updateOct 13, 2026

Changedtariff-details1 field changed

changedInput schema / properties / language / description

Previous value: -"Language of the conversation (for the eco statement and proof texts). Default: de."New value: +"Language of the conversation (for the eco statement and proof texts). Default: the language of the compare-tariffs result the ref comes from."

1 tool updateOct 3, 2026
- Addedcompare-vpn
1 tool updateOct 2, 2026
- Addedcompare-esims

3 tool updatesSep 26, 2026

Changedbook-contract1 field changed

changedInput schema / properties / consent / description

Previous value: -"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."New value: +"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. True only after that agreement."

Changedcompare-tariffs12 fields changed

changedInput schema / properties / annualConsumptionKwh / description

Previous value: -"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)."New value: +"The household's actual annual consumption in kWh, from the user or their last bill; no default. The ranking depends on it. Typical values by household size: electricity ~1500 (1 person), 2500 (2), 3500 (3), 4500 (4+); gas ~9000 (flat), ~20000 (house)."

changedInput schema / properties / currentAnnualCostEur / description

Previous value: -"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."New value: +"The user's ONGOING yearly cost on their current contract in EUR: current prices, one-time bonuses EXCLUDED. Not 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."

changedInput schema / properties / currentMonthlyPaymentEur / description

Previous value: -"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."New value: +"The FUTURE monthly payment (Abschlag) stated on the bill for the coming period, e.g. 'Ihr monatlicher Zahlbetrag beträgt zukünftig 159,00 €'. It already reflects price changes after the billing period, which the bill's Arbeitspreis/Grundpreis lines predate. Takes precedence over the price components."

changedInput schema / properties / includeDynamicTariffs / description

Previous value: -"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."New value: +"Include dynamic (spot-price) tariffs whose first-year price is only a forecast. Default: false, since most German households book fixed-price tariffs."

changedInput schema / properties / providers / description

Previous value: -"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."New value: +"Only offers from these providers (names, e.g. [\"Vattenfall\", \"E WIE EINFACH\"]). Restricts the ranking to these providers."

changedOutput schema / properties / query / properties / annualConsumptionKwh / description

Previous value: -"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)."New value: +"The household's actual annual consumption in kWh, from the user or their last bill; no default. The ranking depends on it. Typical values by household size: electricity ~1500 (1 person), 2500 (2), 3500 (3), 4500 (4+); gas ~9000 (flat), ~20000 (house)."

changedOutput schema / properties / query / properties / currentAnnualCostEur / description

Previous value: -"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."New value: +"The user's ONGOING yearly cost on their current contract in EUR: current prices, one-time bonuses EXCLUDED. Not 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."

changedOutput schema / properties / query / properties / currentMonthlyPaymentEur / description

Previous value: -"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."New value: +"The FUTURE monthly payment (Abschlag) stated on the bill for the coming period, e.g. 'Ihr monatlicher Zahlbetrag beträgt zukünftig 159,00 €'. It already reflects price changes after the billing period, which the bill's Arbeitspreis/Grundpreis lines predate. Takes precedence over the price components."

changedOutput schema / properties / query / properties / includeDynamicTariffs / description

Previous value: -"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."New value: +"Include dynamic (spot-price) tariffs whose first-year price is only a forecast. Default: false, since most German households book fixed-price tariffs."

changedOutput schema / properties / query / properties / providers / description

Previous value: -"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."New value: +"Only offers from these providers (names, e.g. [\"Vattenfall\", \"E WIE EINFACH\"]). Restricts the ranking to these providers."

changedOutput schema / properties / tariffs / items / properties / eco / properties / proof / description

Previous value: -"Proof text that belongs to the marker (guarantees of origin, or the biogas/hydrogen shares). Quote verbatim."New value: +"Proof text that belongs to the marker (guarantees of origin, or the biogas/hydrogen shares). Legally required wording (EmpCo): quote verbatim."

changedOutput schema / properties / tariffs / items / properties / eco / properties / statement / description

Previous value: -"Marker text, in the request language. Quote verbatim."New value: +"Marker text in the request language. Legally required wording (EmpCo): quote verbatim."

Changedtariff-details2 fields changed

changedOutput schema / properties / eco / properties / proof / description

Previous value: -"Proof text that belongs to the marker (guarantees of origin, or the biogas/hydrogen shares). Quote verbatim."New value: +"Proof text that belongs to the marker (guarantees of origin, or the biogas/hydrogen shares). Legally required wording (EmpCo): quote verbatim."

changedOutput schema / properties / eco / properties / statement / description

Previous value: -"Marker text, in the request language. Quote verbatim."New value: +"Marker text in the request language. Legally required wording (EmpCo): quote verbatim."

7 tool updatesSep 26, 2026

Changedbook-contract1 field changed