Skip to main content
Glama

Open data: clinical trials, EU tenders, companies, fuel prices

EU Fuel Price Change Monitor (France, Spain)

eu-fuel-monitor
Read-onlyIdempotent

Each run returns only the stations whose fuel prices changed since the last run, from the French and Spanish open government feeds, filtered by postcode prefix. Read from donnees.roulez-eco.fr, sedeaplicaciones.minetur.gob.es when called. Each result: country, station_id, postcode, address, city, lat, lon, diesel_eur_l, sp95_e5_eur_l, e10_eur_l, sp98_eur_l. Needs a RapidAPI key for this API (https://rapidapi.com/IanGregory/api/clinical-trials-eu-tenders-open-data-api), sent as the X-RapidAPI-Key header; the free plan has 50 requests a month.

Input Schema

NameRequiredDescriptionDefault
limitNoAt most this many results (default 100).
countryNoWhich national feeds to read (empty: all). Example: ["FR", "ES"].
postcodeNoKeep stations whose postcode starts with this (28 is Madrid in Spain, Eure-et-Loir in France; 75 Paris; empty keeps all). Example: "28".

Output Schema

NameRequiredDescriptionDefault
countYeshow many results came back
itemsYesthe results, one object each
partialNosome of the source's requests failed: the results are incomplete
productNo
sourcesNowhere the data came from: each source's name, licence and the attribution to show with it
fetched_atNowhen the source was read (Unix seconds)
truncated_fromNothe answer was cut to fit: this many results came back in all

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedOutput schema / properties / sources
      Added value: +{
      +  "description": "where the data came from: each source's name, licence and the attribution to show with it",
      +  "items": {
      +    "type": "object"
      +  },
      +  "type": "array"
      +}
  2. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "properties": {
      +    "count": {
      +      "description": "how many results came back",
      +      "type": "integer"
      +    },
      +    "fetched_at": {
      +      "description": "when the source was read (Unix seconds)",
      +      "type": "integer"
      +    },
      +    "items": {
      +      "description": "the results, one object each",
      +      "items": {
      +        "properties": {
      +          "address": {
      +            "description": "address (text)"
      +          },
      +          "city": {
      +            "description": "city (text)"
      +          },
      +          "country": {
      +            "description": "country (country)"
      +          },
      +          "diesel_eur_l": {
      +            "description": "diesel_eur_l (price)"
      +          },
      +          "e10_eur_l": {
      +            "description": "e10_eur_l (price)"
      +          },
      +          "lat": {
      +            "description": "lat (lat)"
      +          },
      +          "lon": {
      +            "description": "lon (lon)"
      +          },
      +          "postcode": {
      +            "description": "postcode (id)"
      +          },
      +          "sp95_e5_eur_l": {
      +            "description": "sp95_e5_eur_l (price)"
      +          },
      +          "sp98_eur_l": {
      +            "description": "sp98_eur_l (price)"
      +          },
      +          "station_id": {
      +            "description": "station_id (id)"
      +          }
      +        },
      +        "type": "object"
      +      },
      +      "type": "array"
      +    },
      +    "partial": {
      +      "description": "some of the source's requests failed: the results are incomplete",
      +      "type": "boolean"
      +    },
      +    "product": {
      +      "type": "string"
      +    },
      +    "truncated_from": {
      +      "description": "the answer was cut to fit: this many results came back in all",
      +      "type": "integer"
      +    }
      +  },
      +  "required": [
      +    "count",
      +    "items"
      +  ],
      +  "type": "object"
      +}
  3. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true and destructiveHint=false, so the low-risk read profile is covered structurally. The description adds valuable non-schema behavior: live reads from two external government feeds, cross-run statefulness (only changed stations are returned), and an authentication requirement with a concrete rate limit. The RapidAPI URL given actually points at a 'clinical-trials-eu-tenders-open-data-api' listing, which is inconsistent with this tool and could mislead an agent setting up credentials.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core behavior (delta results from two national feeds) and then layered with return fields, sources, and auth requirements. Three dense sentences with no filler; the only wasted content is the mismatched RapidAPI link.

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?

An output schema exists, yet the description also enumerates the returned fields, which is redundant but harmless. Sources, auth, rate limit, and delta semantics make it complete for correct invocation. The only real defect is the RapidAPI URL naming a different API, which leaves credential setup ambiguous.

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%: limit bounds and default, country enum values and empty-means-all semantics, and postcode prefix behavior are all documented in the schema. The description only restates the postcode-prefix filter. Baseline 3 is appropriate since the schema carries the parameter meaning.

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 (returns fuel stations whose prices changed), scoped to French and Spanish open government feeds and postcode-prefix filtering. It also names the upstream data sources (donnees.roulez-eco.fr, sedeaplicaciones.minetur.gob.es), so the agent knows exactly what is being read and no sibling tool overlaps this domain.

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?

The key usage context is explicit: results are delta-based ('changed since the last run') and filtered by postcode prefix, so an agent knows repeated polling is the intended pattern. Operational constraints (RapidAPI key via X-RapidAPI-Key header, 50 requests/month on the free plan) are stated. It stops short of explicit when-not-to-use or alternative-tool guidance, but no sibling is a plausible substitute.

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