Skip to main content
Glama
Sign In
mcp-edf

mcp-edf

by mgcrea
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

EDF: Contracts

edf_get_contracts
Read-only

Retrieve EDF electricity and gas contract details, including current tariff option, subscribed power, off-peak hours, and version history, so you can identify the active tariff before analyzing costs.

Instructions

The home's EDF contracts. Electricity: the tariff option (BASE, HPHC for peak/off-peak, TEMPO…), the subscribed power in kVA and EDF's tariff code, as a history of versions, since EDF writes a new one at every price or option change; current is the one in force. For options with off-peak hours, the meter's calendar (e.g. "HC 01:30-07:00"). Gas: tariff code, consumption option and price zone, or null with no gas contract. Call it to learn the option before reading costs by tariff heading.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "edf_get_contracts"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint, so the burden is lower; the description still adds real semantics: a new version is written at every price or option change, `current` is the one in force, gas is null when there is no gas contract, and the meter calendar accompanies off-peak options. It does not discuss response size or whether history is paginated, which is the only notable omission.

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 one-line purpose, then structured by energy type (Electricity / Gas) and closed with a usage pointer. Dense but nearly every clause carries information; the trailing 'tariff heading' phrase is slightly jargon-y but still informative.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the full burden of describing the return shape, and it does so by listing the fields per energy type plus the null case. It stops short of field names and nesting layout, so an agent knows what to expect conceptually but not the exact payload structure.

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?

The tool takes zero parameters, so there is nothing to disambiguate; the baseline applies and the description correctly spends no words on arguments.

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?

Names the exact resource (the home's EDF contracts) and enumerates the content returned: tariff option, subscribed power in kVA, EDF tariff code, version history with `current` marked, off-peak calendar, and gas tariff/option/zone. This is unmistakably distinct from the consumption, load-curve, and max-power siblings.

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?

Gives a concrete use condition: call it to learn the tariff option before reading costs by tariff heading, which implies correct ordering relative to the cost/usage tools. It stops short of naming an alternative tool or stating when not to call it.

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

Deploy Server

Other Tools