Skip to main content
Glama

Household electricity and gas by yearly cost

compare_energy
Read-onlyIdempotent

An indicative calculation, not yet checked by an independent expert (verified: false): present the result as an estimate, never as a guaranteed price; show estimate_note (the sentence with the day of the data, in locale cs | sk | en) with every result. Household electricity and gas offers (Czechia for now) ranked by the yearly bill for a stated consumption in one distributor's area, with VAT. The bill is split into the regulated part (distribution, system services, renewables support, market operator, tax: set by the energy regulator for the distributor, the same with every supplier) and the supplier part (commodity price and monthly fee: what switching changes). Every offer has the supplier's official price list (source_url, verified_on, valid_from) and says whether the price is fixed (fixed_months or fixed_until) or variable. Spot and formula prices are never ranked; they are listed in not_ranked. Offers whose price list was read only for another distributor's area are left out. Electricity: distributor (cez-distribuce | egd | pre-distribuce), rate (D01d, D02d, D25d, D26d, D27d, D35d, D45d, D56d, D57d, D61d), mwh = yearly high-tariff (or all) consumption, nt_mwh = low-tariff consumption; breaker = main breaker (1x25, 3x10, 3x16, 3x20, 3x25 default, 3x32, 3x40, 3x50, 3x63; it sets the fixed monthly distribution price from the regulator's table); postcode (5 digits) instead of distributor picks the distributor area as an estimate (area.estimate = true; two candidates when the postcode spans an area boundary: then pass distributor). Every result is an estimate (result_type: estimate, guaranteed: false): the binding bill depends on the actual consumption, the distributor stated on the bill and the contract. Gas: distributor (gasnet | gas-distribution | ppd), mwh = yearly consumption up to 63 MWh; postcode instead of distributor picks the gas area the same way (estimate; two candidates around Prague or on an area boundary: then pass distributor). Call without a distributor to get the distributors, rates (rate_info: low-tariff hours a day), products and the regulated price tables. COMPARISON TEMPLATE (20 Oct 2026): every ranked offer carries the forDeal score 0–10 (score, score_parts price / conditions / rating, score_weights as used, score_missing when a part is absent), labels (cheapest = lowest total of the list; best_value = highest score), a one-sentence reason, conditions (fixation months and bucket, term indefinite | fixed_term, notice_months, termination_fee none | stated, green; null = the price list does not state it) and the supplier's public rating (source, score, scale, count, source_url, fetched_on; counted only from 10 reviews; null = we have none, and the weights are renormalised, the answer says so). Filters: fixation none | 12 | 24 | 36 (variable price, or fixed up to 1 / 2 / 3+ years), pricing fixed | variable | spot (spot = market-price products, listed without a total), green true, no_penalty true (no fee for leaving stated); filter_counts says how many offers each chip would leave. sort score (default) | price. compare = up to 3 offer ids: the answer adds comparison with the same parameters side by side. Method and weights: scoring. Freshness: every offer's verified_on is the day a person read its price list; price_lists_change_check_on is the day of the last weekly automatic check of the lists, price_lists_checked gives that day per supplier, price_lists_last_checked_on is the later of that day and the newest verified_on (the date the website shows as "price lists checked"), and price_lists_flagged names offers whose list changed or vanished since (say their price may be out of date). What the household pays today, best first: current_offer (an id from products), or its own prices current_vt_price + current_nt_price + current_fee_month (current_prices_vat), or current_monthly (the advance); each offer then carries saving_year against it and the answer states saving_basis (offer | own_prices | advance) and warnings (e.g. nt_mwh_missing for a two-tariff rate without low-tariff consumption).

Input Schema

NameRequiredDescriptionDefault
mwhNoYearly consumption in MWh (electricity: high tariff or all; default 2.5 electricity, 10 gas).
rateNoElectricity distribution rate, e.g. D02d (default) or D25d (two tariffs).
sortNoscore (default: forDeal score, highest first) | price (yearly total, lowest first).
greenNoFilter, true: only products whose price list states electricity of renewable origin (none stated yet).
limitNo
localeNoLanguage of estimate_note: cs | sk | en (default en).
nt_mwhNoElectricity low-tariff consumption a year in MWh (two-tariff rates only).
breakerNoElectricity main breaker: 1x25 | 3x10 | 3x16 | 3x20 | 3x25 (default) | 3x32 | 3x40 | 3x50 | 3x63.
compareNoComma-separated offer ids (2–3) for a side-by-side comparison in `comparison`.
countryNoCZ (default).
pricingNoFilter: fixed | variable (price-list products, ranked) | spot (market-price products: listed in not_ranked without a total, never ranked).
fixationNoFilter, one of none | 12 | 24 | 36: none = variable price without fixation; 12 / 24 / 36 = fixed price up to 1 / 2 / 3 or more years.
postcodeNoPostcode of the supply point (e.g. 602 00), electricity or gas; picks the distributor when none is given. An estimate from the post's postcode list and the distributors' coverage by district.
commodityNoelectricity (default) | gas
householdNoHousehold type (energy v3) instead of rate + consumption: electricity byt | chata | bojler | akumulace | elektromobil | tepelne-cerpadlo | elektricke-topeni; gas plyn-vareni | plyn-voda | plyn-byt | plyn-dum. Sets the rate, a typical yearly consumption and its low-tariff share (stated assumptions, see `households`); mwh overrides the total, rate and nt_mwh override the rest. With current_monthly and no mwh, the consumption is estimated from the payment (consumption_basis: from_monthly).
no_penaltyNoFilter, true: only products whose terms state no fee for leaving (an indefinite term).
distributorNoDistributor of the place: electricity cez-distribuce | egd | pre-distribuce; gas gasnet | gas-distribution | ppd.
current_offerNoId of the household's current product from `products` (energy v2): today's yearly total is then priced from that price list for the same need, and saving_year compares like with like (saving_basis: offer). Takes precedence over current_vt_price and current_monthly.
current_monthlyNoWhat the household pays today a month with VAT (the current advance), in the country's currency. Each offer then carries saving_year = current_monthly × 12 − total_year (positive = cheaper than today; an estimate).
current_nt_priceNoToday's low-tariff commodity price per MWh (two-tariff electricity rates; required when nt_mwh > 0).
current_vt_priceNoToday's commodity price per MWh from the household's bill or price list (electricity: high tariff or all; gas: the gas price). With current_fee_month it gives today's yearly total (saving_basis: own_prices); takes precedence over current_monthly.
current_fee_monthNoToday's monthly fee of the supplier (stálá platba).
current_prices_vatNoWhether current_*_price and current_fee_month include VAT: excluded (default, as price lists state them) | included (as a bill often shows them).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the readOnly annotation, it discloses that results are unverified estimates, that estimate_note must be shown, that spot and formula prices are never ranked, that offers from another distributor area are excluded, and how freshness dates and flagged price-list changes work. This is unusually rich disclosure of behavior the agent would otherwise not know.

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

Conciseness2/5

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

The description is front-loaded with the critical estimate disclaimer, but it is one enormous paragraph full of nested parentheses and run-on clauses. Every fact may be relevant for a complex 23-parameter tool, but the lack of structure makes it hard to scan and borders on over-specification rather than concise guidance.

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 complex 23-parameter tool with no output schema, the description covers the ranking method, filters, comparison output, current-spend baselines, saving_basis, warnings and freshness metadata. An agent has enough information to invoke it correctly across the main scenarios.

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 very high, so the baseline is 3, but the description adds substantive meaning: the bill split between regulated and supplier parts, how breaker sets the distribution price, how postcode estimates the distributor area, how household overrides mwh and rate, and the precedence among current_* inputs. It is not fully redundant with the schema, though some parameter detail is duplicated.

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: an indicative calculated comparison of household electricity and gas offers ranked by yearly bill for a stated consumption. It scopes the market to Czechia and makes clear that results are estimates, so an agent can distinguish it from a generic supplier list or bill-specific tool.

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?

It gives clear usage scenarios: call without a distributor to retrieve distributors, rates and regulated price tables; use postcode when no distributor is known; use current_offer, current_vt_price or current_monthly depending on what the household has. It does not explicitly compare itself with siblings such as compare_energy_from_bill, so the alternative-selection guidance is strong but not complete.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources