Skip to main content
Glama

Energy Charts

by io.github.pipeworx-io

Renewable Share

renewable_share
Read-onlyIdempotent

Renewable share of a country's electricity LOAD, as a percent — how much of demand wind, solar, hydro and biomass are covering, now or over a past date range. Answers "what share of Germany's electricity is renewable right now", "how renewable was France's grid in July", "which days last month did renewables cover most of the load". Accepts a country NAME ("Germany") or 2-letter code, or "eu"/"all" for the EU aggregate. Returns the latest MEASURED reading with its timestamp, a min/avg/max summary for the window, and a per-day breakdown; 15-minute readings are included for windows of 3 days or less. Values are percent OF LOAD and legitimately exceed 100 when a country generates more renewable power than it consumes and exports the surplus. Measured settled data, not a forecast. Keyless. Source: Fraunhofer ISE energy-charts.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
endNoOptional end date, YYYY-MM-DD, inclusive. Defaults to today.
startNoOptional start date, YYYY-MM-DD. Honoured — a past window returns that window. Defaults to 7 days ago. Maximum span 366 days.
countryYesCountry name ("Germany", "France") or 2-letter code ("de", "fr", "es", "pl"). Use "eu" or "all" for the EU aggregate.

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the read-only/idempotent annotations, the description discloses the return structure (latest reading, min/avg/max summary, per-day breakdown, 15-minute data for short windows), the unusual 'percent of load can exceed 100' interpretation, that it is measured settled data rather than a forecast, and that it is keyless. This is substantial behavioral context.

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

Conciseness5/5

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

The description is dense but efficient: every sentence adds useful information, key constraints like LOAD and MEASURED are front-loaded, and there is no filler or redundancy.

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 read-only, keyless tool with no output schema, the description covers inputs, output contents, units, edge-case interpretation, data provenance, and access requirements. Nothing essential is missing for an agent to invoke and interpret the tool correctly.

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

Parameters3/5

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

Schema coverage is 100%, so the baseline is 3. The description reinforces country name/code/'eu' formats and date-range behavior, but it mostly restates what the schema already documents rather than adding significant new parameter semantics.

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 precisely identifies the resource and metric: renewable share of a country's electricity LOAD as a percent, and it gives concrete example queries. It distinguishes itself from sibling energy tools by emphasizing LOAD and MEASURED settled data, so an agent can tell it apart from tools like generation_mix or total_power.

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?

The description clearly conveys when to use the tool through example questions and by stating it works for current readings or past date ranges. It also explains country vs. EU aggregate selection, but it does not explicitly name alternatives or state when not to use this tool.

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

All Energy Charts toolsInspect
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

A3.5/5.0
Disambiguation2/5

Many tools have overlapping purposes, such as ask_pipeworx, ask_pipeworx_grounded, and deep_research, which all perform similar data retrieval. The multiple Polymarket tools also overlap in focus, making it unclear which to use for a given task.

Naming Consistency2/5

Tool names are inconsistent: some use 'ask_', 'polymarket_', 'pipeworx_', while others like 'electricity_price', 'installed_power', and 'remember' follow no coherent pattern. Conventions are mixed and unpredictable.

Tool Count2/5

With 35 tools, the server is over-scoped for an 'Energy Charts' purpose. Only 5-6 tools are directly energy-related; the rest are a miscellany of data services, prediction markets, and memory functions, which is excessive and unfocused.

Completeness2/5

The server lacks essential energy analysis tools like forecast, emission factors, or capacity utilization, yet includes many unrelated tools (e.g., betting, memory). This creates significant gaps for the stated domain.

Resources