Skip to main content
Glama
Sign In

Energi Data Dk

by io.github.pipeworx-io
OverviewDiscussionsAdmin

Spot Prices

spot_prices
Read-onlyIdempotent

Day-ahead electricity spot prices from Energi Data Service (Energinet, Denmark/Nordic). Prices per bidding zone (PriceArea) in DKK and EUR per MWh: 15-minute intervals from 2025-10-01 (the day-ahead market moved to 15-minute products), hourly before that. Bidding zones: DK1 (west Denmark), DK2 (east Denmark), DE (Germany), NO2, SE3, SE4, and others. Omit "area" to get all zones. Keyless official open data.

Example tool call

This call uses example arguments supplied in the tool’s input schema.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "area": "DK1",
      "limit": 24
    },
    "name": "spot_prices"
  }
}

Input Schema

NameRequiredDescriptionDefault
endNoISO date/time upper bound.
areaNoBidding zone, e.g. "DK1", "DK2", "DE". Omit for all areas.
limitNoMax records (default 96, i.e. the last 24 hours of 15-minute rows for one area).
startNoISO date/time lower bound, e.g. "2026-06-01" or "2026-06-01T00:00".

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / limit / description
      Previous value: -"Max records (default 24, i.e. last 24 hourly rows)."New value: +"Max records (default 96, i.e. the last 24 hours of 15-minute rows for one area)."
  2. Changed1 schema field changed
    • addedInput schema / examples
      Added value: +[
+  {
+    "area": "DK1",
+    "limit": 24
+  },
+  {
+    "end": "2026-06-02",
+    "start": "2026-06-01"
+  }
+]
  3. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/open-world, so the description is free to add real value: 15-minute interval granularity from 2025-10-01 and hourly before, dual currency (DKK and EUR per MWh), and that no API key is needed. It does not mention timezone semantics or rate limits, which keeps it from a 5.

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 source and resource, then units, granularity, and zone list, with no filler sentences. It runs long, but nearly every clause carries decision-relevant information an agent needs before calling.

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?

With no output schema, the description does the work of describing returns: one row per zone per interval in DKK and EUR per MWh. There is a minor gap around timestamp semantics (local vs UTC, DST) and how `limit` interacts with multi-zone queries, but nothing blocking for a 4-parameter read-only tool.

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 baseline is 3; the description goes beyond it by explaining the zone vocabulary (DK1 west, DK2 east, DE, NO2, SE3, SE4) and the interval granularity that determines what `limit` and the start/end bounds actually address. Timezone/format of the ISO bounds is still left to 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?

States a specific verb+resource (day-ahead electricity spot prices), names the upstream source (Energi Data Service / Energinet) and the geography (Denmark/Nordic). No sibling in the list covers power market prices, so the boundary is unambiguous.

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?

"Omit 'area' to get all zones" and "Keyless official open data" give clear operating context. It stops short of explicit when-to-use/when-not guidance relative to any alternative (e.g. co2_intensity for grid mix), so a 4 rather than a 5.

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

All Energi Data Dk 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