mcp-edf

EDF: Compare Periods

edf_compare_periods

Read-only

Compare electricity use between two periods, defaulting to the same dates a year earlier, and get EDF's weather verdict to see whether it was warmer or colder and consumption higher or lower.

Instructions

Electricity used in one period against a reference period (by default the same dates a year earlier), with EDF's weather verdict: whether the period was warmer, similar or colder than the reference, and whether consumption was higher, similar or lower. Use it to ask "did we use more this summer than last, and was it hotter?". The verdict is qualitative and reads temperature only: the kWh are NOT weather-adjusted, and in summer "colder" just means cooler, which lowers a cooling load rather than raising a heating one. Electricity only; EDF answers FLUID_NOT_SUPPORTED for gas, so use edf_compare_years with energy=gas plus edf_get_weather there.

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": {
      "from": "<from>"
    },
    "name": "edf_compare_periods"
  }
}

Input Schema

Name	Required	Description
`to`	No	Last day of the period, inclusive, e.g. 2026-08-31. Defaults to yesterday.
`from`	Yes	First day of the period, inclusive, e.g. 2026-06-01.
`reference_to`	No	Last day of the reference period, inclusive. Defaults to `to` a year earlier.
`reference_from`	No	First day of the reference period. Defaults to `from` a year earlier.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.0Nov 11, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only say readOnlyHint and openWorldHint; the description adds real behavioral context on top - the verdict is qualitative and reads temperature only, the kWh are NOT weather-adjusted, and 'colder' in summer means reduced cooling rather than increased heating. It also discloses the concrete failure mode (FLUID_NOT_SUPPORTED for gas), which an agent could not infer from structured fields.

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 purpose and the qualifier land in the first sentence and the gas fallback closes the description, so it is front-loaded and orderly. It is dense but long, and the summer/'colder' caveat, while useful, is elaborated more than strictly needed.

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?

No output schema exists, and the description compensates by characterizing the return verdict (warmer/similar/colder plus higher/similar/lower) and its qualitative limits. With four fully documented date parameters and clear notes on scope and failure modes, nothing an agent needs in order to call it correctly is missing.

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?

Schema coverage is 100% and the schema already documents every parameter's format and default, so the baseline is 3. The description does add conceptual framing by defining the reference period as by default the same dates a year earlier, which tells the agent what the comparison is semantically before it reads the schema.

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 concrete verb and resource - electricity used in one period versus a reference period - plus the weather verdict that is bundled with it. It also names edf_compare_years as the tool for the gas case, so an agent can separate the two without opening either schema.

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?

Gives an explicit usage scenario ('did we use more this summer than last, and was it hotter?') and an explicit exclusion with the alternative: electricity only, gas must go to edf_compare_years with energy=gas plus edf_get_weather. Both the when and the when-not are stated.

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

Deploy Server