# tokencost-dev [Health: Active]

**Category:** 🗣️ Conversational AI  
**Repository:** https://github.com/atriumn/tokencost-dev  
**GitHub Stars:** 1  
**npm Downloads (last month):** 245  
**Views:** 1  
**Installs:** 0  
**Upvotes:** 0  
**Directory Page:** https://allmcps.com/mcp/tokencost-dev

## Description
LLM pricing oracle — model lookup, cost estimation, and comparison via LiteLLM

## Tools
Capabilities this server exposes over MCP:

- **get_model_details** — Look up pricing, context window, and capabilities for an LLM model. Uses fuzzy matching so you don't need the exact model key.
- **calculate_estimate** — Estimate the cost for a given number of input and output tokens on a specific model. Supports optional cached_tokens for prompt caching discounts.
- **compare_models** — Filter and compare models by provider, minimum context window, or mode. Returns top 5 most cost-effective matches.
- **refresh_prices** — Force a re-fetch of pricing data from the LiteLLM registry. Use this if you suspect the cached data is stale.

## Claude Desktop Quick Installation
Install path detected from listing signals. Uses `npx` (confidence: high):

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

## Documentation

## 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:

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

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

```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.

_Full upstream README: https://allmcps.com/mcp/tokencost-dev/readme_