Skip to main content
Glama

Tankerkoenig Stations Nearby

tankerkoenig_stations_nearby
Read-onlyIdempotent

German gas station fuel prices near a location — Benzinpreise Germany, real-time from the official MTS-K feed. Find the cheapest diesel, E5, or E10 near a point in Germany with price in EUR per liter, brand, address, distance, and open status. Coordinates are required: geocode a German city or address first (e.g. via a geocoding tool) — Berlin is lat 52.52, lng 13.40. Data covers Germany only. Example: tankerkoenig_stations_nearby({ latitude: 52.52, longitude: 13.40, radius_km: 5, fuel: "diesel", sort: "price" })

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fuelNoFuel type: "e5" (Super 95), "e10" (Super E10), "diesel", or "all" for all three prices per station (default "all")
sortNoSort order: "distance" (default) or "price" (cheapest first). Sorting by price requires a single fuel type (e5, e10, or diesel), the API rejects sort by price when fuel is "all"
_apiKeyNoOptional: your own free Tankerkoenig API key (creativecommons.tankerkoenig.de)
latitudeYesLatitude of the search center (Germany), e.g. 52.52 for Berlin
longitudeYesLongitude of the search center (Germany), e.g. 13.40 for Berlin
open_onlyNoReturn only stations that are currently open (default false)
radius_kmNoSearch radius in kilometers (default 5, maximum 25 — larger values are clamped)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / examples
      Previous value: -[
      -  {
      -    "_apiKey": "your-tankerkoenig-api-key",
      -    "fuel": "diesel",
      -    "latitude": 52.52,
      -    "longitude": 13.4,
      -    "radius_km": 5,
      -    "sort": "price"
      -  },
      -  {
      -    "_apiKey": "your-tankerkoenig-api-key",
      -    "fuel": "e5",
      -    "latitude": 48.13,
      -    "longitude": 11.58,
      -    "open_only": true,
      -    "radius_km": 10,
      -    "sort": "distance"
      -  }
      -]New value: +[
      +  {
      +    "fuel": "diesel",
      +    "latitude": 52.52,
      +    "longitude": 13.4,
      +    "radius_km": 5,
      +    "sort": "price"
      +  },
      +  {
      +    "fuel": "e5",
      +    "latitude": 48.13,
      +    "longitude": 11.58,
      +    "open_only": true,
      +    "radius_km": 10,
      +    "sort": "distance"
      +  }
      +]
  2. Changed1 schema field changed
    • addedInput schema / examples
      Added value: +[
      +  {
      +    "_apiKey": "your-tankerkoenig-api-key",
      +    "fuel": "diesel",
      +    "latitude": 52.52,
      +    "longitude": 13.4,
      +    "radius_km": 5,
      +    "sort": "price"
      +  },
      +  {
      +    "_apiKey": "your-tankerkoenig-api-key",
      +    "fuel": "e5",
      +    "latitude": 48.13,
      +    "longitude": 11.58,
      +    "open_only": true,
      +    "radius_km": 10,
      +    "sort": "distance"
      +  }
      +]
  3. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already establish the safe read-only, idempotent profile, and the description adds real value on top: the MTS-K feed as the authoritative source, real-time freshness, EUR-per-liter units, and the geographic limitation. It does not, however, mention rate limits or what the optional _apiKey enables, leaving some operational context unstated.

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 purpose, then prerequisites, coverage, and a call example; each sentence carries distinct information with no filler. Dense but efficiently packaged for an agent.

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?

With no output schema, the description compensates by enumerating the returned fields (price, brand, address, distance, open status) and the units. Combined with a complete input schema and the requirement/prerequisite guidance, an agent has everything needed to invoke it correctly.

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 coverage is 100% and the schema descriptions are already thorough (enum meanings, default values, the price-sort restriction when fuel is 'all', radius clamping). The worked example duplicates the one already present in the schema's examples array, so the description adds little semantic detail beyond the structured fields — baseline 3 is appropriate.

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 and resource — real-time German gas station fuel prices near a location — and names the concrete data returned (price per liter, brand, address, distance, open status). It also implicitly distinguishes itself from the sibling lookups (tankerkoenig_prices, tankerkoenig_station_details) by being proximity-centric.

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?

Clearly states the coordinate requirement, the 'geocode a German city or address first' prerequisite, and the Germany-only constraint, with a concrete Berlin coordinate example. It stops short of explicitly routing the agent away from the sibling tools (e.g. when to use station_details or prices instead), so it is not quite the full when/when-not/alternatives.

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.