elpriser-mcp

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered by structured data. The description adds the geographic/domain scoping (Danish grid operator) that explains why bounds exist, but discloses nothing about rate limits, failure modes, or what is returned on an unmapped coordinate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with the action and resource, followed by the reason it matters and a trigger phrase. There is no redundant restatement of the tool name or schema fields.

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

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

For a simple two-parameter read-only lookup with full schema coverage and rich annotations, the description supplies enough intent and domain context to call it correctly. The only gap is that it never hints at the return value (the netselskab name), which matters since no output schema exists.

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

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

Schema coverage is 100% with both parameters documented as WGS84 plus min/max bounds, so the schema already carries parameter meaning. The description only restates latitude/longitude at a high level and adds no format or precision guidance beyond the schema, making the baseline 3 appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

The description names a specific verb and resource ('Look up the Danish net company (netselskab)') and keys it to the exact lookup inputs ('for a location by latitude/longitude'), so an agent can tell it apart from the pricing siblings without opening the schema. It also supplies the domain term netselskab, which aids matching to Danish user phrasing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

It gives a clear triggering context — 'needed to compute the exact total price for an address' — plus a literal user query example, so the agent knows when this precedes a price calculation. It stops short of naming an explicit alternative or stating when not to use it, and it does not mention fallback behavior for out-of-Denmark coordinates.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds nothing behavioral beyond that — no mention of result ordering, tie-breaking, timezone/date boundary for "i dag/i morgen", or what happens when the requested hours span a day change. For a pure read tool this is an acceptable but thin contribution.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the action and scope, then immediately the practical use case. No filler, no repetition of title or schema content, and the quoted user phrasing is compact and aids intent matching.

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

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

For a zero-required-parameter, read-only query with fully documented schema, the description is sufficient to call the tool correctly, and the use-case framing substitutes well for an output schema. Minor gaps remain around returned ordering and the day-boundary semantics of "today/tomorrow" in Danish local time.

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

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

Schema description coverage is 100%, with both enums (area, mode) richly documented in the schema itself, so the baseline of 3 applies. The description only implies the `hours` and price-zone concepts already spelled out in the schema, adding no semantics such as whether `hours` must be contiguous or how ties are resolved.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

"Find the N cheapest hours of the day for a price zone" gives a specific verb (find/rank) and resource (cheapest hours), and the concrete use cases (EV charging, heat pump, dishwasher) make the intent unambiguous. It does not name any sibling such as get_current_price or get_price_forecast to draw the boundary explicitly, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

It states clearly when to reach for this tool: scheduling deferrable loads, and it even anchors the intent to a natural-language Danish query ("hvornår er strøm billigst i dag/i morgen"). There are no explicit exclusions or named alternatives that would tell an agent when to pick get_today_prices or get_current_price instead.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description adds only the 'this hour' freshness constraint; it says nothing about the data source, update cadence, or what happens if no current price is available. Useful but thin beyond what annotations provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with the action and the scope front-loaded; every clause carries routing value and there is no filler or repetition of the title.

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

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 should indicate what comes back — currency and unit (DKK/kWh vs. øre/kWh) or the price shape are never stated. Combined with silence on the data source and refresh timing, an agent cannot fully anticipate the response even though the calling surface (params, enums) is well covered.

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

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

Schema description coverage is 100% and both parameters are fully enumerated with per-value meanings (DK1/DK2 zones, the four price views), so the schema carries the semantic load. The description contributes only the loose phrase 'for a price zone' and adds no interpretation of mode or default behavior.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

States a specific verb and resource ('Get the current Danish electricity price') with a clear temporal scope ('this hour') and a subject ('a price zone'). The 'current/this hour' framing implicitly separates it from get_today_prices and get_price_forecast, but no sibling is named or explicitly excluded.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Gives explicit usage context by quoting the Danish user intents ('hvad er elprisen lige nu / hvad koster strøm nu'), which strongly supports intent-based routing. It stops short of naming alternatives or stating when to prefer get_today_prices or get_price_forecast instead.

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

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

Annotations only declare read-only, idempotent, open-world and non-destructive, so the description carries real weight and does so: prices are EUR/MWh without VAT, taxes or grid fees, Poland and GB also return local currency in zoneInfo, and gb is a within-day Market Index Price in GBP/MWh rather than a day-ahead price. It also warns that 'forecast' days are elpriser.org's own statistical estimate, not an official forecast — a caveat an agent could not derive from any structured field.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core capability and caveats packed into parentheticals rather than separate sentences, with the use-case line last. The one wasteful element is the full re-enumeration of all 40 zone codes, which largely duplicates the schema enum, though it does contribute the country-name-to-code mapping.

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

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

With a single required parameter, no output schema, and annotations covering the safety profile, the description supplies the units, currency nuances, and forecast caveat an agent needs to interpret results. It omits anything about the shape of the hourly series returned (e.g. how many hours, ordering) and any data-freshness or rate-limit context.

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

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

Schema coverage is 100% and the enum already constrains zone to the 40 valid keys, so the schema does the heavy lifting and the baseline is 3. The description does add modest meaning the enum lacks — human-readable expansions such as NO1-NO5, SE1-SE4, and 'Northern Italy (it-n)' — plus the gb currency caveat attached to that specific zone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

States a specific verb and resource ('Get spot electricity prices (day-ahead, hourly)') and bounds it to 40 named European bidding zones, so the agent knows exactly what domain it covers. It does not explicitly distinguish itself from siblings like get_current_price, get_today_prices, or get_price_forecast, leaving that inference to the agent.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

'Use for "what is the electricity price in Germany / Spain / Norway today"' gives a concrete triggering question shape and clear context for invocation. It stops short of naming exclusions or pointing to the sibling tools that handle current/forecast/cheapest-hours variants.

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

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

Annotations already declare readOnly, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description adds genuinely useful provenance information — that beyond tomorrow the values are estimates rather than published prices — but says nothing about caching or refresh cadence. That is a meaningful but modest addition given the annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two compact sentences, front-loaded with the core capability and the data-quality caveat immediately after. The Danish search phrase earns its place as a matching hint; nothing is redundant.

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

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

There is no output schema, and the description does not say what the result looks like — hourly resolution, per-area arrays, units, or currency. It covers the temporal scope well but leaves the return shape underspecified for a series-returning tool.

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

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

Schema coverage is 100% and both enum parameters are fully described in the schema, including what each mode costs and which zone maps to which region. The description only echoes "for a price zone" and adds no syntax or selection guidance 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.

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

States a specific verb and resource (7-day electricity price forecast) plus the zone scope, and explains that today/tomorrow are actual day-ahead prices while later days are weather-corrected estimates. It implicitly separates itself from siblings like get_today_prices and get_current_price, though it does not name them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Gives a clear use context via the quoted Danish phrasing "elpriser de næste dage / prognose", which signals the multi-day query intent. It does not state when to prefer the short-horizon siblings instead, so the routing guidance is clear but not exhaustive.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds only the defaults (today, a price zone) and confirms a full 24-hour set; it says nothing about response shape, units, or what happens for future dates beyond the forecast horizon.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two compact sentences with the core capability and default front-loaded, followed by a query-matching hint. No filler, though the quoted Danish phrase is the only slightly loose element.

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

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

The tool is simple and annotations cover safety, but there is no output schema and the description never characterizes the 24 returned entries (hour + price, currency). For a data-retrieval tool that gap is a real, if modest, omission.

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

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

Schema description coverage is 100% and both enums are fully documented in the schema, including the four pricing modes. The description's mention of date defaulting to today merely restates the schema, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

States a specific verb and resource with scope: 'Get all 24 hourly electricity prices for a given date ... in a price zone.' The 'all 24 hourly' wording implicitly separates it from get_current_price (single price) and get_cheapest_hours, but no sibling is named explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Offers a usage cue by quoting the Danish phrasing 'elpriser i dag / time for time', which helps match natural-language queries. However, it gives no explicit when-not guidance and never points to get_current_price, get_price_forecast, or get_european_prices as alternatives.

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