Tokencost Dev

What tokencost-dev MCP server does

The tokencost-dev MCP server exposes model economics and metadata as tools that an MCP-compatible assistant can call. It connects to the LiteLLM community registry for pricing data and provides information such as input and output rates, context-window limits, and supported capabilities.

The main lookup tool accepts flexible model names. An assistant can request details using a shortened name such as sonnet 4.5 instead of a full provider model identifier. Returned details can include the provider, operating mode, pricing per million tokens, maximum input and output sizes, and capabilities such as vision or function calling.

How it works

At startup and during normal use, pricing data is obtained from the LiteLLM registry and cached locally. The cache is refreshed automatically every 24 hours. A separate refresh tool lets an assistant request a new fetch instead of waiting for the automatic update interval.

Cost calculations use the selected model’s input and output rates together with the token counts supplied by the user or agent. The result separates input cost, output cost, and the combined estimate. Model comparisons can filter candidates by requirements such as provider or mode and return cost-oriented results with pricing and context information.

Setup and configuration

The tokencost-dev MCP server runs through npx, so a client can launch it without a separate service or configuration file. Claude Code can register it with:

claude mcp add tokencost-dev -- npx -y tokencost-dev

For Cursor, add a server entry to .cursor/mcp.json:

{
  "mcpServers": {
    "tokencost-dev": {
      "command": "npx",
      "args": ["-y", "tokencost-dev"]
    }
  }
}

No API key, account, or environment variable is required according to the project documentation. The server uses the LiteLLM registry as its pricing source and maintains its own local cache.

Tools and capabilities

The tokencost-dev MCP server provides four tools:

• get_model_details looks up a model’s pricing, context window, provider, mode, and capabilities. Fuzzy matching supports both abbreviated and complete model names.
• calculate_estimate computes the expected cost for specified input and output token counts.
• compare_models identifies cost-effective models that match supplied requirements, including provider and mode filters.
• refresh_prices forces a new pricing-data fetch from LiteLLM.

These tools suit assistants that answer pricing questions, estimate usage for a proposed prompt and response size, or compare available models before choosing one.

Limitations and notes

Pricing is sourced from the LiteLLM community registry rather than from a provider-specific billing API. The displayed values therefore depend on the registry data available to the server. Cached data can remain in use for up to the automatic 24-hour refresh interval unless refresh_prices is called.

The documentation describes pricing and metadata lookup, token-based estimation, and model comparison. It does not describe making model requests, tracking an account’s actual usage, or calculating a provider invoice. Estimates should therefore be treated as token-price calculations based on the selected registry entry.