Real-time fuel prices, active alerts (traffic, wildfires, severe weather, earthquakes), per-country data coverage, and cheapest gas stations by city, aggregated from official public sources across 38+ countries. Read-only, no auth required for the free tier.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.3/5 across 4 of 4 tools scored.
Each tool has a distinct purpose: alerts, city fuel stations, country coverage, and national fuel prices. Even the two fuel-related tools differ in granularity and data type, preventing confusion.
All tools follow a consistent `ekopump_get_` prefix with snake_case noun phrases, making their function predictable and uniform across the set.
Four tools is an appropriate, focused size for this server, covering fuel prices, station-level prices, alerts, and coverage information without unnecessary bloat.
The set covers fuel prices at both national and station levels, alerts, and coverage metadata. However, it lacks retrieval tools for other data types mentioned in coverage (e.g., transit, flights) and the alerts tool cannot filter by country or type, which are minor but notable gaps.
ekopump_get_active_alertsAlertas activas (tráfico, incendios, meteo, sismos)ADevuelve las alertas actualmente activas que EkoPump agrega de múltiples fuentes oficiales: tráfico DGT (España), incendios (EONET/EFFIS), meteorología severa (MeteoAlarm, National Weather Service), sismos y otras. Incluye desglose por fuente y severidad además de una muestra de alertas individuales.
Args:
limit (number, opcional, 1-50, por defecto 15): cuántas alertas individuales devolver. El desglose por fuente/severidad siempre refleja el total real, no solo la muestra.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Número máximo de alertas individuales a devolver (1-50, por defecto 15). El resumen por fuente y severidad siempre incluye el total real. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive behavior. The description adds context about aggregation from multiple sources, the breakdown by source/severity, and importantly clarifies that the limit parameter only affects the sample while the breakdown reflects the real total. This goes beyond annotations without contradicting them.
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?
The description is concise, with the main purpose in the first sentence and a clear, bulleted argument explanation. It front-loads the key information and avoids unnecessary filler.
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 simple read-only tool with one parameter and no output schema, the description adequately explains what is returned (aggregated alerts with breakdown and sample) and how the parameter affects the response. It lacks only minor details like data freshness, but overall is complete enough for an agent to invoke correctly.
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 schema has 100% coverage for the single 'limit' parameter, including its range, default, and the note about the summary reflecting the real total. The description repeats this information without adding new semantic detail, so it earns the baseline score for high schema coverage.
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 clearly states the verb 'Devuelve' (returns) and the resource 'alertas actualmente activas' aggregated from multiple official sources, listing specific categories (traffic, fires, weather, earthquakes). This distinguishes it from sibling tools about stations, coverage, and fuel prices.
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 description makes it clear this tool is for retrieving active alerts from official sources, which is a distinct use case from the sibling tools. However, it does not explicitly state when to use this tool over alternatives or provide exclusion criteria, though none are needed given the domain separation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ekopump_get_city_stationsGasolineras más baratas en una ciudadADevuelve las gasolineras con mejor precio en una ciudad concreta cubierta por EkoPump, ordenadas de más barata a más cara, con precio de gasolina y diésel por estación.
Args:
city (string, requerido): nombre o slug de la ciudad (ej. "Madrid", "paris"). Debe ser una de las ciudades cubiertas por EkoPump — si no se reconoce, el error incluye ejemplos válidos.
limit (number, opcional, 1-25, por defecto 10): cuántas estaciones devolver.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | Nombre o slug de una ciudad cubierta por EkoPump (ej. "Madrid", "paris", "san-sebastian"). Ciudades disponibles: Madrid, Barcelona, Valencia, Sevilla, Bilbao, Zaragoza, Málaga, Alicante, Murcia, Palma, Valladolid, Córdoba, Granada, Santander, San Sebastián, y más. | |
| limit | No | Número máximo de estaciones a devolver, ordenadas de más barata a más cara (1-25, por defecto 10). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds useful behavioral details: results are ordered from cheapest to most expensive, each station includes gasoline and diesel prices, and unrecognized cities produce errors with valid examples. This goes beyond the annotation baseline without contradicting it.
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?
The description is concise and front-loaded: the first sentence captures the core functionality, and the Args section is compact. Every sentence adds meaningful information, with no filler or repetition beyond a reasonable inline parameter summary.
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 simple read-only query tool with two parameters and no output schema, the description is fully adequate. It explains input constraints, output ordering, fuel types returned, and error behavior. The lack of an output schema is compensated by the explicit statement of what is returned.
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 coverage is 100%, so baseline is 3. The description enhances this by giving concrete examples for city ('Madrid', 'paris'), explaining the slug/name flexibility, and noting that errors include valid city examples. For limit, it restates the default and range but adds no new semantics, so the extra value comes primarily from the city parameter context.
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 clearly states the tool returns cheapest gas stations in a specific EkoPump-covered city, sorted by price, with gasoline and diesel prices. This distinguishes it from siblings like get_fuel_prices (broader fuel pricing) and get_active_alerts (alerts). The verb 'Devuelve' and specific resource 'gasolineras... en una ciudad concreta' make the purpose unambiguous.
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 description implies when to use it (for city-specific cheap station lookups) and gives constraints (city must be EkoPump-covered, limit 1-25). However, it does not explicitly compare with sibling tools or state when not to use it. The usage context is clear but exclusions and alternatives are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ekopump_get_country_coverageQué datos cubre EkoPump en cada paísADevuelve qué tipos de datos en vivo tiene EkoPump para un país (o para todos): combustible, transporte público, vehículos en vivo, bicis públicas, cargadores EV, alertas locales, vuelos y barcos. Útil para responder "¿EkoPump tiene datos de X país?" o "¿qué cubre EkoPump en Portugal?".
Args:
country (string, opcional): código ISO 3166-1 alpha-2 (ej. "PT"). Si se omite, devuelve un resumen agregado de todos los países con al menos un dato en vivo.
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | Código de país ISO 3166-1 alpha-2. Si se omite, se devuelve un resumen agregado de todos los países. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive. The description adds valuable context about the optional country parameter and the fallback to an aggregate report when omitted, plus the list of covered data types. No contradiction with annotations.
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?
The description is brief and front-loaded, with the core purpose in the first sentence, example queries in the second, and a compact Args section. Every sentence contributes meaning with no 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?
For a simple read-only tool with one optional parameter and no output schema, the description covers the essential behavior, including the parameter's effect and the returned data categories. The sibling context makes its role clear, so no additional detail is needed.
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 schema fully describes the country parameter (ISO code, optional, aggregate if omitted) with 100% coverage. The description's Args section essentially repeats the schema, adding no new semantic information beyond what the schema provides.
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 clearly states the tool returns the types of live data EkoPump has for a country or all countries, with a specific list of data categories (fuel, transit, vehicles, etc.). This distinguishes it from siblings that focus on specific data types like alerts or fuel prices.
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?
Explicit use cases are provided: answering whether EkoPump has data for a country or what coverage exists in a specific country. It does not mention alternatives or exclusions, but the context is clear enough for an agent to know when to select this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ekopump_get_fuel_pricesPrecios de combustible + BrentADevuelve el precio medio nacional de gasolina (G95), G98 y diésel por país, junto con el precio del petróleo Brent, agregados a partir de fuentes oficiales por EkoPump (ekopump.es). Datos de solo lectura, sin autenticación.
Args:
country (string, opcional): código ISO 3166-1 alpha-2 (ej. "ES"). Si se omite, devuelve todos los países disponibles.
Devuelve precios en euros por litro, salvo que la fuente original use otra moneda ya convertida por EkoPump.
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | Código de país ISO 3166-1 alpha-2 (ej. 'ES', 'FR', 'DE'). Si se omite, se devuelven todos los países con datos de precio disponibles. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly and idempotent; the description adds that no authentication is needed and explains a currency conversion nuance. This provides useful behavioral context beyond the annotations, though it omits details like rate limits or data refresh, which are acceptable given the low bar set by annotations.
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?
The description is compact and well-organized: a clear purpose statement followed by a short args list. It front-loads the key content and avoids any unnecessary wording.
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 simple read-only tool with one optional parameter and no output schema, the description explains the data source, price units (euros per liter), and currency conversion behavior. It does not detail the exact response format, but that is not critical for straightforward data retrieval.
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 input schema fully documents the 'country' parameter (ISO code, optional, omission returns all), and the description repeats this with an example. Since schema coverage is 100%, the description adds no new parameter semantics, so the baseline score of 3 applies.
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 clearly states the tool returns national average fuel prices for gasoline (G95, G98) and diesel by country plus Brent oil price, using the verb 'Devuelve' and identifying the resource. This distinguishes it from sibling tools (alerts, city stations, coverage).
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 description provides context on usage: it aggregates official sources and allows optional country filtering. It does not explicitly discuss alternatives or when not to use it, but the focused scope on fuel prices gives sufficient guidance for correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
