Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@gas-prices-today-mcp What's the average gas price in Texas this week vs. a year ago?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Gas prices today for AI assistants. Ask for this week's price per gallon in your state or city and get the U.S. Energy Information Administration (EIA) average for regular, midgrade, premium or diesel, the change from last week, last month and a year ago, and what a fill-up or a trip costs.
This is a Model Context Protocol (MCP) server. It reads the EIA weekly retail gasoline and diesel survey at call time and needs no API key.
Tool | What it returns |
| This week's EIA average retail price per gallon (taxes included) for the US, a region, one of nine surveyed states, one of ten surveyed cities or the region of any other state, with the change from last week, four weeks ago and a year ago. |
| The states, cities and regions EIA prices, ranked from cheapest to most expensive, against the US average. |
| The cost of a fill-up at the area average or your price, and the cost of a trip from miles and miles per gallon. |
Every result has structured JSON, a one-paragraph summary, as_of, source and more (a page on mcpstamp.com). Every tool is marked read-only.
Related MCP server: opinet-mcp
This week's price. EIA publishes new averages every Monday, so a remembered number is stale.
Which places EIA prices itself. It covers the US, five regions with sub-regions, nine states (California, Colorado, Florida, Massachusetts, Minnesota, New York, Ohio, Texas, Washington) and ten cities. For any other state the server says so and returns the EIA region that contains it.
The price a year ago, read from the EIA weekly history file.
Paste this URL. No token, no sign-up.
https://gas-prices-today-mcp.lipmichal.workers.dev/mcpclaude mcp add --transport http gas-prices-today https://gas-prices-today-mcp.lipmichal.workers.dev/mcpClaude Desktop adds remote servers under Settings, Connectors, Add custom connector. Paste the URL above.
Add to ~/.cursor/mcp.json.
{
"mcpServers": {
"gas-prices-today": { "url": "https://gas-prices-today-mcp.lipmichal.workers.dev/mcp" }
}
}Add to .vscode/mcp.json.
{
"servers": {
"gas-prices-today": { "type": "http", "url": "https://gas-prices-today-mcp.lipmichal.workers.dev/mcp" }
}
}The npm package is not published. Build it from this repository with Node 20 or newer.
git clone https://github.com/theluckystrike/gas-prices-today-mcp && cd gas-prices-today-mcp
npm install && npm run build
claude mcp add gas-prices-today -- node $(pwd)/dist/stdio.js"What are gas prices today?"
"How much is a gallon of regular in Texas right now, and what was it a year ago?"
"Which state EIA surveys has the most expensive gas?"
"What is the diesel price in California this week?"
"What will a 300 mile trip cost at 30 miles per gallon?"
Full list with fetch dates in DATA_SOURCES.md.
EIA weekly retail gasoline and diesel prices, the per-area tables for regular, midgrade, premium, all grades and diesel, read at call time.
EIA weekly history pages (LeafHandler) for the price a year ago.
EIA PADD definitions for which states belong to which region.
State, city and regional averages from a retail survey, not the price at your station.
EIA prices nine states and ten cities directly. Other states get their region's average.
Diesel is priced for the US, the regions and California only.
The hosted server caches EIA pages for up to 15 minutes.
More MCP servers that answer questions your assistant cannot answer alone are on mcpstamp.com.
Part of the Zovo MCP collection at https://mcp.zovo.one
Built by theluckystrike.
npm install
npm test # builds, then runs the fixture tests and an offline stdio test
node scripts/stdio-transcript.mjs # live stdio round trip, writes .live/stdio-transcript.jsonlMIT
Ranks the areas EIA prices (states, cities, regions) from cheapest to most expensive for a grade this week, with the US average, the cheapest and the most expensive area.
| Name | Required | Description | Default |
|---|---|---|---|
| grade | No | Default regular. | |
| group | No | Which areas to rank. Default all. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, open-world, idempotent, and non-destructive behavior. The description adds ranking direction, weekly temporal scope, and output highlights (US average, cheapest, most expensive area). It does not describe tie handling or response structure in more detail.
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 definition is a single front-loaded sentence with no filler. It puts the ranking action and scope first, followed by the included summary values.
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?
The tool is low complexity, annotations cover the safety profile, and the schema fully documents parameters. The description also summarizes key return content, though it leaves 'all_grades' behavior implicit and does not fully specify output shape.
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%, with enums and defaults documented for both parameters. The description links grade to 'this week' and maps areas to states/cities/regions, but it does not clarify ambiguous cases such as grade='all_grades'. Baseline 3 is appropriate when the schema already carries parameter meaning.
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 uses a specific verb and resource: it ranks EIA area prices for a grade this week. It also names the scope (states, cities, regions) and headline outputs, making it easy to distinguish from get_gas_prices and estimate_fill_up_cost.
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 comparison purpose is implied by 'Ranks' and the cheapest-to-most-expensive ordering, but there is no explicit when-to-use guidance or routing to sibling tools. It also does not say when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cost of filling a tank (gallons times this week's EIA average for the area, or your price per gallon), and optionally the fuel cost of a trip from miles and miles per gallon, including cents per mile.
| Name | Required | Description | Default |
|---|---|---|---|
| area | No | US, a state name or code ("Texas", "CA"), a city EIA prices ("Chicago", "NYC"), or an EIA region ("Midwest", "PADD 2"). Default US. A state EIA does not price is answered with its region. | |
| grade | No | Default regular. | |
| miles | No | Trip distance in miles. Give with miles_per_gallon. | |
| gallons | Yes | Gallons to buy, for example 15. | |
| miles_per_gallon | No | Your vehicle fuel economy. Give with miles. | |
| price_per_gallon | No | Your own price per gallon. Default the EIA average for the area. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds real substance beyond them: it discloses the data source (this week's EIA average for the area) and the output semantics (cost, and cents per mile). It does not disclose the fallback behavior for states without EIA pricing, which is a minor gap.
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?
A single dense sentence with the primary tank-fill purpose front-loaded before the optional trip extension. It is slightly run-on with nested parentheticals, but every clause carries information and nothing is padded.
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?
With no output schema, the description must hint at return values, and it does so by naming the cost and cents-per-mile outputs. Six parameters with full schema coverage are already explained in the schema, and the annotations cover the safety and world-access profile, so nothing material is missing.
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 description coverage is 100% and each parameter already documents defaults, ranges and pairing constraints, so the schema carries the load. The description reinforces the area-price versus custom price_per_gallon choice and the miles/miles_per_gallon pairing but adds no new format or edge-case guidance. Baseline 3 is appropriate.
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 names a specific computation (tank fill cost) and its formula components (gallons times this week's EIA average, or your price per gallon), plus the optional trip-cost extension with cents per mile. It does not distinguish itself from the sibling price-lookup tools, so it falls short of a 5.
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?
Usage is only implied: an agent can infer this is the calculator rather than the price fetchers, since siblings compare_gas_prices and get_gas_prices are named in the tool list but never referenced here. There is no explicit when-to-use, when-not-to-use, or routing statement, and no mention that trip cost requires miles together with miles per gallon beyond what the schema already says.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Latest EIA weekly average retail price per gallon (taxes included) of regular, midgrade or premium gasoline, all grades or diesel for the US, an EIA region, one of nine surveyed states, one of ten surveyed cities, or the region of any other state, read at call time from eia.gov: price, change from last week and four weeks ago, the price a year ago, the last six survey weeks and the next release date.
| Name | Required | Description | Default |
|---|---|---|---|
| area | No | US, a state name or code ("Texas", "CA"), a city EIA prices ("Chicago", "NYC"), or an EIA region ("Midwest", "PADD 2"). Default US. A state EIA does not price is answered with its region. | |
| grade | No | Default regular. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, open-world behavior, and the description adds meaningful context beyond that: the source is eia.gov, values are read fresh at call time, prices are weekly averages with taxes included, and the exact return fields (change vs. last week/four weeks/year ago, six survey weeks, next release date) are disclosed despite there being no output schema.
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?
It front-loads the resource and scope with no filler, and every clause carries information. However, all of it is crammed into one very long run-on sentence, which hurts parseability for a reader skimming for a decision.
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 two-parameter read tool with no output schema, the description is unusually complete: it covers data source, freshness, scope of areas and grades, and the full shape of the response. The only real omission is any guidance tying it to its sibling tools.
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 both parameters are already fully documented, including the area fallback rule. The description adds only incidental color (taxes included, nine surveyed states, ten surveyed cities) and otherwise restates the area and grade options the schema already carries.
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 names a specific verb+resource (retrieve the latest EIA weekly average retail gasoline price) and enumerates exactly what data points come back. It implicitly separates itself from compare_gas_prices and estimate_fill_up_cost by being the raw single-area lookup, but never names or contrasts them.
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?
Usage is only implied: an agent can infer this is the plain price lookup while the siblings handle comparisons and cost math. There is no explicit when-to-use, when-not-to-use, or alternative routing statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0compare_gas_pricesestimate_fill_up_costget_gas_pricesScored across 3 tools
Each tool has a clearly distinct job: get_gas_prices fetches a single area/grade reading, compare_gas_prices ranks many areas against each other, and estimate_fill_up_cost performs a cost calculation. There is no overlap in intent, and the descriptions make the boundaries explicit (e.g., ranking vs. single lookup).
All three names follow a consistent snake_case verb_noun pattern (get_, compare_, estimate_ + domain object). The verbs are distinct but stylistically uniform, so the convention is predictable.
Three tools is a well-scoped surface for a focused gas-price data server: retrieve, compare, and apply to a cost estimate. Each tool earns its place with no filler or redundancy.
The read-only domain is well covered: current price with weekly/yearly deltas and history, cross-area ranking, and downstream cost math. The one minor gap is there is no way to enumerate valid area names (nine surveyed states, ten cities, regions), so an agent must guess accepted inputs.
Energy data from EIA: electricity, fuel prices, and renewables
Live US diesel prices and optimized stop-by-stop fuel plans for trucking. Free snapshot tool.
Gas and fuel prices by station and area, as structured data via a hosted MCP server.
Real-time fuel prices, alerts, and cheapest gas stations across 38+ countries.
