Fuel MCP

Context

Most fuel-price apps provide fixed filters, but many user questions are inherently multi-step: nearest stations, specific fuel type, historical trend, and best option under constraints. Fuel MCP was built to move from rigid UI workflows to an intent-first conversational layer on top of an existing public API.

What I built

A production-style MCP server around precioil.es, exposing a focused toolset that an LLM can call safely and repeatedly:

• nearby stations by radius and by municipality/province
• station detail and station price history retrieval
• daily average prices (national and province-level)
• helper tools to enumerate provinces and municipalities for follow-up calls

Technical approach

I implemented the server in Python using FastMCP and HTTPX, with explicit tool contracts so models can plan reliable call sequences. Each tool wraps a concrete API endpoint and returns structured responses suitable for chained reasoning. The runtime supports both STDIO (local MCP clients) and streamable HTTP transport (networked deployments), with logging and error handling to keep failures observable and debuggable.

Outcome

Fuel MCP demonstrates how existing REST capabilities can be converted into conversational infrastructure without replacing the underlying backend. The result is a reusable MCP integration pattern: expose narrowly scoped tools, keep contracts stable, and let LLMs orchestrate complex fuel-price queries on top of live public data.