FindEnergyRates Electricity Rates

by com.findenergyrates

Overview Discussions Admin

Server Details

Live US retail electricity plans, utility price-to-compare rates, ZIP-to-utility lookup. Read-only.

Ownership verified

Status: Healthy
Uptime: 99.5% over 42 days
Last Tested: 2026-10-22 23:11
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.7/5.0

Scored 2026-10-20 04:50 across 7 tools

Disambiguation5/5

Each tool targets a distinct job (lookup utility, list utilities, search plans, compare a current rate, estimate annual cost, get default rate, service info), and descriptions explicitly cross-reference 'do not use X, use Y'. The three plan-listing tools (search_plans, compare_my_plan, estimate_annual_cost) are the closest overlap, but their input requirements and use cases are spelled out clearly.

Naming Consistency5/5

All tools use a uniform snake_case 'electricity_' prefix followed by a verb_noun pattern (find_utility_by_zip, get_price_to_compare, list_utilities, search_plans, compare_my_plan, estimate_annual_cost). Only 'about' deviates slightly but remains readable and consistent with the namespace.

Tool Count5/5

Seven tools is well-scoped for a read-only electricity rate lookup service, with each tool earning its place and no redundant entries.

Completeness4/5

The surface covers the core lifecycle: locate utility, list utilities, search plans, compare a current rate, estimate annual cost, and get the default rate, with enrollment explicitly out of scope. Minor gaps exist (e.g., no single-plan-by-id detail endpoint, only plan_url), but agents can work around these.

Available Tools

7 tools

electricity_aboutA

Read-onlyIdempotent

Inspect

Use this when someone asks what FindEnergyRates is, where its electricity data comes from, which states it covers, how plans are ranked, how fresh the data is, whether FindEnergyRates is paid, or how to cite it. Returns that, with the referral and broker disclosure and links to the privacy policy and terms. Takes no input. Do not use it for plans or rates (use electricity_search_plans or electricity_get_price_to_compare).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, openWorld=false, so the safety profile is covered. The description adds concrete behavioral content beyond that: it takes no input and returns referral/broker disclosure plus privacy policy and terms links. It stops short of full disclosure (e.g., no caching/auth notes), hence a 4 rather than 5.

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?

Front-loaded usage trigger, then return contents, then a zero-argument note, then the exclusion. Every clause adds routing value (the question list is what makes the trigger operational) with no filler.

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?

No output schema exists, so the description must describe returns itself — and it does: referral/broker disclosure and privacy/terms links. For a no-input informational tool, the description plus annotations leave nothing an agent needs 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?

Zero parameters, so per the rubric the baseline is 4. The description correctly states 'Takes no input,' confirming the empty schema is intentional rather than an omission.

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?

Names a specific resource (FindEnergyRates) and enumerates exactly what the tool answers: data origin, state coverage, ranking method, data freshness, pricing model, and citation. It also explicitly contrasts itself against electricity_search_plans and electricity_get_price_to_compare, so an agent can route correctly without opening the 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 explicit when-to-use triggers (the enumerated question types) and an explicit exclusion with named alternatives: 'Do not use it for plans or rates (use electricity_search_plans or electricity_get_price_to_compare).' Nothing is left to inference.

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

electricity_compare_my_plan

Read-onlyIdempotent

Inspect

Use this when someone gives the rate they pay now and asks whether they could pay less, or how much they would save by switching. Returns how many current plans for their utility are cheaper at their monthly usage, the cheapest of them with estimated monthly and yearly savings, and the utility's price to compare where one exists. In Texas current_rate_cents is the all-in average price per kWh (total bill divided by kWh, delivery included); elsewhere it is the supply (generation) rate per kWh. Savings are estimates at a flat monthly usage, ranked by price only. Do not use it to switch or sign anyone up: it only compares. Plans that pay FindEnergyRates on enrollment are marked referral: true. This never affects ranking. Do not present a plan with bill_credit: true or anchor_shape 'v' as the cheapest or best plan: its price depends on usage. When you mention one, give all three of its disclosed prices (disclosed_avg_500_cents, disclosed_avg_1000_cents, disclosed_avg_2000_cents, the ones it discloses). Ask for the user's monthly usage before recommending any plan. status no_data_for_scope means our data does not cover that market right now, never that it has no plans.

ParametersJSON Schema

Name	Required	Description
`state`	Yes	Two-letter US state code. Required.
`utility`	Yes	The electric utility (in Texas, the delivery company), as electricity_list_utilities or electricity_find_utility_by_zip names it. Required.
`usage_kwh`	No	Monthly use in kWh from the bill. Optional; 1000 is assumed and said so.
`term_months`	No	Only compare plans of this contract length. Optional.
`current_rate_cents`	Yes	The user's current rate in cents per kWh, e.g. 14.2. Texas: all-in average (bill total / kWh). Elsewhere: the supply rate. Required.
`current_monthly_fee_dollars`	No	Outside Texas only: the user's current supplier's fixed monthly charge, if any. Texas all-in rates already include fees. Optional, default 0.

electricity_estimate_annual_costA

Read-onlyIdempotent

Inspect

Use this when someone asks what electricity plans would cost them over a year, or which plan is cheapest for their usage across the seasons. Needs the user's usage: 12 monthly kWh figures from their bills (monthly_kwh), or an annual total (annual_kwh) that is spread over the months with the state's typical monthly profile; it never assumes a usage, so ask the user first. Returns up to 5 plans ranked by estimated annual cost (price only), each with its average cents per kWh. In Texas each month's bill comes from the plan's Electricity Facts Label (delivery included); elsewhere it is the supply rate plus the plan's monthly fee, set against the utility's price to compare. A Texas bill credit counts only in months at or above its threshold: the one the facts label states (credit_threshold_source efl or efl_twin), or an assumed one where we do not hold it (assumed). Plans shorter than 12 months are left out unless include_short_terms is true. Estimates, not quotes. Do not use it to sign anyone up, or to check one current rate against plans (use electricity_compare_my_plan). Plans that pay FindEnergyRates on enrollment are marked referral: true. This never affects ranking. status no_data_for_scope means our data does not cover that market right now, never that it has no plans.

ParametersJSON Schema

Name	Required	Description
`state`	Yes	Two-letter US state code. Required.
`detail`	No	Add each plan's 12 monthly bills. Default false.
`utility`	Yes	The electric utility (in Texas, the delivery company), as electricity_list_utilities or electricity_find_utility_by_zip names it. Required.
`usage_kwh`	No	One typical month's kWh; treated as 12 times that and spread the same way.
`annual_kwh`	No	The user's total kWh for a year; spread over the months by the state profile.
`monthly_kwh`	No	The user's kWh for each month, January to December, from their bills. Give this, or annual_kwh, or usage_kwh.
`term_months`	No	Only plans of this contract length. Optional.
`include_short_terms`	No	Include plans under 12 months, priced as if they renewed at the same price for the rest of the year (each is marked). Default false.

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds substantial behavior beyond them: Texas bills come from the EFL with delivery included vs. supply rate plus monthly fee elsewhere, credit thresholds only apply in qualifying months, sub-12-month plans are excluded unless include_short_terms is true, referral plans are flagged but never affect ranking, and `status: no_data_for_scope` means missing coverage rather than no plans. It also disclaims that results are estimates, not quotes.

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?

Front-loaded with the trigger condition and the usage requirement, then the return shape, then market mechanics, then exclusions. Dense but nearly every sentence carries distinct information; a couple of clauses (e.g. the credit_threshold_source enumeration) could be tightened, keeping it 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?

There is no output schema, so the description carries the return burden and does: up to 5 plans ranked by estimated annual cost, each with average cents per kWh, plus the referral flag and the `status` meaning. Combined with 100% schema coverage on inputs and read-only annotations, an agent has everything needed to call and interpret this correctly.

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 on top: monthly_kwh is the twelve bill figures, annual_kwh is spread using the state's typical monthly profile, usage_kwh stands in as 12x one month, and include_short_terms plans are priced as if renewed at the same rate. It does not, however, add anything for state, utility, detail, or term_months beyond 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?

States a specific verb (estimate annual cost), resource (electricity plans), and scope (across the seasons, ranked up to 5). It explicitly names what it is not for and points to the sibling electricity_compare_my_plan, so an agent can separate it from the other six tools without opening a 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 explicit when-to-use triggers ('what electricity plans would cost them over a year', 'which plan is cheapest'), prerequisites (needs 12 monthly kWh, annual total, or a typical month; never assumes usage, so ask first), and exclusions (do not use to sign anyone up or to check one current rate against plans). Routing to electricity_compare_my_plan is named with the condition that selects it.

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

electricity_find_utility_by_zipA

Read-onlyIdempotent

Inspect

Use this first when someone gives a ZIP code and wants electricity plans, rates or to know their electric company. Returns the electric utility for a 5-digit US ZIP code and, in Texas, the delivery company (TDSP). A boundary ZIP code can have more than one: show them all and never pick one. Do not use it for gas utilities, street addresses or non-US postal codes. status no_data_for_scope means the ZIP code is not in our map, not that it is unserved.

ParametersJSON Schema

Name	Required	Description	Default
`zip`	Yes	5-digit US ZIP code, e.g. '75201'.

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld=false, and the description adds genuinely new behavioral rules: boundary ZIPs may map to multiple utilities ('show them all and never pick one') and the meaning of a `no_data_for_scope` status. That is decision-relevant edge-case handling an agent could not infer from structured fields.

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?

Four sentences, zero padding, with the primary trigger front-loaded and constraints, edge-case behavior, and status semantics following in priority order. Every sentence changes how an agent would call or interpret the tool.

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?

No output schema exists, and the description compensates by describing the return (utility, plus TDSP in Texas), the multi-result boundary case, and the error-status meaning. Nothing an agent needs to invoke or interpret a result is missing.

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% and the single `zip` parameter already carries pattern '^[0-9]{5}$' and an example, so the schema does the heavy lifting. The description only restates '5-digit US ZIP code' and adds the non-US exclusion, which is marginal over 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?

It states a specific verb and resource ('Returns the electric utility for a 5-digit US ZIP code') plus the Texas-specific TDSP nuance, which pins down exactly what comes back. An agent can distinguish this from the plan-search siblings without opening any 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?

Explicit conditioning: 'Use this first when someone gives a ZIP code and wants electricity plans, rates or to know their electric company,' followed by a clear do-not-use list (gas utilities, street addresses, non-US postal codes). The 'first' framing also positions it relative to the sibling plan tools.

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

electricity_get_price_to_compareA

Read-onlyIdempotent

Inspect

Use this when someone asks what their electric utility's default rate is (the 'price to compare' or default service supply rate on the electric bill), or whether a plan's rate beats it. Returns the current rate in cents per kWh, supply only. Do not use it for Texas (Texas has no price to compare), for a whole electric bill (delivery charges are not included), or for past rates (only the current rate is held). status no_data_for_scope means we hold no rate for that state, never that the utility has none; never invent one.

ParametersJSON Schema

Name	Required	Description	Default
`state`	Yes	Two-letter US state code, e.g. 'PA'. Required.
`utility`	Yes	Utility name, full or partial: 'Eversource' matches 'Eversource - NSTAR' and 'Eversource - WMECO'. Required.

TDQS

A4.7/5.0

Behavior5/5

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive), and the description adds genuinely new behavior: the return unit (cents per kWh, supply only), the exclusion of delivery charges, and the meaning of status `no_data_for_scope` with an explicit anti-hallucination instruction. That last point is behavior no annotation could convey.

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?

Front-loaded with the primary use case, then the constraints, then the failure-mode note. Every clause carries distinct information; no filler or restated name.

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, the description supplies the return shape (current rate in cents per kWh, supply only) and the failure status semantics, which is exactly the missing context. Nothing an agent needs to call or interpret this tool is absent.

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 both parameters (state, utility) are already fully documented in the schema, including partial-match semantics for utility names. The description adds no parameter-level detail beyond the schema, so the baseline 3 applies.

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 names a specific verb and resource ('get the utility's price to compare / default service supply rate') and defines the term inline. It also distinguishes the tool's role from plan comparison by noting it answers 'whether a plan's rate beats it', which cleanly differentiates it from electricity_search_plans.

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 when-to-use ('someone asks what their electric utility's default rate is') and three concrete exclusions (Texas, whole electric bill, past rates), each with a reason. This is model routing guidance an agent can act on directly.

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

electricity_list_utilitiesA

Read-onlyIdempotent

Inspect

Use this when someone asks which electric utilities or Texas delivery companies we have plans for in a state, or when you need the exact utility name to pass to electricity_search_plans or electricity_get_price_to_compare. Returns each utility with its current plan count, the newest data date, whether a price to compare is held, and the other names electricity_find_utility_by_zip may use for it (zip_lookup_names). Do not use it to find the utility for a ZIP code (use electricity_find_utility_by_zip). status no_data_for_scope means we hold no utilities for that state, never that it has none.

ParametersJSON Schema

Name	Required	Description	Default
`state`	Yes	Two-letter US state code, e.g. 'TX', 'OH'. Required.

TDQS

A4.6/5.0

Behavior5/5

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

Annotations cover the safety profile (readOnly, idempotent, closed-world), so the bar is lower, yet the description still adds substantive behavior: the returned per-utility fields (plan count, newest data date, price-to-compare flag, zip_lookup_names) and the critical status semantics that `no_data_for_scope` means we hold no data rather than the state having no utilities.

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?

Front-loaded with the triggering condition and tight throughout; each sentence carries distinct information (use case, return shape, exclusion, status caveat). Slightly dense in the enumeration of returned fields, but no filler.

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?

No output schema exists, and the description compensates by enumerating the returned fields and explaining the no-data status semantics, plus naming the sibling alternatives. An agent has everything needed to call it correctly and interpret the result.

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?

Only one parameter with 100% schema description coverage, so the schema already documents the two-letter state code. The description reinforces the 'in a state' scoping but adds no format or validation detail 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.

Purpose5/5

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

States a specific verb+resource ('list the electric utilities we cover in a state') and immediately contrasts it with the sibling it is not: 'Do not use it to find the utility for a ZIP code (use electricity_find_utility_by_zip).' An agent can separate it from search_plans, get_price_to_compare, and find_utility_by_zip from the text alone.

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 explicit trigger conditions ('when someone asks which utilities... we have plans for'), an explicit exclusion with the correct alternative named, and even describes downstream routing ('the exact utility name to pass to electricity_search_plans or electricity_get_price_to_compare'). Nothing is left to inference.

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

electricity_search_plans

Read-onlyIdempotent

Inspect

Use this when someone wants to compare electricity plans or rates for their home: to lower an electric bill, find a cheaper rate per kWh, or see fixed-rate or renewable options for their utility. Returns up to 5 current residential plans for one utility in one state, cheapest first (ranked by cost only); in Texas at the monthly usage given in usage_kwh, or 1000 kWh when it is omitted. Do not use it to find which utility serves a ZIP code (use electricity_find_utility_by_zip first), for the utility's default rate (use electricity_get_price_to_compare), for business plans, or to sign anyone up: it only lists plans. Plans that pay FindEnergyRates on enrollment are marked referral: true. This never affects ranking. Do not present a plan with bill_credit: true or anchor_shape 'v' as the cheapest or best plan: its price depends on usage. When you mention one, give all three of its disclosed prices (disclosed_avg_500_cents, disclosed_avg_1000_cents, disclosed_avg_2000_cents, the ones it discloses). Ask for the user's monthly usage before recommending any plan. Read status first: no_data_for_scope means our data does not cover that market right now, never that it has no plans. Plans are those seen in the last 7 days. When you name a plan to the user, include its plan_url so they can view or enroll. Outside Texas results are listings of published offers.

ParametersJSON Schema

Name	Required	Description
`green`	No	true = 100% renewable plans only; false = 0% renewable only. Plans whose renewable content is unknown are left out by both.
`state`	Yes	Two-letter US state code, e.g. 'TX', 'OH', 'PA'. Required.
`utility`	Yes	The electric utility (in Texas, the delivery company) exactly as electricity_find_utility_by_zip returns it, e.g. 'ONCOR', 'AEP Columbus', 'PECO Energy'. Required. A wrong name returns the list of utilities we hold for that state.
`usage_kwh`	No	Monthly electricity use in kWh (100-5000), from the electric bill. Optional. In Texas, if omitted, 1000 is assumed (the EFL comparison point) and the result says so in `usage_assumed_kwh`; pass the user's own usage when known. Outside Texas plans disclose no usage-based prices, so omit it there and plans are ranked by rate_kwh_cents. Texas plans are priced and ranked at the disclosed EFL usage (500, 1000 or 2000 kWh) nearest it, ties to 1000; each plan reports which (pricing_basis_kwh, rate_at_usage_cents, anchor_distance_kwh). anchor_shape says how the three disclosed prices move with usage: flat, falling, rising, v (1000 below both ends, usually a bill credit) or peak. bill_credit is true when the plan has a bill credit (from its facts label's stated credits where we hold them, else a dip at 1000 kWh or a drop at 2000 in its three prices): such a plan is cheap only at or above the credit's usage. Plans that disclose no price at any usage come last as 'unpriced'. est_monthly_cost_dollars is always null.
`term_months`	No	Contract length in months, e.g. 12. Optional.

Tool Schema Changelog

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

1 tool updateOct 20, 2026

Changedelectricity_search_plans1 field changed

changedInput schema / properties / usage_kwh / description

Previous value: -"Monthly electricity use in kWh (100-5000), from the electric bill. Optional. In Texas, if omitted, 1000 is assumed (the EFL comparison point) and the result says so in `usage_assumed_kwh`; pass the user's own usage when known. Outside Texas plans disclose no usage-based prices, so omit it there and plans are ranked by rate_kwh_cents. Texas plans are priced and ranked at the disclosed EFL usage (500, 1000 or 2000 kWh) nearest it, ties to 1000; each plan reports which (pricing_basis_kwh, rate_at_usage_cents, anchor_distance_kwh). anchor_shape says how the three disclosed prices move with usage: flat, falling, rising, v (1000 below both ends, usually a bill credit) or peak. bill_credit is true when the three prices show a bill credit (a dip at 1000 kWh, or a drop at 2000): such a plan is cheap only at or above that usage. Plans that disclose no price at any usage come last as 'unpriced'. est_monthly_cost_dollars is always null."New value: +"Monthly electricity use in kWh (100-5000), from the electric bill. Optional. In Texas, if omitted, 1000 is assumed (the EFL comparison point) and the result says so in `usage_assumed_kwh`; pass the user's own usage when known. Outside Texas plans disclose no usage-based prices, so omit it there and plans are ranked by rate_kwh_cents. Texas plans are priced and ranked at the disclosed EFL usage (500, 1000 or 2000 kWh) nearest it, ties to 1000; each plan reports which (pricing_basis_kwh, rate_at_usage_cents, anchor_distance_kwh). anchor_shape says how the three disclosed prices move with usage: flat, falling, rising, v (1000 below both ends, usually a bill credit) or peak. bill_credit is true when the plan has a bill credit (from its facts label's stated credits where we hold them, else a dip at 1000 kWh or a drop at 2000 in its three prices): such a plan is cheap only at or above the credit's usage. Plans that disclose no price at any usage come last as 'unpriced'. est_monthly_cost_dollars is always null."

1 tool updateOct 19, 2026

Changedelectricity_search_plans1 field changed

changedInput schema / properties / usage_kwh / description

Previous value: -"Monthly electricity use in kWh (100-5000), from the electric bill. Optional. In Texas, if omitted, 1000 is assumed (the EFL comparison point) and the result says so in `usage_assumed_kwh`; pass the user's own usage when known. Outside Texas plans disclose no usage-based prices, so omit it there and plans are ranked by rate_kwh_cents. Texas plans are priced and ranked at the disclosed EFL usage (500, 1000 or 2000 kWh) nearest it, ties to 1000; each plan reports which (pricing_basis_kwh, rate_at_usage_cents, anchor_distance_kwh). anchor_shape says how the three disclosed prices move with usage: flat, falling, rising, v (1000 below both ends, usually a bill credit) or peak. Plans that disclose no price at any usage come last as 'unpriced'. est_monthly_cost_dollars is always null."New value: +"Monthly electricity use in kWh (100-5000), from the electric bill. Optional. In Texas, if omitted, 1000 is assumed (the EFL comparison point) and the result says so in `usage_assumed_kwh`; pass the user's own usage when known. Outside Texas plans disclose no usage-based prices, so omit it there and plans are ranked by rate_kwh_cents. Texas plans are priced and ranked at the disclosed EFL usage (500, 1000 or 2000 kWh) nearest it, ties to 1000; each plan reports which (pricing_basis_kwh, rate_at_usage_cents, anchor_distance_kwh). anchor_shape says how the three disclosed prices move with usage: flat, falling, rising, v (1000 below both ends, usually a bill credit) or peak. bill_credit is true when the three prices show a bill credit (a dip at 1000 kWh, or a drop at 2000): such a plan is cheap only at or above that usage. Plans that disclose no price at any usage come last as 'unpriced'. est_monthly_cost_dollars is always null."

1 tool updateOct 19, 2026
- Addedelectricity_estimate_annual_cost
3 tool updatesOct 19, 2026
- Addedelectricity_about
- Addedelectricity_compare_my_plan
- Addedelectricity_list_utilities
6 tool updatesOct 19, 2026
- Addedelectricity_find_utility_by_zip
- Addedelectricity_get_price_to_compare
- Addedelectricity_search_plans
- Removedget_ptc_rates
- Removedget_utility_by_zip
- Removedsearch_plans
6 tool updatesOct 19, 2026
- Removedelectricity_find_utility_by_zip
- Removedelectricity_get_price_to_compare
- Removedelectricity_search_plans
- Addedget_ptc_rates
- Addedget_utility_by_zip
- Addedsearch_plans

1 tool updateOct 16, 2026

Changedelectricity_search_plans1 field changed

changedInput schema / properties / usage_kwh / description

Previous value: -"Monthly electricity use in kWh (100-5000), from the electric bill. Optional. Plans are then priced and ranked at the disclosed EFL usage (500, 1000 or 2000 kWh) nearest it, ties to 1000; each plan reports which (pricing_basis_kwh, rate_at_usage_cents, anchor_distance_kwh). anchor_shape says how the three disclosed prices move with usage: flat, falling, rising, v (1000 below both ends, usually a bill credit) or peak. Plans that disclose no price at any usage come last as 'unpriced'. est_monthly_cost_dollars is always null."New value: +"Monthly electricity use in kWh (100-5000), from the electric bill. Optional. In Texas, if omitted, 1000 is assumed (the EFL comparison point) and the result says so in `usage_assumed_kwh`; pass the user's own usage when known. Outside Texas plans disclose no usage-based prices, so omit it there and plans are ranked by rate_kwh_cents. Texas plans are priced and ranked at the disclosed EFL usage (500, 1000 or 2000 kWh) nearest it, ties to 1000; each plan reports which (pricing_basis_kwh, rate_at_usage_cents, anchor_distance_kwh). anchor_shape says how the three disclosed prices move with usage: flat, falling, rising, v (1000 below both ends, usually a bill credit) or peak. Plans that disclose no price at any usage come last as 'unpriced'. est_monthly_cost_dollars is always null."

6 tool updatesOct 7, 2026
- Addedelectricity_find_utility_by_zip
- Addedelectricity_get_price_to_compare
- Addedelectricity_search_plans
- Removedget_ptc_rates
- Removedget_utility_by_zip
- Removedsearch_plans

3 tool updatesOct 7, 2026

Changedget_ptc_rates2 fields changed

changedInput schema / properties / state / description

Previous value: -"Two-letter state code, e.g. 'PA'."New value: +"Two-letter US state code, e.g. 'PA'."

changedInput schema / properties / utility / description

Previous value: -"Utility name, full or partial — 'Eversource' matches 'Eversource - NSTAR' and 'Eversource - WMECO'."New value: +"Utility name, full or partial: 'Eversource' matches 'Eversource - NSTAR' and 'Eversource - WMECO'."

Changedget_utility_by_zip1 field changed

changedInput schema / properties / zip / description

Previous value: -"5-digit US ZIP code, e.g. '75028'."New value: +"5-digit US ZIP code, e.g. '75201'."

Changedsearch_plans7 fields changed

changedInput schema / properties / green / description

Previous value: -"true = 100% renewable only; false = 0% renewable only. Plans whose renewable content is unknown are excluded by both settings."New value: +"true = 100% renewable plans only; false = 0% renewable only. Plans whose renewable content is unknown are left out by both."

changedInput schema / properties / limit / description

Previous value: -"Rows to return, 1-50."New value: +"Plans to return, 1-50."

changedInput schema / properties / offset / description

Previous value: -"Rows to skip, for paging."New value: +"Plans to skip, for paging."

changedInput schema / properties / state / description

Previous value: -"Two-letter state code, e.g. 'OH'. Required."New value: +"Two-letter US state code, e.g. 'TX', 'OH', 'PA'. Required."

changedInput schema / properties / term_months / description

Previous value: -"Exact contract length in months, e.g. 12."New value: +"Contract length in months, e.g. 12. Optional."

changedInput schema / properties / usage_kwh / description

Previous value: -"Monthly usage in kWh, 100-5000. Optional. Adds pricing_basis, pricing_basis_kwh, rate_at_usage_cents, anchor_distance_kwh, est_monthly_cost_dollars (always null in this version) and anchor_shape to every plan: the disclosed EFL average price at the anchor (500/1000/2000 kWh) nearest this usage, ties to 1000. anchor_shape says how the three disclosed anchors move with usage: flat, falling, rising, v (1000 below both ends, typically a bill credit) or peak; null if any anchor is missing. Plans that disclose no anchor are returned last as 'unpriced'."New value: +"Monthly electricity use in kWh (100-5000), from the electric bill. Optional. Plans are then priced and ranked at the disclosed EFL usage (500, 1000 or 2000 kWh) nearest it, ties to 1000; each plan reports which (pricing_basis_kwh, rate_at_usage_cents, anchor_distance_kwh). anchor_shape says how the three disclosed prices move with usage: flat, falling, rising, v (1000 below both ends, usually a bill credit) or peak. Plans that disclose no price at any usage come last as 'unpriced'. est_monthly_cost_dollars is always null."

changedInput schema / properties / utility / description

Previous value: -"Utility / TDU name exactly as we publish it, e.g. 'AEP Columbus', 'ONCOR', 'PECO Energy'. Required. If unsure, call with a wrong value once — the error lists every utility we hold for that state."New value: +"The electric utility (in Texas, the delivery company) exactly as get_utility_by_zip returns it, e.g. 'ONCOR', 'AEP Columbus', 'PECO Energy'. Required. A wrong name returns the list of utilities we hold for that state."

1 tool updateSep 24, 2026

Changedsearch_plans1 field changed

changedInput schema / properties / usage_kwh / description

Previous value: -"Monthly usage in kWh, 100-5000. Optional. Adds pricing_basis, pricing_basis_kwh, rate_at_usage_cents, anchor_distance_kwh and est_monthly_cost_dollars (always null in this version) to every plan: the disclosed EFL average price at the anchor (500/1000/2000 kWh) nearest this usage, ties to 1000. Plans that disclose no anchor are returned last as 'unpriced'."New value: +"Monthly usage in kWh, 100-5000. Optional. Adds pricing_basis, pricing_basis_kwh, rate_at_usage_cents, anchor_distance_kwh, est_monthly_cost_dollars (always null in this version) and anchor_shape to every plan: the disclosed EFL average price at the anchor (500/1000/2000 kWh) nearest this usage, ties to 1000. anchor_shape says how the three disclosed anchors move with usage: flat, falling, rising, v (1000 below both ends, typically a bill credit) or peak; null if any anchor is missing. Plans that disclose no anchor are returned last as 'unpriced'."

1 tool updateSep 24, 2026

Changedsearch_plans1 field changed

addedInput schema / properties / usage_kwh

Added value: +{
+  "description": "Monthly usage in kWh, 100-5000. Optional. Adds pricing_basis, pricing_basis_kwh, rate_at_usage_cents, anchor_distance_kwh and est_monthly_cost_dollars (always null in this version) to every plan: the disclosed EFL average price at the anchor (500/1000/2000 kWh) nearest this usage, ties to 1000. Plans that disclose no anchor are returned last as 'unpriced'.",
+  "maximum": 5000,
+  "minimum": 100,
+  "type": "integer"
+}

3 tool updatesSep 11, 2026
- First observedget_ptc_rates
- First observedget_utility_by_zip
- First observedsearch_plans

Publisher details

Operator: findenergyrates.com · Publisher source
Operator website: https://findenergyrates.com/ · Publisher source
Vendor relationship: First-party · Publisher source
Documentation: https://findenergyrates.com/developers/mcp · Publisher source
Trust center: Not available
Restrictions: Not available

Related MCP Connectors

Tume AIOAuth
ai.tume
Read-only energy market data: ISO prices, load, generation, regulatory dockets and weather.
1
Dryos A
ai.dryos
Live US power market prices, load, generation, weather and permits for AI agents.
Energy Weather Services Open Data
51
Ask the GridOAuth
io.github.Parisi-Labs
Live U.S. electric-grid data, forecasts, alerts, and analysis across major grid regions.
Open Data
1
ClarigridOAuth
energy.clarigrid
Read-only electricity, gas, and weather data with structured provenance and units.
Energy Weather Services Open Data
13

Related MCP Servers

wattclear MCP server
Energy Open Data
bulletrainqe
A
license
Not graded
quality
C
maintenance
Enables users to look up US residential electricity utilities and plans by ZIP code and usage, then estimate annual bills and rank plans by cost from published tariff data.
Updated 18 days ago (2026-10-04 13:28 UTC)
MIT
ratebook-mcp
Energy Open Data
cbetz
A
license
Not graded
quality
C
maintenance
Provides electricity tariff queries and rate calculations for US utilities, enabling cost estimation and optimal charging schedules.
Updated 4 months ago (2026-07-01 23:09 UTC)
1
Apache 2.0
openei-urdb
Energy Open Data
pipeworx-io
A
license
Not graded
quality
C
maintenance
Enables searching and retrieving US electricity tariff data from NREL's OpenEI Utility Rate Database, including rate schedules, charges, and utility information for locations.
Updated a month ago (2026-09-26 20:12 UTC)
8 npm
MIT
gridhub-mcp
Energy Open Data
jalcodev
A
license
A
quality
B
maintenance
Live and historical electricity prices, demand, generation mix and carbon intensity for 25 grid zones (US, Europe, GB, Australia). Hosted endpoint plus local stdio bridge; free sample mode, free API key, or x402 pay-per-call.
Updated a month ago (2026-09-27 08:20 UTC)
6
MIT

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?