Skip to main content
Glama

ElectricityFinder

by io.github.konradish
OverviewDiscussionsAdmin

Compare Texas electricity plans

compare_texas_electricity_plans
Read-onlyIdempotent

This tool ranks the Texas electricity plans at a ZIP code by what each would cost over a year at the person's own monthly kWh (not the 1,000 kWh figure plan ads quote). Free, no account. No electricity company pays ElectricityFinder (Odigital LLC, PUCT broker BR260062); it is paid only by subscribers to an optional plan on its site. Order: lowest projected yearly cost first, within the contract length in term_filter (default: usually 12 months; term_filter says which length was used and why); plans whose price depends on conditions (bill credits, time-of-use, usage tiers) come after plans without them. Each plan comes with its projected yearly cost at that usage and its Electricity Facts Label (efl_url), the Texas-required label of the plan's rates, fees and terms. price_conditions is null when ElectricityFinder found no condition on a plan's price, and otherwise holds the kind and a note written to be repeated as is; a null does not rule out conditions, and the EFL is the authority. link reopens the same comparison on electricityfinder.online, re-priced with that day's plans; it does not expire. revisit holds the link and a suggested reminder date. cheapest_any_term names a cheaper plan of another contract length when there is one. utility_note is set when a co-op or city utility serves the ZIP; homes it serves cannot choose a retail plan. A Variable or Indexed rate_type means the price can change from month to month. interval_data comes from a fixed rule and says whether 15-minute meter data could change the cheapest plan for this home. interval_data.paid_plan, present only when the verdict is interval_data_can_change_the_answer, describes the optional paid plan that prices on 15-minute data. how_to_get_my_usage explains how to get the monthly kWh numbers this tool takes.

Input Schema

NameRequiredDescriptionDefault
zipYes5-digit Texas ZIP code of the home.
termNoContract length to rank. default (the site's own default: usually 12 months; 24 when 24-month plans are the most common), 12, 24, or any (includes month-to-month plans).
usageNoUp to 12 months of usage. Best: the last 12 months. Totals of a Smart Meter Texas 15-minute file, by month, are fine.
average_monthly_kwhNoOnly when monthly numbers are not known: one typical month. Less accurate, because summer and winter differ.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / term / description
      Previous value: -"Contract length to rank. default (the site's own default: the most common term, usually 12 months), 12, 24, or any (includes month-to-month plans)."New value: +"Contract length to rank. default (the site's own default: usually 12 months; 24 when 24-month plans are the most common), 12, 24, or any (includes month-to-month plans)."
  2. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description goes well beyond them: exact ranking order, the tie-break rule for conditional-price plans, that links never expire, funding disclosure (PUCT BR260062), and the caveat that a null price_conditions does not rule out conditions. It also flags the paid-plan upsell surfaced inside interval_data, which an agent needs to know before relaying results.

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 lead sentence front-loads the function, and with no output schema every return-field gloss earns its place. It is still a single dense run-on paragraph with semicolon-chained clauses, which hurts scannability for a description this long.

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 no output schema and a rich structured return, the description carries the full burden and does so: it defines price_conditions, efl_url, link, revisit, cheapest_any_term, utility_note, rate_type, and interval_data. Nothing an agent needs to interpret or relay a result is left unexplained.

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% and each parameter is already documented, so the baseline applies. The description adds the rationale for usage-over-average ('not the 1,000 kWh figure plan ads quote'), but it refers to 'term_filter' when the actual parameter is named 'term', which could send an agent looking for a field that does not exist.

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 and resource: 'ranks the Texas electricity plans at a ZIP code', and immediately scopes the metric ('by what each would cost over a year at the person's own monthly kWh'). This is unmistakably distinct from the only siblings, how_to_get_my_usage and send_feedback.

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?

Establishes the entry conditions (a Texas ZIP, actual monthly kWh), removes friction ('Free, no account'), and explicitly routes usage-data questions to the how_to_get_my_usage sibling. It does not state a when-not-to-use case, but with only two unrelated siblings there is little to exclude.

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

All ElectricityFinder toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources