Loading ToolBench
MCP server for Finnish electricity spot price data from Sahkotin.fi, providing current prices, forecasts, historical data, and price predictions
Spothinta provides 4 well-named, verb-prefixed tools (get_current_price, get_today_prices, get_tomorrow_prices, get_price_history) for fetching Finnish electricity pricing data. All tools have clear, descriptive names following verb_noun convention. However, critical gaps exist: tool descriptions lack actionable detail about when to use each tool vs. alternatives, parameter descriptions are minimal, output schemas are not documented in the source, and error handling guidance is absent. The server is HTTP-based with mcp-handler integration, but provides no tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite all tools being read-only. Three tools accept no parameters (empty input schemas), while get_price_history has a properly typed schema. Overall, definitions are functional but lack LLM-optimization and production polish expected of A/B-tier tools.
Get the current electricity price in Finland (c/kWh incl. 25.5% VAT)
Get historical electricity prices for a date range in Finland (c/kWh incl. 25.5% VAT). Maximum 30-day range.
Get hourly electricity prices for today in Finland (c/kWh incl. 25.5% VAT)
Get hourly electricity prices for tomorrow in Finland (c/kWh incl. 25.5% VAT). Prices are typically available after 14:00 EET.
Output schemas not documented. No visible specification of what fields get_current_price, get_today_prices, get_tomorrow_prices return (e.g., price as float, unit, timestamp structure). LLMs cannot plan downstream processing or compose tools without knowing response structure. Baseline: 100% of A+ tools have documented return types.
Tool descriptions lack differentiation and selection guidance. All descriptions state 'Get...electricity prices in Finland (c/kWh incl. 25.5% VAT)' without explaining WHEN to call each tool instead of alternatives. Pattern baseline: descriptions should answer 'What does it do? When should the LLM call it instead of a similar tool? What does it return?' Descriptions are 60 - 100 chars; should be 10 - 1024 with actionable context.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 76 | 2026-07-28+ | v2 |
Tool annotations missing. All tools are read-only operations but lack readOnlyHint: true in their definition. This omission forces LLMs to reason about idempotency and safety, and prevents client tooling from optimizing request batching. Current MCP spec (2026-07-28) rewards tool annotations.
No error handling guidance. Tools make external API calls (sahkotin.fi) but lack documented error responses or recovery guidance. If the API is unavailable, what does the tool return? Should the LLM retry? Call an alternative tool? Baseline: error responses must tell the LLM what to do next.
Parameter descriptions missing or incomplete. get_price_history has 'start' and 'end' parameters with descriptions ('Start date in ISO format...', 'End date in ISO format...') but lacks explicit range constraints (30-day limit mentioned only in tool description, not in 'end' param description). Pattern baseline: describe the expected format, range, and allowed values directly in parameter description.
No result limiting or pagination documented. Tools return 'prices' arrays; no visible limit, pagination, or total_count guidance. If get_price_history returns 30 days × 24 hours = 720 price points, how are they presented? Pagination or result capping not visible. Baseline: tools returning lists should accept limit parameters and return pagination info.