GridLabs provides access to French electricity and energy data, including local electricity consumption information and public datasets. Explore municipal energy indicators and find useful information about electricity in France.
Scored across 8 tools
The consumption, tariff, subscription-funnel, and discovery tools have clearly distinct scopes, and the electricity vs. gas split is explicitly signposted. The three search tools (addresses, cities, RGE companies) lack descriptions entirely, and addresses vs. cities boundaries are somewhat blurry, which leaves minor room for misselection.
All eight tools follow a strict gridlabs_<verb>_<noun> snake_case pattern with a consistent namespace prefix. The get_/search_ verb split maps meaningfully to retrieval-by-key vs. query operations rather than being an inconsistency.
Eight tools is well within the ideal range and each maps to a distinct resource: discovery, two consumption datasets, tariffs, subscription intent, and three search surfaces. No obvious filler or redundancy.
Core read workflows are covered, but get_tariff_scenario reads 'one documented scenario' with no companion tool to enumerate available scenarios, which is a dead end for agents. The three search tools also ship without descriptions, leaving their input/output contracts and coverage unclear.
Returns the API catalog (RFC 9727), OpenAPI JSON, and llms.txt for the site. Also see /.well-known/ai-catalog.json for ARD discovery.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full disclosure burden. It usefully enumerates the three artifacts returned (API catalog, OpenAPI JSON, llms.txt), which is real behavioral value given there is no output schema, but it says nothing about response shape (one blob vs. separate fields), authentication needs, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the primary return content front-loaded. The second sentence is cryptic ('ARD discovery') and arguably dilutes focus, but there is no padding or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must explain what comes back, and it does list the three artifacts. However, for a discovery endpoint the agent still cannot tell how those artifacts are packaged in the response or whether auth/region constraints apply, leaving a meaningful gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline is 4. The description introduces no parameter behavior that could conflict, and nothing about input semantics is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a concrete verb ('Returns') and concrete resources ('API catalog (RFC 9727), OpenAPI JSON, and llms.txt'), which is enough to distinguish it from the sibling grid-data tools. The trailing 'for the site' is slightly vague about scope, and the secondary 'Also see' clause muddies rather than sharpens the core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit statement of when an agent should call this tool versus the sibling search/consumption tools, nor any prerequisites. The 'Also see /.well-known/ai-catalog.json' line gestures at an alternative discovery source but never clarifies whether that is another tool, a raw URL, or a fallback path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Latest publishable residential electricity consumption for one French commune. Annual kWh per delivery point, source and year. No professional data, no geographic fallback, no household estimate. Unavailable is not zero.
| Name | Required | Description | Default |
|---|---|---|---|
| code_insee | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It does disclose meaningful behavior beyond the schema: the data is 'latest publishable' (not historical), annual granularity, per delivery point, and crucially that missing data means 'unavailable', not zero. However, it says nothing about auth, rate limits, coverage gaps for small communes, or failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core purpose, then unit, then exclusions — no filler sentences. The telegraphic fragments ('No professional data, no geographic fallback, no household estimate') are dense but slightly clipped, which costs a point on readability rather than on waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description does the work of explaining the return content (annual kWh per delivery point, plus source and year) and the null-vs-zero semantics, which is the key thing an agent needs. It is only incomplete on input validation and error/coverage edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% — the single parameter code_insee has only a regex pattern (5 digits or 2A/2B prefix) and no prose. The description implies via 'one French commune' that the parameter identifies a commune, which adds some meaning, but it never states that the value must be an INSEE code or what happens with an unknown code.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource and metric: residential electricity consumption for one French commune, measured as annual kWh per delivery point. The word 'electricity' plus 'residential' cleanly separates it from the gas-consumption sibling, and 'one commune' separates it from the city/address search siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-not-to-use conditions: no professional data, no geographic fallback, no household estimate, which tells an agent when this tool will return nothing useful. It stops short of naming the sibling to use instead (e.g. gas consumption or city search), so it lacks the alternative-routing that would earn a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Latest publishable residential gas consumption for one French commune. Annual kWh per delivery point, not household consumption or address eligibility. Returns source and year; unavailable is not zero.
| Name | Required | Description | Default |
|---|---|---|---|
| code_insee | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does substantial work: it discloses the normalization basis ('per delivery point'), provenance ('returns source and year'), freshness ('latest publishable'), and critically the null semantics ('unavailable is not zero'). Auth requirements and rate limits are not mentioned, which is the main residual gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the core capability, followed by the unit caveat and the null-value warning. No filler, and each sentence adds distinct information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description compensates by describing the return payload (source and year) and the null-vs-zero distinction. For a single-parameter read tool this is nearly complete; only error behavior for invalid or uncovered commune codes is left unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the single parameter code_insee is documented only by its name and regex pattern. The description's phrase 'for one French commune' implies the parameter identifies a commune, but it adds no detail on INSEE code format, overseas departments, or what happens on an unknown code — the schema pattern alone carries the format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource and scope: 'Latest publishable residential gas consumption for one French commune', with a clear unit definition ('Annual kWh per delivery point'). It implicitly separates itself from the electricity sibling by naming gas, and explicitly rules out household-level and address-eligibility interpretations, though it never names the sibling tools it is not.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The clause 'not household consumption or address eligibility' functions as an explicit when-not, steering the agent away from address-level tools such as search_addresses. What is missing is a positive routing statement naming the alternative tool to use for household-level or electricity questions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns next_url and funnel metadata for the comparison questionnaire (public, no login).
| Name | Required | Description | Default |
|---|---|---|---|
| city_slug | No | ||
| move_date | No | ||
| housing_type | No | ||
| current_provider | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full disclosure burden. It usefully reveals that access needs no login and that the response includes next_url plus funnel metadata, but it says nothing about whether calling it persists an 'intent', whether it is idempotent, or what rate limits apply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler or repetition. It is efficient, though its brevity contributes to the gaps in purpose and parameter guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description partially offsets the missing output schema by naming the key return field next_url and the funnel metadata. However, for a tool with four undocumented optional parameters and no annotations, it omits too much parameter and usage context to be considered complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across all four parameters (city_slug, move_date, housing_type, current_provider), and the description adds no per-parameter meaning, formats, or accepted values. Only a faint domain hint ('comparison questionnaire') loosely motivates the fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states what the tool returns (next_url and funnel metadata) and the domain (comparison questionnaire), but never plainly states the action the tool performs. A name like get_subscribe_intent implies creating or resolving a subscription intent, while the text describes a questionnaire fetch, leaving the actual operation ambiguous relative to siblings like gridlabs_get_tariff_scenario.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance and no mention of which sibling to pick for adjacent tasks such as tariff scenarios or address search. The only routing signal is the parenthetical '(public, no login)', which speaks to prerequisites rather than tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one documented electricity cost scenario from the same verified source reader as the website. Limited panel, annualized EUR TTC costs, sources and review dates. Not a quote, market-wide ranking or subscription eligibility. No custom profile or bulk export.
| Name | Required | Description | Default |
|---|---|---|---|
| scenario_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses useful behavioral scope: limited panel, annualized EUR TTC figures, included sources and review dates, and that custom profiles/bulk export are unsupported. It says nothing about what happens with an unknown scenario_id, whether results are cached, or what the response shape is (no output schema exists).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads what the tool does, then scope, then exclusions in tight fragments with no filler. The telegraphic style ('Limited panel, annualized EUR TTC costs, sources and review dates') is dense but readable; nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with no annotations and no output schema, the description adequately frames scope, data characteristics and limitations. However, the unexplained enum values and the absence of any return-shape hint leave real gaps an agent must fill by trial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is one required parameter with 0% schema description coverage and an enum of opaque values ('small-base', 'hphc-6', 'hphc-9'). The description explains the general nature of a scenario but never decodes the enum — an agent cannot tell what 'hphc' means or how the sizes relate without guessing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: reading one documented electricity cost scenario, with a provenance note ('same verified source reader as the website'). The resource is clearly distinct from all siblings (consumption, addresses, cities, RGE companies, subscribe intent), though no sibling is named explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives meaningful exclusions — 'Not a quote, market-wide ranking or subscription eligibility' and 'No custom profile or bulk export' — which steers an agent away from misusing it for ranking or eligibility questions. It stops short of naming the alternative tool (e.g. subscribe intent) for those excluded cases, so it is clear context without full routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | ||
| postalCode | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
gridlabs_get_agent_discoverygridlabs_get_commune_electricity_consumptiongridlabs_get_commune_gas_consumptiongridlabs_get_subscribe_intentgridlabs_get_tariff_scenariogridlabs_search_addressesgridlabs_search_citiesgridlabs_search_rge_companies
Add one secure layer between your agents and this server.