Skip to main content
Glama

precios_carburantes

Retrieve fuel prices at gas stations in a Spanish municipality. Input a municipality ID and fuel type to get stations sorted by price from cheapest to most expensive, with details including location and hours.

Instructions

Precios de un carburante en las gasolineras de un municipio.

Usa el ID de municipio que devuelve buscar_municipio. El resultado viene ordenado de más barata a más cara. Las gasolineras que no venden el producto pedido no aparecen en el resultado (se indica cuántas se excluyeron). Los precios se actualizan en la API del MINETUR cada ~30 minutos; la respuesta incluye la fecha de esos precios.

Args: municipio_id: ID de municipio MINETUR (lo da buscar_municipio). producto: nombre del carburante en lenguaje natural. Admite alias como "diesel", "glp", "gasolina 95", "gasolina 98", o el nombre exacto de la API (p. ej. "Gasoleo A"). Por defecto gasolina 95 E5. limite: número máximo de gasolineras a devolver, ordenadas por precio ascendente. Por defecto 20 (algunos municipios grandes, como Madrid capital, tienen más de 240 gasolineras).

Returns: Un diccionario con estado: "ok", "sin_gasolineras", "municipio_invalido", "error_conexion" (no se pudo contactar con la API), "error_respuesta" (la API respondió algo que no es JSON), "limite_invalido" (limite no es un entero >= 1), o "producto_no_reconocido" si producto no se pudo resolver. En estado "ok" incluye fecha, producto, total_excluidas, y gasolineras (lista con rotulo, direccion, localidad, horario, precios de todos los productos que vende esa estación como diccionario producto→precio, y coordenadas). En los demás estados incluye mensaje explicando qué pasó y qué hacer.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limiteNo
productoNogasolina 95 e5
municipio_idYes
Behavior5/5

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

With no annotations, the description fully discloses ordering (ascending price), exclusion of non-selling stations, update frequency (~30 min), and all possible return states (ok, sin_gasolineras, etc.) with explanations.

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 description is well-structured with Args and Returns sections, and purpose is front-loaded. It could be slightly more concise by reducing redundancy in ordering and exclusion details, but overall good.

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?

Despite no output schema, the description details the return structure (states, fields like fecha, producto, gasolineras with subfields) and all error conditions. It fully covers what the tool returns and how to interpret results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, but the description adds extensive detail for each parameter: municipio_id references buscar_municipio, producto lists aliases and default, limite explains max number and default. This adds significant meaning beyond schema titles.

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?

The description clearly states it returns prices of a fuel in gas stations of a municipality, specifying the verb (precios de), resource (carburante), and scope (gasolineras de un municipio). It distinguishes from the sibling tool buscar_municipio by referencing it for the municipality ID.

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?

It explains using the ID from buscar_municipio, defaults, ordering, and exclusion. It does not explicitly state when not to use the tool or list alternatives, but the usage context is well-covered.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/gregoriofraile/gasolineras-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server