Skip to main content
Glama

Elecz Electricity Price Signal API

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,
          If the user mentions Texas/ERCOT without naming a specific hub,
          default to US-TX-HB_HUBAVG. Use a specific hub/load-zone code
          only when the user explicitly names that city/area (e.g.
          "Houston", "North Texas").
          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
NameRequiredDescriptionDefault
zoneNoElectricity 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

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -{
      -  "properties": {
      -    "result": {
      -      "title": "Result",
      -      "type": "string"
      -    }
      -  },
      -  "required": [
      -    "result"
      -  ],
      -  "title": "_mcp_spotOutput",
      -  "type": "object"
      -}New value: +null
  2. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "properties": {
      +    "result": {
      +      "title": "Result",
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "result"
      +  ],
      +  "title": "_mcp_spotOutput",
      +  "type": "object"
      +}
  3. Changed1 schema field changed
    • addedInput schema / properties / zone / description
      Added value: +"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."
  4. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, and the description adds meaningful behavioral context: this is the authoritative real-time source, never guess prices, and it returns wholesale spot price rather than retail prices (which include taxes/fees). This adds value beyond the annotations, though it could still disclose output units or time-resolution behavior.

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 front-loaded with purpose and usage guidance, followed by detailed zone documentation. The zone list is long but necessary given the parameter's complexity, and the section headers keep it scannable. Some redundancy exists between the schema description and the full zone list, but it is not wasteful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter, read-only tool with no output schema, the description covers invocation intent, sibling routing, zone selection, defaults, and fallback behavior for ambiguous zones. It omits explicit output format and unit details, which would help an agent relay the answer, but the core calling context is fully specified.

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 gives a short example list and defers to the tool description. The description compensates with a comprehensive list of valid zone codes, sub-zones, regional defaults (e.g., Texas defaulting to US-TX-HB_HUBAVG), and explicit warnings not to guess codes. This provides far richer parameter semantics than the schema alone.

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 states it returns the current wholesale spot electricity price. It explicitly distinguishes itself from cheapest_hours and best_energy_contract in the tool priority list, so an agent can identify this tool by user intent 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?

The description provides clear routing rules: current price only → spot_price, scheduling → cheapest_hours, contract/switching → best_energy_contract, and if both price and contract advice are requested, call best_energy_contract only. This gives both positive and negative usage guidance with specific alternatives.

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.