What can you do with this server?

This server provides a read-only interface to the AI Price Index, letting you query current and historical AI model API prices locally — no API keys required. * Look up current prices (current_price): Get today's input/output price per million tokens for any supported model (e.g., gpt-4o, claude-opus-4-5, gemini-2.5-pro), along with the source URL. * Look up prices on a specific date (price_on): Retrieve the exact price in effect on any past date (YYYY-MM-DD) — useful for auditing costs or tracking price changes over time. * Compare multiple models side-by-side (compare): Get input/output prices for several models at once, for today or a specific historical date. * Calculate cost from token usage (cost_from_usage): Compute the USD cost from a token rollup (input, output, cache reads/writes) for a given model at a point in time, with built-in cache multipliers. * Discover available models (list_models): List all known model IDs and aliases, optionally filtered by provider (e.g., anthropic, openai, google). All results include cite-ready provenance: source_url, last_validated, confidence, and a CC BY 4.0 attribution string. Short/aliased model IDs are supported and resolve to canonical names.

Which integrations are available for this server?

Provides access to historical and current pricing data for Google AI models, including point-in-time lookups and source attribution. Provides access to historical and current pricing data for OpenAI models, including point-in-time lookups and source attribution.

How do I use ai-price-index-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@ai-price-index-mcp What was the price of gpt-4 on January 1, 2024?" 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.

ai-price-index-mcp

by RoninForge

Overview Schema Source Related Servers Discussions Admin

JavaScript

Local

ai-price-index-mcp

RoninForge ai-price-index-mcp is a read-only Model Context Protocol server that answers what an AI model's API price was on a given date, with the first-party source that proves it. It is MIT licensed, runs entirely on your machine, and requires no API keys.

Part of RoninForge.org, an independent open-source workshop that keeps dated, reproducible records of the AI developer tooling economy. It serves the open AI Price Index dataset to any MCP client, including Claude Code and Cursor.

Most pricing tools tell an agent what a model costs today. This one also answers what a model cost on a given date, and returns the first-party source URL plus the date that price was last validated, so the agent can cite the number. That point-in-time lookup is the differentiator.

Zero keys, zero prompts, zero network at runtime. The dated dataset is bundled inline inside the ai-price-index dependency. The server reads it locally and adds nothing to your traffic.
Read-only. It only looks prices up. It cannot write, configure, or call out.
Cite-ready. Every result carries source_url, last_validated, confidence, and the CC BY 4.0 attribution string.

Install

Requires Node.js 18 or newer. No build step, no API key.

npx -y ai-price-index-mcp

That command runs the stdio server; an MCP client launches it for you using the config below.

Related MCP server: tokenomics

Client configuration

Drop this into your MCP client config. The server speaks stdio.

Claude Code (~/.claude.json or a project .mcp.json), and Cursor (~/.cursor/mcp.json), use the same mcpServers shape:

{
  "mcpServers": {
    "ai-price-index": {
      "command": "npx",
      "args": ["-y", "ai-price-index-mcp"]
    }
  }
}

Or, with Claude Code's CLI:

claude mcp add ai-price-index -- npx -y ai-price-index-mcp

Tools

All tools return structured JSON as text content. Prices are usd_per_mtok (USD per million tokens). Model ids resolve through the dataset's aliases, so short ids work (e.g. claude-opus-4-5 resolves to claude-opus-4-5-20251101).

Tool	Arguments	Returns
`current_price`	`model`, `provider?`	Today's input/output price for a model, with its source.
`price_on`	`model`, `date` (YYYY-MM-DD), `provider?`	The price in effect on that date (the point-in-time lookup).
`compare`	`models[]`, `date?`	Side-by-side input/output prices for several models on one date.
`cost_from_usage`	`model`, `tokens`, `date?`, `provider?`	USD value of a token rollup at a point in time, with cache multipliers.
`list_models`	`provider?`	Known model ids (optionally one provider), each with its aliases.

tokens for cost_from_usage accepts input, output, cache_read, cache_write_5m, cache_write_1h (all optional, missing counts as 0). Cache read is 0.1x input, cache write is 1.25x (5 minute) or 2x (1 hour).

Pass provider (for example openai, anthropic, google) to disambiguate a bare id that exists under more than one vendor.

Example result

price_on with { "model": "gpt-4", "date": "2024-01-01" }:

{
  "query": "gpt-4",
  "provider": "openai",
  "model": "gpt-4",
  "date": "2024-01-01",
  "covered": true,
  "input": {
    "usd_per_mtok": 30,
    "unit": "usd_per_mtok",
    "effective_from": "2023-03-14",
    "effective_to": null,
    "last_validated": "2023-04-15",
    "confidence": "archived",
    "source_url": "https://web.archive.org/web/20230415223802/https://openai.com/pricing"
  },
  "output": { "usd_per_mtok": 60, "...": "..." },
  "provenance": {
    "dataset": "AI Price Index by RoninForge",
    "data_version": "2026-06-17",
    "license": "CC-BY-4.0",
    "attribution": "AI Price Index by RoninForge (https://roninforge.org/data/ai-price-index/), CC BY 4.0",
    "source": "https://roninforge.org/data/ai-price-index/"
  }
}

How it works

This server is a thin wrapper over the ai-price-index npm library, which ships the dated dataset bundled inline. There is no pricing logic, no separate data layer, and no network call here. The data version a result reports is the dataset release that the installed ai-price-index pins to. To move to newer prices, update that dependency.

Data license and attribution

The price data is from the AI Price Index and is licensed CC BY 4.0. When you publish anything derived from it, attribute it:

AI Price Index by RoninForge (https://roninforge.org/data/ai-price-index/), CC BY 4.0.

The code of this server is licensed MIT (see LICENSE). Data and tooling licenses are tracked upstream in the ai-price-index repository.

Available Tools

5 tools

compareCompare modelsA

Side-by-side input/output prices for several model ids on one date (today by default, or pass date as YYYY-MM-DD). Each row resolves independently; unknown ids are reported per row.

ParametersJSON Schema

Name	Required	Description	Default
`models`	Yes	Model ids or aliases to compare, e.g. ["claude-opus-4-8", "gpt-4o", "gemini-2.5-pro"].
`date`	No	Optional date (YYYY-MM-DD). Omit for today.

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations, the description adds key behavioral info: each row resolves independently and unknown IDs are reported per row. It does not explicitly state read-only nature, but it's implied and sufficient.

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?

Two sentences, front-loaded with purpose, no wasted words. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description lacks detail about the return format (e.g., table structure). It covers behavior but not output shape, leaving some incompleteness.

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

Parameters4/5

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

Schema coverage is 100%, so baseline 3. The description adds meaning beyond schema by explaining independent resolution and unknown ID handling for 'models', and 'omit for today' for 'date'.

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 the tool provides side-by-side input/output prices for multiple model IDs on a date, distinguishing it from siblings like 'current_price' (single model) and 'list_models' (listing only).

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?

The description explicitly says it's for comparing several models, implying use when a comparison is needed. It does not explicitly mention alternatives or when not to use, but the context is clear.

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

cost_from_usageCost from token usageA

Value a token rollup in USD at a point in time, using the shared cache multipliers (cache read 0.1x input, cache write 1.25x for 5m / 2x for 1h). tokens accepts input, output, cache_read, cache_write_5m, cache_write_1h. Defaults to today if no date is given.

ParametersJSON Schema

Name	Required	Description
`model`	Yes	Model id or alias to price the usage against.
`tokens`	Yes	Token counts to value. All fields optional and non-negative; missing fields count as 0.
`date`	No	Optional date (YYYY-MM-DD). Omit for today.
`provider`	No	Optional provider slug to disambiguate a bare id.

TDQS

A4/5.0

Behavior3/5

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

With no annotations, the description discloses cache multipliers and date defaults. However, it does not mention potential rate limits, caching behavior, or whether the tool is read-only. The 'shared cache multipliers' hint at internal state but are not fully explained.

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?

The description is two sentences with no wasted words. The key purpose is front-loaded, followed by essential details about token fields and date default.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the nested tokens object and absence of output schema, the description covers token field meaning and date defaults. It could mention the return value format (e.g., a number in USD), but the function name makes it clear.

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

Parameters4/5

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 adds value by listing the specific token fields (input, output, cache_read, etc.) and explaining cache multipliers, which goes beyond the schema's property descriptions.

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 states 'Value a token rollup in USD at a point in time', which is a specific verb and resource. It distinguishes from sibling tools like 'current_price' (which likely prices a single token) and 'price_on' (which may fetch historical prices) by focusing on token rollup valuation with cache multipliers.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use the tool (when you have token counts to value) but does not explicitly guide when not to use it or contrast with siblings. It mentions defaults but lacks exclusion criteria.

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

current_priceCurrent priceA

Today's input and output price per million tokens (usd_per_mtok) for a model id, with the first-party source. Accepts short or aliased ids (e.g. "claude-opus-4-8", "gpt-4o", "gemini-2.5-pro"). Pass provider to disambiguate a bare id shared across vendors.

ParametersJSON Schema

Name	Required	Description	Default
`model`	Yes	Model id or alias, e.g. "claude-opus-4-8" or "gpt-4o".
`provider`	No	Optional provider slug (e.g. "openai", "anthropic") to disambiguate a bare id.

TDQS

A4.4/5.0

Behavior4/5

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

No annotations provided, so the description carries full burden. It discloses that prices are today's and from first-party source, but does not explicitly state read-only behavior or other traits like rate limits.

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?

Two sentences, no redundancy, and the core function is front-loaded. Every word adds value.

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?

Given the tool's simplicity (2 params, no output schema, no annotations), the description fully covers purpose, unit, and parameter usage. Complete for effective selection and invocation.

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?

Schema coverage is 100%, but the description adds meaningful context: model accepts short/aliased ids, provider disambiguates shared bare ids. This goes beyond the schema's minimal descriptions.

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 the tool returns today's input and output price per million tokens for a model id, specifying unit and data source. It distinguishes from sibling tools like 'price_on' by focusing on current prices.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains how to use parameters (accepts aliased ids, provider for disambiguation), but does not specify when to use this tool versus alternatives or when not to use it.

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

list_modelsList modelsA

List the model ids known to the dataset, optionally filtered to one provider, each with its provider and aliases. Use this to discover valid ids for the other tools.

ParametersJSON Schema

Name	Required	Description	Default
`provider`	No	Optional provider slug to filter by, e.g. "anthropic".

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description carries full burden. It discloses the output (model IDs, provider, aliases) and the optional filtering behavior. No side effects or limitations are mentioned, but the tool is simple and read-only.

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?

Two sentences: first states the core functionality, second states its purpose. No wasted words; front-loaded and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple listing tool with one optional parameter and no output schema, the description covers the essential aspects: what it returns, filtering, and how it relates to sibling tools. Slightly vague about 'dataset,' but adequate given the context.

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

Parameters4/5

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

Schema coverage is 100% with a description for 'provider.' The tool description adds context by explaining the effect of the filter and that each result includes provider and aliases, going beyond the schema alone.

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 lists model IDs known to the dataset, optionally filtered by provider, and includes provider and aliases. This distinguishes it from sibling tools like compare, cost_from_usage, current_price, and price_on, which focus on cost or comparison.

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?

Explicitly advises to 'discover valid ids for the other tools,' providing clear context for when to use it. Lacks explicit when-not-to-use or alternatives, but the purpose is well-stated.

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

price_onPrice on a dateA

The input and output price per million tokens that was IN EFFECT on a given date (YYYY-MM-DD), with the source that proves it. This is the point-in-time lookup: use it to value past usage or to see how a price changed over time. covered=false means the date predates the model's recorded coverage.

ParametersJSON Schema

Name	Required	Description
`model`	Yes	Model id or alias, e.g. "gpt-4".
`date`	Yes	The date to price, as YYYY-MM-DD, e.g. "2024-01-01".
`provider`	No	Optional provider slug to disambiguate a bare id.

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description properly explains the function (lookup, no side effects), clarifies the meaning of 'covered=false', and indicates the output includes the price and source. It is transparent about what the tool does without contradictions.

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?

The description is concise (3 sentences) and front-loaded with the core purpose. Each sentence adds essential information: the output, use cases, and the special case of 'covered=false'. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite lacking an output schema, the description explains the key output fields (price per million tokens, source, covered flag). For a simple lookup with 2 required parameters, this is sufficient to understand what the tool returns.

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

Parameters4/5

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

Schema coverage is 100%, baselining at 3. The description adds value by explaining the purpose of 'model' (id or alias), 'date' (YYYY-MM-DD), and 'provider' (disambiguation), and clarifies the meaning of 'covered=false' in the output.

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 the price per million tokens in effect on a given date, specifically for point-in-time lookup to value past usage or see price changes. It distinguishes from siblings like 'current_price' and 'compare' by emphasizing historical lookup and noting the 'covered=false' flag.

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?

The description explicitly advises to use it for 'valuing past usage' or 'seeing how a price changed over time', implying it's not for current prices. Although alternatives are not named, the sibling tools list provides context, making the usage reasonably clear.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

5 tool updatesJun 19, 2026
- First observedcompare
- First observedcost_from_usage
- First observedcurrent_price
- First observedlist_models
- First observedprice_on

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.3/5.0

Scored 2026-06-19 16:16 across 5 tools

Disambiguation5/5

Each tool serves a distinct purpose: compare for side-by-side price comparison, cost_from_usage for token cost calculation, current_price for today's price, list_models for model discovery, and price_on for historical price lookup. There is no functional overlap.

Naming Consistency4/5

Names are all lowercase with underscores for multi-word terms (e.g., cost_from_usage, current_price). While not strictly verb-noun (compare is verb-only, price_on is noun-preposition), the pattern is consistent and readable, with no mixing of conventions.

Tool Count5/5

Five tools is well-scoped for an AI pricing index: listing models, current and historical prices, comparison, and cost estimation. Each tool earns its place without unnecessary redundancy or shortage.

Completeness4/5

The tool set covers the core lifecycle: discovery, current price, historical price, comparison, and cost calculation. A minor gap is the lack of historical cost calculation using past multipliers, but this does not severely impair agent workflows.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

mcp A
com.modelpricewatch
Live LLM API pricing: token prices, comparisons, cheapest-model lookups. No key required.
AI & Machine Learning Research & Data
42
CraloOAuth
ai.cralo
Pay-per-use tool marketplace for AI agents. Search, price-check, and call APIs via MCP.
Agent Orchestration Developer Tools
1
inferenceindexer-mcp A
io.github.DesMartin01
AI inference pricing for agents: live and historical model prices, provider comparison.
AI & Machine Learning Agent Orchestration
101
priceparse
io.github.Larshiensch99
Extract structured pricing tiers and addons from any SaaS pricing page URL. Built for AI agents.
Web Scraping Research & Data
2

Related MCP Servers

azure-pricing-mcp
Cloud Platforms Finance
pimentelleo
A
license
A
quality
B
maintenance
Enables LLMs to query Azure service pricing via the public Azure Retail Prices API, with tools for searching prices, estimating costs, comparing regions, and listing services.
Updated 4 months ago (2026-05-22 20:11 UTC)
5
MIT
tokenomics
AI & Machine Learning Search Developer Tools
tylergibbs1
A
license
Not graded
quality
D
maintenance
Provides live LLM pricing data from OpenRouter, enabling agents to search models, get pricing, estimate costs, and compare models.
Updated 3 months ago (2026-06-26 14:51 UTC)
6 npm
MIT
statlyte
AI & Machine Learning
richardwilkinson9
A
license
Not graded
quality
B
maintenance
Enables assistants to access up-to-date LLM pricing, context windows, and model identifiers, with tools to estimate costs, find cheapest models, and check scheduled price changes.
Updated a month ago (2026-08-14 07:54 UTC)
26 npm
MIT
OptimToken MCPofficial
AI & Machine Learning Cloud Platforms
OptimNow
A
license
Not graded
quality
A
maintenance
Enables AI assistants to fetch live, dated prices for LLM models and cloud compute instances across providers, compare and recommend models, and estimate monthly costs based on workload-specific token shapes and constraints.
Updated 6 days ago (2026-09-10 01:52 UTC)
MIT

ai-price-index-mcp

Install

Client configuration

Tools

Example result

How it works

Data license and attribution

Links

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

OptimToken MCPofficial