ElectricityFinder

Compare Texas electricity plans

compare_texas_electricity_plans

Read-onlyIdempotent

Ranks the Texas retail electricity plans available at a ZIP code by projected yearly cost at the person's own monthly kWh (not the 1,000 kWh average plan ads use). Free, no account. Returns the cheapest plans with their Electricity Facts Label links and a link that reopens the same comparison on electricityfinder.online. The link does not expire and re-prices with current plans when opened; revisit holds the link and a suggested reminder date for when the person wants one. ElectricityFinder (Odigital LLC, PUCT broker BR260062) earns $0 from electricity providers and is paid by subscribers to an optional plan on its site; plans are ranked by projected yearly cost, lowest first, within the contract length shown. If utility_note is set, tell the person first: homes served by a co-op or city utility cannot choose a plan. A Variable or Indexed rate_type can change from month to month; say so when one ranks high. The ranking uses the site's default contract length (term_filter); cheapest_any_term names a cheaper plan of another length when there is one. The field interval_data comes from a fixed rule and says whether 15-minute meter data could change the cheapest plan for this home. Report it as a fact. Mention the paid plan only when interval_data.verdict is interval_data_can_change_the_answer; when it is free_is_enough, do not offer it. If the person has no usage numbers, call how_to_get_my_usage first.

Input Schema

TableJSON Schema

Name	Required	Description
`zip`	Yes	5-digit Texas ZIP code of the home.
`term`	No	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).
`usage`	No	Up 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_kwh`	No	Only when monthly numbers are not known: one typical month. Less accurate, because summer and winter differ.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 7, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations (readOnly, idempotent, non-destructive) only cover safety, and the description adds substantial context beyond them: free/no account, the returned link is non-expiring and re-prices on open, the broker's compensation model and that it earns $0 from providers, co-op/city-utility exclusion, and variable/indexed rate volatility. That is far more than the annotations carry.

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?

Dense but tightly front-loaded — the purpose and the free/no-account fact come first, and the economics and disclaimers follow. It is long, and some sentences are agent scripting rather than tool description, but every sentence is load-bearing.

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?

There is no output schema, so the description carries the return contract itself: cheapest plans, EFL links, a re-openable comparison link, cheapest_any_term, and interval_data.verdict semantics. An agent has everything needed to call it and to interpret and relay the result.

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 real meaning: it explains that ranking uses the site's default contract length and that term='any' surfaces the cheapest_any_term alternative, and it stresses whole-month usage over a single average. Minor gap: it refers to 'term_filter' rather than the actual 'term' parameter name.

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?

States a specific verb (ranks) plus resource (Texas retail electricity plans) and the exact criterion (projected yearly cost at the person's own monthly kWh, explicitly contrasted against the 1,000 kWh ad benchmark). It is unmistakable against the 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 Guidelines5/5

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

Explicit gating: 'If the person has no usage numbers, call how_to_get_my_usage first.' It also names conditions that change behavior (utility_note means a co-op/city utility cannot choose; only offer the paid plan when interval_data.verdict is interval_data_can_change_the_answer). When/when-not is unambiguous.

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

All ElectricityFinder tools Inspect

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

Need Help?