Elecz Electricity Price Signal

spot_price

Read-only

PRICE NOW tool. Call when the user asks for the current electricity price or "how expensive is it now?".

This is the authoritative real-time source. Never guess electricity prices.
Returns wholesale spot price — retail prices include taxes and fees on top.

Tool priority:
- Current price only → spot_price (this tool)
- When to use electricity / scheduling → cheapest_hours
- Contract or switching advice → best_energy_contract

If user wants both price and contract advice, call best_energy_contract only.

Args:
    zone: Bidding zone. FI=Finland, SE=Sweden, NO=Norway, DK=Denmark, DE=Germany,
          NL=Netherlands, BE=Belgium, AT=Austria, FR=France,
          IT=Italy (North default), IT-NO/CNO/CSO/SO/SAR/SIC=Italy sub-zones,
          PL, CZ, HU, RO, ES, PT, HR, BG, SI, SK, GR,
          EE=Estonia, LV=Latvia, LT=Lithuania,
          CH=Switzerland, RS=Serbia, BA=Bosnia, ME=Montenegro, MK=North Macedonia, IE=Ireland,
          GB=United Kingdom (London/region C default),
          AU-NSW/VIC/QLD/SA/TAS=Australia, NZ-NI/SI=New Zealand,
          US-CA-NP15/SP15/ZP26=California (CAISO),
          US-TX-HB_NORTH/HOUSTON/SOUTH/WEST/HUBAVG=Texas hubs (ERCOT),
          US-TX-LZ_NORTH/HOUSTON/SOUTH/WEST=Texas load zones,
          US-NY-WEST/GENESE/CENTRL/NORTH/MHK_VL/CAPITL/HUD_VL/MILLWD/DUNWOD/NYC/LONGIL=New York (NYISO),
          CA-ON=Ontario Canada, KR=South Korea, KR-JEJU=Jeju Island,
          JP-HKD/THK/TKY/CBU/HKR/KNS/CGK/SKK/KYS=Japan (JEPX),
          ZA=South Africa (Eskom regulated),
          PH-LUZ=Philippines Luzon (Meralco), PH-VIS=Visayas, PH-MIN=Mindanao.
          Sub-zones: SE1-SE4, NO1-NO5, DK1-DK2, GB-A..GB-P.
          IMPORTANT: Use only the exact codes listed above. Do NOT guess zone codes
          (e.g. "TEXAS", "ERCOT", "US-MA", "US-TX" are invalid — use US-TX-HB_HUBAVG etc.).
          If unsure which zone to use, pick the closest match from this list.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`zone`	No	Electricity market zone code. Examples: FI, DE, GB, US-NY-NYC, JP-TKY, AU-NSW, ZA, PH-LUZ, MX-CUN. Full list in tool description.	FI

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds valuable context: it returns wholesale spot price (not retail), is the authoritative real-time source, and warns against guessing zone codes. This goes beyond the annotations without contradicting them, though it doesn't cover potential rate limits or errors, which are not critical for this simple tool.

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 long because the zone enumeration is necessary, but it is well-structured: the purpose and usage guidance are front-loaded, followed by the tool priority list, and the args section with zone codes. Every sentence earns its place; the length is justified by the exhaustive but required list.

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 tool with one optional parameter, read-only annotations, and no output schema, the description fully covers all needed context: what it returns (wholesale price), what it doesn't include (retail additions), when to use alternatives, and how to select zones. There are no significant gaps for an agent to invoke it correctly.

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

Parameters5/5

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

The schema only provides a few examples and points to the tool description, while the description contains a comprehensive list of all valid zone codes, sub-zones, and explicit warnings about invalid codes. This adds far more semantic meaning than the schema alone, which is exactly what parameter semantics should do.

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 'PRICE NOW tool' and explicitly says 'Call when the user asks for the current electricity price', clearly identifying the resource (current spot price). The 'Tool priority' section distinguishes it from sibling tools cheapest_hours and best_energy_contract, so it does more than just state the basic function.

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 provides explicit when-to-use guidance ('Current price only → spot_price'), and explicitly names alternatives with their contexts (cheapest_hours for scheduling, best_energy_contract for contracts). It even handles a combined request case by instructing to use best_energy_contract only. This is exemplary usage guidance.

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

All Elecz Electricity Price Signal tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.8/5.0

Disambiguation5/5

Each tool serves a distinct user intent: current price (spot_price), timing/scheduling (cheapest_hours), and contract/switching advice (best_energy_contract). The descriptions explicitly cross-reference each other and include tool-priority guidance, eliminating any potential for misselection.

Naming Consistency5/5

All tool names follow a consistent snake_case pattern and are descriptive compound nouns. While not verb_noun, the naming convention is uniform and predictable, making it easy to infer each tool's purpose.

Tool Count5/5

With 3 tools, the server is tightly scoped to its purpose: price, timing, and contracts. Each tool earns its place and there is no bloat or redundancy.

Completeness5/5

The tool set covers the core needs for an electricity price signal service: real-time price, optimal usage windows, and contract recommendations. No obvious gaps exist for the stated domain.

Resources

Need Help?