Skip to main content
Glama

foncier_conso_elec

Annual electricity consumption of French sites (open data, no key).

TWO GRID TIERS, and they are not interchangeable. reseau="distribution" (default) reads Enedis: consumption per ADDRESS, with the NAF division. reseau="transport" reads ODRE (RTE): the sites connected to the transmission grid, which are ABSENT from Enedis entirely — and they are the largest consumers in the country. Saint-Jean-de-Maurienne (73248) returns zero NAF-24 address on Enedis and 1,702,616 MWh on ODRE for 2023 — one IRIS (732480104) holding 3 delivery points, so that row comes back marked maille="iris_agrege", not as a single site. A "heavy electricity user" list built on distribution alone is a list without the heavy users: use reseau="les_deux" for a real one.

⚠️ THE TRANSPORT TIER IS A YEAR BEHIND. ODRE's newest millésime is older than Enedis's (2023 against 2024, measured 2026-09-09). Asking ODRE for a year it does not carry returns ZERO rows for the whole tier — which reads exactly like "no transmission-connected site here" while it means "that year does not exist yet". That zero is now NAMED in avertissement_millesime: read it before concluding. Nothing is invented to fill the hole — an absent year stays absent, it is only said out loud.

TWO GRAINS, and maille governs BOTH tiers with the same meaning: "site" = one row is one site. On DISTRIBUTION, Enedis publishes ONE ROW PER ADDRESS AND PER NAF DIVISION, so maille="ligne" (default) returns rows, and thresholding them one by one MISSES sites whose divisions are each below the bar but whose total is above it; maille="site" sums an address's divisions and applies min_mwh AFTER the sum — the grain almost every caller means. A site then carries naf2_principal, naf2_detail and multi_naf2. On TRANSPORT, "site" keeps only the IRIS that hold a single delivery point, and "ligne" also returns the aggregated ones. Filtering those out is how a query for the largest consumers returns the small ones — see maille below.

Rows Enedis publishes without an address are real consumption that cannot be located: they are never returned as sites, and counted in lignes_ignorees / mwh_ignores instead of being silently dropped.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "annee": "<annee>"
    },
    "name": "foncier_conso_elec"
  }
}

Input Schema

NameRequiredDescriptionDefault
_orgNoOrg (id) de CET APPEL. `oto_list_orgs()`.
deptNoINSEE department code (e.g. "59").
naf2NoNAF divisions, two digits (e.g. ["24", "23", "86"]) — the grain Enedis actually publishes in. Ignored on the transport tier, which carries no NAF.
anneeYesreference year (e.g. "2024"). ODRE lags a year behind Enedis, so the year that fits distribution may return nothing at all on transport — `avertissement_millesime` says so rather than letting it pass for empty.
limitNomax rows per tier (default 200); `limit=-1` means NO ceiling, and `total` is the number of rows RETURNED, not the population — it saturates on `limit`, and says so in `tronque` / `avertissement_troncature` when it does. ⚠️ **`limit` caps the rows READ, upstream of `min_mwh`** — the threshold is applied AFTER reading, so a capped read thresholds only what it happened to read. With `min_mwh` set, `total` is therefore a FLOOR, never a count: measured on one department, `limit=60` answered `total: 2` where `limit=-1` answers 61. **Pass `limit=-1` whenever you pass `min_mwh`**, or read `total` as "at least".
_groupNoÉquipe (id) de CET APPEL, sous son org parente.
mailleNo"ligne" (as published, default) or "site" (one row = one site). On DISTRIBUTION, "site" sums an address's NAF divisions. On TRANSPORT, "site" keeps only the IRIS holding a SINGLE delivery point; "ligne" also returns the aggregated IRIS, each marked `maille="iris_agrege"`. Those aggregates carry 59 % of the transmission tier (2023 national: 55.3 TWh over 931 rows, of which 22.9 TWh over the 729 single-site ones), and the biggest consumer in France is one of them — filtering them out is how a "largest consumers" query returns the small ones.ligne
reseauNowhich grid tier(s) to read.distribution
_run_idNoOBLIGATOIRE à chaque appel dès `run_start` ou `data_claim_next` : sans lui, l'écriture sur une ligne réservée est refusée. Hérité seulement si le serveur tient un run actif — n'y compte pas.
max_mwhNo
min_mwhNo
secteurNo"INDUSTRIE" | "TERTIAIRE" | "AGRICULTURE" — coarse: a hospital and an office tower are both TERTIAIRE. Prefer `naf2`.
_projectNoProjet (id) de CET APPEL — jeton PRIMAIRE. `oto_project(op='list')`.
_instanceNoInstance de connecteur PRÉCISE (un credential exact). `oto_instance(op='list')`.
code_epciNo
code_communeNo

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.8/5.0
Behavior5/5

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

No annotations exist, so the description carries the full burden and does so: it discloses that ODRE lags a year and that an absent year returns ZERO rows rather than an error, that the zero is signalled in `avertissement_millesime`, that `limit` caps rows upstream of `min_mwh` making `total` a floor, and that address-less rows are counted in `lignes_ignorees`/`mwh_ignores` instead of dropped. This is exactly the non-obvious behavior an agent could not infer.

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 the tier distinction, then grain, then the truncation trap — a sensible order. It is long (~450 words) and a few passages are rhetorical rather than informative ('a list without the heavy users', 'only said out loud'), but nearly every sentence carries an operational fact.

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 16-parameter tool with no annotations and no output schema, the description covers the decision-critical parameters, names key response fields (`avertissement_millesime`, `tronque`, `total`, `naf2_principal`/`naf2_detail`/`multi_naf2`, `lignes_ignorees`) and the Saint-Jean-de-Maurienne numeric example grounds the abstract tiers in a checkable case.

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?

Adds real meaning beyond the schema for `reseau`, `maille`, `naf2` (ignored on transport), `annee` (ODRE lag) and `limit` (read cap, not result cap), with a concrete measured example of the `limit=60` vs `limit=-1` discrepancy. Left undocumented in both schema and description: `max_mwh`, `code_epci`, `code_commune`.

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+scope: 'Annual electricity consumption of French sites (open data, no key)'. It immediately distinguishes the two underlying sources (Enedis distribution vs ODRE transport) and which one is the default, so an agent knows exactly what dataset it is hitting.

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

Usage Guidelines5/5

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

Explicit when-to-use rules throughout: `reseau="les_deux"` is required for a real 'heavy consumer' list, `maille="site"` is 'the grain almost every caller means', and 'Pass `limit=-1` whenever you pass `min_mwh`' is a direct operational rule. It also names the failure mode of each wrong choice rather than just describing the option.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources