Skip to main content
Glama

MCP Cost Optimizer

See what your LLM calls cost and how much you'd save by switching models β€” local MCP server, no API keys.

Find overspending in your AI agent's usage records. Compare the cost of every model you're considering. Make decisions with real numbers, not guesses.

npm version npm downloads CI License: MIT Glama


πŸš€ Quick Install

Cursor

Add to Cursor

Click the button above to install in Cursor with one click, or use this deeplink:

cursor://anysphere.cursor-deeplink/mcp/install?name=cost-optimizer&config=eyJjb21tYW5kIjoibnB4IiwiYXJncyI6WyIteSIsIm1jcC1jb3N0LW9wdGltaXplciJdfQ==

Claude Code

# Quick install
claude mcp add cost-optimizer -- npx -y mcp-cost-optimizer

# Or via marketplace
/plugin marketplace add petrovicistefan/mcp-cost-optimizer
/plugin install mcp-cost-optimizer@mcp-cost-optimizer

VS Code

Install in VS Code

Or manually add to .vscode/mcp.json:

{
  "servers": {
    "cost-optimizer": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "mcp-cost-optimizer"]
    }
  }
}

Any MCP Client

npx -y mcp-cost-optimizer

See detailed setup instructions for other clients (Windsurf, Cline, Gemini CLI, Zed, Codex CLI).


Related MCP server: token-meter

Table of Contents


Quickstart

Claude Code Plugin

/plugin marketplace add petrovicistefan/mcp-cost-optimizer
/plugin install mcp-cost-optimizer@mcp-cost-optimizer

Any MCP Client

Works with Cursor, VS Code, Windsurf, Claude Desktop, Cline, Codex CLI, Zed, and Gemini CLI. Install with one command:

npx -y mcp-cost-optimizer

Or add to your MCP config file:

Claude Desktop, Cursor, Windsurf, Cline, Gemini CLI β€” claude_desktop_config.json, ~/.cursor/mcp.json, ~/.codeium/windsurf/mcp_config.json, Cline MCP settings, ~/.gemini/settings.json:

{
  "mcpServers": {
    "cost-optimizer": {
      "command": "npx",
      "args": ["-y", "mcp-cost-optimizer"]
    }
  }
}

VS Code / GitHub Copilot β€” .vscode/mcp.json:

{
  "servers": {
    "cost-optimizer": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "mcp-cost-optimizer"]
    }
  }
}

Zed β€” settings.json:

{
  "context_servers": {
    "cost-optimizer": {
      "command": "npx",
      "args": ["-y", "mcp-cost-optimizer"]
    }
  }
}

Codex CLI:

codex mcp add cost-optimizer -- npx -y mcp-cost-optimizer

⭐ Support This Project

Found this MCP useful? Star this repository!

A GitHub star helps other developers discover the project and lets you save it for later. Thanks for supporting open source!


Demo

Cost Analysis Demo

Analyzing LLM usage across multiple models with custom pricing rates


Why MCP Cost Optimizer?

You're running AI agents. You have usage logs. You're wondering:

  • How much did that cost? Analyze normalized usage records and see total cost, per-model breakdown, and which models lack pricing data.

  • What if I switched models? Compare migration scenarios: keep your token counts, change the model, see estimated savings (or extra cost).

  • Am I repeating the same requests? Identify conditional response-cache opportunities when you supply request hashes.

MCP Cost Optimizer is:

  • Local-first: No API keys, no accounts, no outbound requests. Your usage data stays on your machine.

  • Provider-agnostic: Bring your own pricing tables. Works with any LLM provider.

  • Transparent: All calculations are deterministic. No hidden assumptions, no magic. You supply the prices, you get exact estimates.


Example Prompts

Once installed, try asking your AI agent:

"Analyze these normalized usage records with my supplied rates. Identify unknown models and repeated requests, then compare a cheaper model. Explain assumptions and do not change production routing."

"I have 50,000 requests across gpt-4o and claude-sonnet-4.5. Estimate the cost with these rates, then show me the savings if I switched to gpt-4o-mini for half of them."

"Compare my current model usage to claude-haiku-3-5. What would I save per month if I migrated?"


Tools

The server exposes three MCP tools for cost analysis:

Tool

Description

Inputs

Output

estimate_llm_cost

Estimate one LLM request from supplied per-million token rates. Input tokens include cached tokens.

record (model, tokens), rates (pricing)

Single-request cost estimate with currency and pricing date

analyze_llm_usage

Analyze normalized LLM usage; report costs, unknown models and conditional response-cache opportunities. No network or file access.

records (array, max 100k), rates (pricing)

Aggregate analysis: total cost, per-model breakdown, unknown models, duplicate request opportunities, token totals

compare_llm_models

Compare a target model with known-price baseline. Scenario only; requires quality evaluation and does not change routing.

records (array, max 100k), rates (pricing), targetModel (string)

Migration scenario: what you'd spend with a different model, keeping the same token counts (requires quality evaluation separately)

All tools:

  • Accept structured JSON arguments

  • Return formatted text + structured JSON

  • Read-only and idempotent (safe to call repeatedly)

  • No network requests or file access


Importing Usage Data

The hook is weak because the tools require normalized usage records. Here's how to get them.

Expected Input Format

Each usage record must include:

{
  "model": "gpt-4o",
  "inputTokens": 1000,
  "outputTokens": 50,
  "cachedInputTokens": 0,
  "requestHash": "optional-unique-identifier"
}

Rules:

  • model: Exact model name (must match your rates file)

  • inputTokens: Total input tokens, including cached tokens

  • outputTokens: Total output tokens

  • cachedInputTokens: (Optional) Prompt cache hits (must be ≀ inputTokens)

  • requestHash: (Optional) Unique identifier for the entire request (tenant, model params, system context, tool state, freshness) β€” used to identify conditional response-cache opportunities

Important: OpenAI's prompt_tokens and Anthropic's separate cache fields are not accepted directly. You must normalize them first.

Example: OpenAI Usage Export

If you export usage from OpenAI's dashboard, you might get CSV with columns like model, prompt_tokens, completion_tokens, cached_tokens.

Transform to normalized format:

// Example transformation (Node.js)
const fs = require('fs');
const Papa = require('papaparse'); // npm install papaparse

const csv = fs.readFileSync('openai-usage-export.csv', 'utf8');
const parsed = Papa.parse(csv, { header: true, dynamicTyping: true });

const normalized = parsed.data.map(row => ({
  model: row.model,
  inputTokens: row.prompt_tokens, // OpenAI prompt_tokens = total input
  outputTokens: row.completion_tokens,
  cachedInputTokens: row.cached_tokens || 0,
  requestHash: row.request_id // if available
}));

fs.writeFileSync('normalized-usage.jsonl', normalized.map(r => JSON.stringify(r)).join('\n'));

Then supply normalized-usage.jsonl to your agent along with your rates file.

Example: Anthropic Usage Export

Anthropic's usage exports include separate fields for input_tokens, cache_creation_input_tokens, cache_read_input_tokens, and output_tokens.

Transform to normalized format:

// Anthropic β†’ normalized format
const normalized = anthropicUsage.map(row => ({
  model: row.model,
  inputTokens: row.input_tokens + row.cache_creation_input_tokens + row.cache_read_input_tokens,
  outputTokens: row.output_tokens,
  cachedInputTokens: row.cache_read_input_tokens,
  requestHash: row.request_id // if available
}));

Note: Cache-write pricing is separate from normal input pricing. This MVP does not support differential cache-write rates. If you supply cachedInputPerMillion in your rates file, it applies to cache reads only.


Rates File Format

Supply your own pricing table as JSON:

{
  "currency": "USD",
  "asOf": "2026-10-19",
  "models": {
    "gpt-4o": {
      "inputPerMillion": 2.5,
      "outputPerMillion": 10.0,
      "cachedInputPerMillion": 1.25
    },
    "claude-sonnet-4.5": {
      "inputPerMillion": 3.0,
      "outputPerMillion": 15.0
    }
  }
}
  • currency: Three-letter code (e.g., "USD", "EUR")

  • asOf: (Optional) Date when prices were verified

  • models: Keyed by exact model name

    • inputPerMillion: Price per million input tokens

    • outputPerMillion: Price per million output tokens

    • cachedInputPerMillion: (Optional) Price per million cached input tokens (defaults to inputPerMillion if omitted)

All models in the rates file must use the same currency. Unknown models are excluded from totals and marked as incomplete.

See examples/rates.json for a demo file (fictional prices).


Use Cases

1. AI Agent Cost Audit

You've run Claude Code or Cursor for a month. You have session logs. You want to know:

  • Total spend per model

  • Which models lacked pricing data

  • Where you can save by switching models

Workflow: Export your usage, normalize it, supply it to your agent with this MCP server installed. Ask: "Analyze my usage and compare it to a cheaper model."

2. Model Migration Planning

You're considering migrating from gpt-4o to gpt-4o-mini for some workloads.

Workflow: Use compare_llm_models to estimate savings. Keep in mind: the tool assumes token counts stay the same. You must separately evaluate quality, context window, and latency.

3. Response Cache Opportunity Detection

You supply requestHash for each request (a hash of tenant, model params, system context, tool state, freshness requirements).

Workflow: The analyze_llm_usage tool identifies duplicate hashes and reports upper-bound savings if you implemented conditional response caching. This is not provider prompt cachingβ€”it's request-level deduplication.

4. Individual Developer / Freelancer

You're working across multiple clients. You want to track LLM costs per project.

Workflow: Keep separate usage logs per project. Analyze each independently. Sum totals for invoicing.

5. Team / Enterprise

Your team shares an API key. You want to attribute costs per engineer or per feature.

Workflow: Tag usage records with engineer/feature identifiers. Analyze subsets. (Future: hosted path with budgets and alerts.)


Privacy & Security

  • No telemetry: Zero outbound requests from the local MCP server or CLI.

  • No credentials: The server never asks for or stores API keys.

  • No file writes: MCP tools accept structured data only; they do not read or write files.

  • CLI sandboxing: The CLI reads JSON/JSONL files only under its current directory, resolves symlinks, and rejects paths outside that root. Files are checked for regular-file type and size (≀20 MiB) before reading. JSONL is parsed incrementally and capped at 100,000 records.

  • Safe arithmetic: Aggregated token counts reject unsafe integer totals. Cost calculations reject infinite results.


Comparison

Tool

Focus

Local

Import Format

Model Comparison

Cache Opportunities

MCP Server

MCP Cost Optimizer

Cost analysis & model-switch scenarios

βœ…

Normalized JSON

βœ…

βœ… (request-level)

βœ…

agentacct

Agent work intelligence & cost dashboard

βœ…

Claude Code/Codex logs

❌

❌

❌ (Python dashboard)

Tokenscope

Menu-bar dashboard for Claude CLI

βœ…

Claude CLI logs

❌

❌

❌ (macOS/Windows app)

tokentop

Real-time terminal monitoring

βœ…

Provider APIs + session files

❌

βœ… (provider cache %)

❌ (TUI)

llm-cost-dashboard

Terminal dashboard with budgets & forecasts

βœ…

Log file / stdin

❌

❌

❌ (Rust TUI)

What sets MCP Cost Optimizer apart:

  • MCP-native: Works with any MCP client (Claude Code, Cursor, VS Code, Windsurf, Cline, Zed, Claude Desktop, Gemini CLI, Codex CLI).

  • Model comparison: Estimate savings (or extra cost) for migration scenarios.

  • Request-level cache detection: Identify duplicate requests when you supply hashes.

  • Provider-agnostic: Bring your own pricing tables (OpenAI, Anthropic, Gemini, Llama, Mistral, etc.).

  • Transparent: All calculations are deterministic. No guesswork, no hidden assumptions.


Limitations

This is an MVP (v0.1.2). Here's what it doesn't do yet:

  • Cache-write pricing: Separate cache-write rates are not supported. Only cache-read pricing is configurable via cachedInputPerMillion.

  • Reasoning tokens: Extended reasoning tokens (e.g., OpenAI o1/o3 series) are not separately priced in this version.

  • Automatic pricing updates: You must maintain your own rates file. The tool does not fetch live pricing from providers.

  • Invoice reconciliation: Estimates are based on your supplied prices, not provider invoices. Currency conversion and taxes are not included.

  • Quality evaluation: Model comparisons assume token counts stay the same. You must separately evaluate quality, tokenizer differences, context window, tool support, and latency.

  • Automatic routing: The tool provides estimates only. It does not change your application's model selection.


Free and Pro

  • Local MCP/CLI: Free forever. Works offline. No accounts, no API keys, no quotas.

  • Hosted path (future): For teams that want centralized quotas, budgets, and alerts, a hosted HTTP path with control-plane integration is planned. Pricing TBD.


Roadmap

  • Provider adapters for automatic normalization (OpenAI, Anthropic, Gemini, Bedrock)

  • Cache-write and reasoning token accounting

  • Verified versioned pricing catalog

  • Project budgets and alerts

  • Quality-gated model evaluation

  • Hosted reporting dashboard

Validate these features with real usage before adding automatic optimizations.


Contributing

Contributions welcome! See CONTRIBUTING.md (if exists) or open an issue.

Before contributing:

  1. Run npm test and npm run check to verify your changes.

  2. Follow the existing code style (zero external dependencies in core.js, ESM modules, node:test for tests).

  3. Add tests for new features.


License

MIT License - see LICENSE file for details.

Copyright Β© 2026 Stefan Petrovici

Free to use, modify, and distribute. No warranty provided.


More MCP Servers by the Author

Part of the petrovicistefan MCP suite β€” local-first guardrails for AI coding agents.

Server

Purpose

Link

πŸ›‘οΈ MCP Security Guard

Detect tool poisoning, rug pulls, prompt injection in MCP servers

GitHub

πŸ’° MCP Cost Optimizer

Analyze LLM costs and model-switch savings

GitHub

πŸ—„οΈ MCP Database Doctor

Diagnose schema issues, slow queries, missing indexes

GitHub

πŸ“¦ MCP Dependency Doctor

Find outdated packages, CVEs, license conflicts

GitHub

πŸ” MCP SEO Auditor

Local SEO checks for meta tags, schema, performance

GitHub

🌐 MCP API Guardian

Validate OpenAPI specs, detect breaking changes

GitHub

πŸͺ MCP Marketplace

Browse and discover the full suite

GitHub

Explore all MCP servers β†’


Found this useful? ⭐ Star this repo to help others discover it!

Available Tools

3 tools
analyze_llm_usageB
Read-onlyIdempotent

Analyze normalized LLM usage; report costs, unknown models and conditional response-cache opportunities. No network or file access.

NameRequiredDescriptionDefault
ratesYes
recordsYes

TDQS

B3/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by saying it reports unknown models and conditional response-cache opportunities, and by stating 'No network or file access.' It still does not explain error behavior or how unknown models are handled beyond being reported.

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 a single compact sentence with no wasted words. The main purpose is front-loaded, followed by the report contents and no-I/O constraint.

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

Completeness2/5

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

This is a complex tool with a deeply nested input schema, 0% schema description coverage, and no output schema. The description briefly mentions return contents but does not explain the input structure or enough semantics for records and rates. It is too thin for the tool's complexity.

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

Parameters2/5

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

Schema description coverage is 0%, and the input schema is a nested object with required records and rates plus detailed subfields. The description only vaguely gestures at 'normalized LLM usage' and 'costs' without explaining what records, rates, currency, asOf, requestHash, or cachedInputTokens mean. The schema has to carry nearly all parameter meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: analyze normalized LLM usage. It also names the report contents (costs, unknown models, response-cache opportunities), which helps distinguish it from a simple cost-estimation sibling. However, it does not explicitly contrast itself with estimate_llm_cost or compare_llm_models.

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

Usage Guidelines2/5

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

The description implies that the tool is for analyzing normalized usage records with rates, but it gives no explicit when-to-use guidance. There is no mention of prerequisites, exclusions, or when an agent should choose this tool over estimate_llm_cost or compare_llm_models.

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

compare_llm_modelsC
Read-onlyIdempotent

Compare a target model with known-price baseline. Scenario only; requires quality evaluation and does not change routing.

NameRequiredDescriptionDefault
ratesYes
recordsYes
targetModelYes

TDQS

C2.9/5.0
Behavior3/5

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so safety is covered. The description adds the meaningful behavioral point that this is a simulation/scenario with no routing side effects and that quality evaluation is out of scope, but it never says what the caller gets back or what constraints apply to the comparison.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with the core action and followed by the scope caveat. Nothing is padded, though the second sentence's "requires quality evaluation" phrasing is more confusing than economical.

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

Completeness2/5

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

For a tool with a nested schema at 0% description coverage, a 100k-item array, no output schema, and three mandatory inputs, two sentences are far too thin. The agent cannot tell what shape of records to supply or what the comparison surfaces.

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

Parameters2/5

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

Schema description coverage is 0% across three required parameters, one of which is a deeply nested rates object and another a records array of up to 100,000 items. The description only obliquely gestures at targetModel and rates ("known-price baseline"); the records parameter, including inputTokens/outputTokens/cachedInputTokens and requestHash, is completely unaddressed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

"Compare a target model with known-price baseline" gives a verb and a resource, but the object of the comparison is ambiguous: cost? quality? throughput? The mention of "requires quality evaluation" muddies rather than clarifies. Sibling names (estimate_llm_cost, analyze_llm_usage) are never referenced, so the agent must infer the boundary itself.

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?

"Scenario only" and "does not change routing" imply when this tool is appropriate (what-if analysis rather than live actuals), which is genuine usage guidance. However, no alternative is named explicitly, and the agent is left to guess that estimate_llm_cost is the non-scenario counterpart.

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

estimate_llm_costB
Read-onlyIdempotent

Estimate one LLM request from supplied per-million token rates. Input tokens include cached tokens.

NameRequiredDescriptionDefault
ratesYes
recordYes

TDQS

B3/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false. The description adds useful calculation context by stating rates are supplied per-million tokens and that input tokens include cached tokens, but it does not explain how cached rates are applied, rounding, or what the estimate returns.

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 short sentences, front-loaded with the core action and followed by the key costing caveat. There is no wasted text.

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

Completeness2/5

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

The tool has a nested rates object, a nested record object, no output schema, and no schema descriptions. The description is too sparse to fully explain the required nested structure, currency, model-rate mapping, or the expected return, leaving significant gaps for an agent.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must carry parameter meaning. It clarifies per-million rates and cached-token inclusion, but leaves key nested semantics undocumented: rates.models keyed by model, currency format, asOf, requestHash, and outputTokens.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Estimate one LLM request' cost from supplied token rates. It is clear what the tool does, though it does not explicitly distinguish itself from siblings analyze_llm_usage and compare_llm_models.

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

Usage Guidelines2/5

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

There is no explicit guidance on when to use this tool versus the sibling tools, nor any when-not conditions. The phrase 'one LLM request' implies single-request estimation rather than bulk analysis, but that is left to inference.

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.

  1. 3 tool updatesv0.1.2
    • First observedanalyze_llm_usage
    • First observedcompare_llm_models
    • First observedestimate_llm_cost

TDQS

B3.4/5.0

Scored across 3 tools

Disambiguation4/5

Each tool targets a different scope: single-request estimation, aggregate usage analysis, and model comparison. They all relate to cost, but the descriptions make the boundaries clear enough for an agent to select correctly.

Naming Consistency5/5

All three names follow the same verb_llm_noun pattern: estimate_llm_cost, analyze_llm_usage, compare_llm_models. The convention is predictable and consistent.

Tool Count5/5

Three tools are well-scoped for a narrow cost-analysis server, and each serves a distinct purpose. No unnecessary tools are present.

Completeness3/5

The surface covers estimation, usage analysis, and model comparison, but an optimizer would benefit from a recommendation or pricing-catalog operation. As named, it analyzes costs rather than completing an optimization lifecycle.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    A
    quality
    B
    maintenance
    Local-first dashboard + MCP server that parses Claude Code and Codex JSONL files into a SQLite cost / token tracker. Per-MCP and per-tool breakdown, session drill-down, dedup by request_id; never talks to vendor APIs
    5
    130 npm
    1
    MIT
  • A
    license
    A
    quality
    B
    maintenance
    A local-first, multi-provider cost meter for LLM usage, exposed as MCP tools. Captures every call into a local SQLite ledger and lets any coding agent query spend, compare providers, and get recommendations β€” no cloud, no account. First-class support for Chinese providers (Qwen, DeepSeek) alongside Anthropic and OpenAI.
    7
    6
    MIT