Skip to main content
Glama
Sign In

Eu Energy Imports

by io.github.pipeworx-io
OverviewDiscussionsAdmin

Import Origins

import_origins
Read-onlyIdempotent

Which countries a country imports natural gas, crude oil or coal FROM, ranked, with each supplier's share of the total and Russia's share called out. Works for Germany, any EU member, or the EU as a whole ("EU"). Annual by default (latest published year); gas and oil also accept a month. Answers "where does Germany get its gas", "how much gas does the EU still import from Russia", "who supplies Italy's oil". Source: Eurostat energy statistics.

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": {
      "geo": "DE",
      "fuel": "gas",
      "top_n": 5,
      "period": "2024"
    },
    "name": "import_origins"
  }
}

Input Schema

NameRequiredDescriptionDefault
geoNoImporting country as a 2-letter code ("DE", "FR", "IT", "EL" for Greece) or "EU" for the EU-27 total. Default "DE".
fuelYesFuel: gas, oil (crude) or coal (solid fossil fuels)
top_nNoHow many suppliers to list (1-30, default 10)
periodNoYear "2024" or, for gas and oil only, month "2025-06". Default: latest published year.
productNoOptional Eurostat energy-product code to narrow within the fuel (e.g. "G3200" for LNG only, "O4600" for oil products).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior4/5

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

Annotations already say readOnlyHint/idempotent/non-destructive, so safety is covered; the description adds real value by naming the data source (Eurostat), disclosing default period behavior and the ranking/share output shape, and calling out that Russia's share is specifically surfaced. It does not mention latency, data freshness limits, or missing-country behavior, but for a read-only lookup that is a minor gap.

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 output shape is front-loaded in the first clause, followed by coverage, default, examples and source — a logical order. It is dense but every sentence carries information; the example-question sentence is the one slightly indulgent element.

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?

With no output schema available, the description carries the burden and does so: it states the return is a ranking of suppliers with each one's share plus Russia's share. Inputs, defaults, valid geographies and the data source are all covered, so an agent has enough to call it 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 description coverage is 100%, so the baseline is 3. The description reinforces defaults ('Annual by default', 'gas and oil also accept a month') and the geo scope, but mostly restates what the schema already documents rather than adding syntax or edge-case meaning.

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

Purpose4/5

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

The definition gives a specific verb and resource ('which countries a country imports gas, oil or coal FROM, ranked, with shares'), which is far more than a restatement of the name. It even disambiguates direction of flow (imports FROM) and scopes to Eurostat data. However, it never names a sibling such as import_dependency_rate, russia_import_trend or energy_mix, so the agent must infer which related tool is better suited.

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?

Scope of valid inputs is clear ('Works for Germany, any EU member, or the EU as a whole'), and the default granularity (annual, latest published year) plus the month exception for gas/oil are stated. Example questions ('where does Germany get its gas') give the agent concrete routing cues. There is no explicit guidance on when NOT to use it or which sibling to pick instead.

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

All Eu Energy Imports 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