A
licenseC
qualityA
maintenanceMCP server for Langfuse observability. Query traces, debug exceptions, analyze sessions, and manage prompts and datasets for your LLM applications.
48
105
MIT
MCPSpend
This server lets you monitor, analyze, and optimize the cost of your AI agent's MCP tool calls directly from any MCP client.
get_today_cost: Returns total tool-call cost and count for the current UTC day.get_usage_this_month: Shows monthly usage vs. plan limit, percentage consumed, and a projection to catch cap overruns early.list_top_tools: Identifies the most expensive tools over a configurable time window (1–365 days), returning up to 50 entries ranked by total cost.list_recent_sessions: Lists recent agent sessions with model, total cost, call count, and duration (up to 100 sessions).get_session_details: Drills into a specific session by ID, returning a summary and up to 500 individual tool calls with timing, cost, and success status.estimate_cost: Estimates the USD cost of a tool call before invoking it, based on historical averages for that (server, tool, model) combination—enabling spend-aware decisions like prompting user confirmation for expensive calls.
MCPSpend
Know what your AI agents really cost. Real-time cost tracking for every MCP tool call across Cursor, Claude Desktop, Windsurf, and VS Code.
mcpspend.com · Smithery · npm · Open VSX · Glama
One-command install
npx --yes @mcpspend/proxy@latest init --key mcps_live_xxxAuto-detects Claude Desktop, Cursor, Windsurf, VS Code (user + workspace), and Claude Code (user + project). Wraps every configured MCP server, leaves a .mcpspend.bak backup, and starts streaming usage to your dashboard at mcpspend.com.
Free tier: 25,000 tool calls/month, no credit card.
Related MCP server: iris-eval/mcp-server
What's in this monorepo
Package | What it is |
| |
| |
| |
Express + Prisma + Postgres + BullMQ. The ingest endpoint, billing, and the new | |
Next.js dashboard at mcpspend.com. |
Three ways to query your usage
Use case | How |
Web dashboard | mcpspend.com/dashboard — overview, top tools, sessions, CSV export. |
From any MCP client (stdio) | Add |
From any MCP client (HTTP) | Point your client at |
Pricing
Plan | Calls/month | Monthly | Yearly |
Free | 25,000 | $0 | $0 |
Pro | 1,000,000 | $29 | $290 (2 months free) |
Team | 10,000,000 | $99 | $990 |
Enterprise | unlimited | $499 | $4,990 |
Every paid plan: 30–90 day retention, CSV/Slack export, budget alerts, role-based access.
Privacy
The proxy reports: tool name, server name, model, latency, success, approximate input/output sizes (tokens, derived from JSON length). It does not send the actual tool arguments or response bodies to MCPSpend. See Privacy Policy for the full sub-processor list (Stripe + Resend + Hostinger, all EU-hosted) and your GDPR rights.
Security
For automated scanners flagging this repo: the proxy uses
child_process.spawnto wrap the user's own MCP server — that's the whole point of an observability proxy. The spawn args come from the user's local MCP-client config (Claude Desktop / Cursor / Windsurf / VS Code), never from network input. No RCE path, no privilege escalation, no arbitrary command execution. Full threat model inSECURITY.md.
API keys stored as SHA-256 hashes (never plaintext on the server)
Passwords bcrypt cost 12
Secrets at rest AES-256-GCM (
APP_ENCRYPTION_KEY)Transport HTTPS only, HSTS enabled, helmet CSP headers
No tool arguments or responses ever leave the user's machine
Per-tenant isolation every query scopes by
organizationIdGDPR Art. 15 / 17 / 20 self-serve at
mcpspend.com/dashboard/account/privacyEU-hosted (Hostinger EU region)
SOC 2 Type I in progress with Vanta (Q4 2026)
DPA available for Enterprise customers
Report vulnerabilities: security@mcpspend.com · Machine-readable disclosure: https://mcpspend.com/.well-known/security.txt · Full policy: SECURITY.md · Live posture: https://mcpspend.com/security
Support the project
If MCPSpend saves you money or you just want to keep the proxy MIT and the free tier alive, you can sponsor any amount via Stripe — no account required:
💖 buy.stripe.com/00w8wPbUxe1qgK36CRbbG06
Every dollar goes back into hosting, security audits, and shipping features.
License
MIT. Use it, fork it, run it self-hosted.
© NewRzs SRL · CUI RO48756557 · Bucharest, Romania · support@mcpspend.com
Available Tools
6 toolsestimate_costA
Estimate the USD cost of an MCP tool call BEFORE invoking it. Returns expected cost based on the historical average for this (server, tool, model) combo in this org over the last 30 days. Use this to make spend-aware decisions — e.g. confirm with the user before calling tools that would cost more than $0.10. Returns 0 + isUnknown=true when no history exists yet.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| serverName | Yes | MCP server name, e.g. "playwright" or "github". | |
| toolName | Yes | Tool name within that server, e.g. "browser_navigate". | |
| model | No | Optional model identifier for cost lookup. Falls back to the historical median for this tool when omitted. |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes return values (expected cost, isUnknown flag) and how cost is derived: historical average for same (server, tool, model) combo over last 30 days. No annotations, so description carries burden and does well, though lacks details on cost computation boundaries.
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 plus a usage example. No fluff, every sentence earns its place. Front-loaded with purpose.
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?
Completely describes a simple tool. Explains inputs, outputs, and special case (no history). No output schema but description covers return fields adequately.
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 has 100% coverage with descriptions. Description adds value by explaining the optional model field falls back to historical median, which is not in schema. No need for more.
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?
Explicitly states it estimates USD cost of an MCP tool call before invoking. Differentiates from siblings like get_session_details, get_today_cost by focusing on cost estimation.
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?
Provides clear when-to-use: 'Use this to make spend-aware decisions — e.g. confirm with the user before calling tools that would cost more than $0.10.' Also explains behavior when no history exists. Missing explicit when-not-to-use, but context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_session_detailsA
Drill into a single session by ID: returns the session summary plus every tool call (up to 500) with timing, cost, and success.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | Session ID from list_recent_sessions. |
TDQS
A4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that it returns session summary and up to 500 tool calls with timing, cost, and success. This provides key behavioral information beyond basic purpose.
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 the action verb 'Drill into', 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is sufficiently complete. It explains the return structure (summary + tool calls with details). Could mention error behavior, but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, session_id, is fully described in the schema (100% coverage). The description adds no meaningful additional detail beyond referencing the session ID. Baseline 3 applies as schema covers it.
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 drills into a single session by ID, returning session summary and tool calls. This distinguishes it from sibling tools like list_recent_sessions (list) and estimate_cost (cost estimation).
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 it is used after list_recent_sessions to get details, but does not explicitly state when to use or when to avoid. It lacks explicit alternative guidance or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_today_costA
Get total tool-call cost and call count for the current day (UTC). Returns a human-readable summary plus structured data.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that data is for UTC day and returns a summary plus structured data, but lacks details on data source, caching, error behavior, or what happens if no calls are made today. Adequate for a simple stat tool.
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, well-structured sentence that front-loads the core purpose and specifies the output format, containing no unnecessary 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?
Given no output schema and no annotations, the description provides essential info: scope (UTC today), content (cost and count), and output format (summary + structured). It is adequate for the tool's simplicity, though could mention the structured data format for completeness.
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?
The input schema has zero parameters, so the baseline is 4. The description adds no parameter details, which is appropriate since there are no parameters.
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 uses a specific verb ('Get') and resource ('total tool-call cost and call count') with clear scope ('current day (UTC)'), making the purpose distinct from sibling tools like 'estimate_cost' or 'get_usage_this_month'.
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 does not explicitly state when to use this tool versus alternatives, but the purpose is implied by the resource: if today's cost and count are needed, this tool is appropriate. No exclusions or alternative mentions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_usage_this_monthA
Returns calls used this month, plan limit, percentage used, and a projection for the rest of the month based on the current daily average. Use this to spot when an org is about to hit the cap.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A4.4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains the projection is based on current daily average, which is useful. Lacks details on caching or real-time nature, but adequate for a simple read operation.
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 wasted words. Front-loaded with key returns and use case.
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 no input schema and no output schema, the description covers inputs (none) and outputs (calls, limit, %, projection). Could specify month scope more explicitly, but sufficient for its simplicity.
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?
No parameters (0), schema coverage 100% vacuously. Baseline 4. Description adds meaning about what data is returned, fulfilling the role.
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 calls used, plan limit, percentage used, and projection for the month. It is distinct from sibling tools like estimate_cost or get_today_cost, which focus on cost or sessions.
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 says to use the tool to spot when an org is about to hit the cap. No explicit when not to use, but the purpose is narrow enough that it's clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_recent_sessionsA
Recent agent sessions (each MCP-client process start = one session) with model, total cost, tool call count, and duration.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max sessions to return (1-100). Default 20. |
TDQS
A4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that each session is tied to an MCP-client process start and lists the returned fields. It does not mention ordering or default limit, but for a list endpoint this is reasonable. No contradiction with annotations.
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, front-loaded sentence with no filler. Every word adds value, defining the scope and content.
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 list tool with one optional parameter and no output schema, the description is adequate. It explains the session definition and returned fields. Could mention default limit or sorting, but not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (the only parameter 'limit' has a full schema description). The description adds no further parameter-specific meaning, so baseline 3 is appropriate.
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 lists recent agent sessions, defines what a session is (MCP-client process start), and enumerates the fields returned (model, total cost, tool call count, duration). This distinguishes it from sibling tools like estimate_cost and get_session_details.
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 usage for viewing recent sessions but does not explicitly state when to use this tool versus siblings (e.g., for cost-related queries, use cost tools). No exclusions or alternatives are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_top_toolsA
Top tools by total cost over the past N days. Optionally limit how many entries to return. Useful for finding "what is the most expensive thing my agents do".
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Days back to consider (1-365). Default 7. | |
| limit | No | Max entries to return (1-50). Default 10. |
TDQS
A4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the burden. It states it lists top tools by cost, implying a read operation. However, it does not disclose if the list is sorted, whether it's cumulative, or any other behavioral details beyond the schema.
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 concise sentences. The first sentence front-loads the core action and scope. The second adds optionality. 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?
For a simple list tool with two optional parameters and no output schema, the description covers purpose and usage. Missing details like sort order (descending by cost) are minor but could improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters described (days range, limit range). The description adds 'top tools by total cost' context but does not materially extend the schema's explanations.
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?
Clearly states the tool lists top tools by total cost over N days, with optional limit. The verb 'list' and resource 'top tools' are specific, and the description distinguishes it from sibling tools like 'get_today_cost' or 'list_recent_sessions'.
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 notes it is useful for finding the most expensive tools (usage context). No when-not or alternatives mentioned, but the sibling list makes it clear this is distinct.
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. Dates show when Glama detected each change.
6 tool updates
v1.0.0- First observed
estimate_cost - First observed
get_session_details - First observed
get_today_cost - First observed
get_usage_this_month - First observed
list_recent_sessions - First observed
list_top_tools
TDQS
A4.4/5.0
Disambiguation5/5
Each tool has a distinct purpose: estimate cost before calls, drill into session details, daily cost, monthly usage with projection, list sessions, and top tools. No overlap.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern (e.g., estimate_cost, get_session_details, list_recent_sessions) with snake_case, making it predictable.
Tool Count5/5
6 tools is well-scoped for a cost monitoring server; covers estimation, daily/monthly usage, session details, and top spenders without being excessive.
Completeness5/5
Covers the core domain: pre-call estimation, current day cost, monthly usage with projections, session details, and top cost drivers. No obvious gaps.
Maintenance
ActivitySlowing
ResponsivenessSyncing
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Hosted MCP server for LLM cost estimation, model comparison, and budget-aware routing.
Agent Cost Allocator MCP — multi-tenant LLM cost attribution for chargeback billing. Companion to
See, price, and control every tool call your AI agents make: policy checks, cost, and audit tools.
Free OpenAI-compatible inference with signed provenance receipts and 3 focused MCP tools.
Related MCP Servers
- AlicenseAqualityAmaintenanceMCP-native agent evaluation and observability server. Log traces, evaluate output quality with 12 built-in rules (PII detection, prompt injection, cost thresholds), and track agent costs. Real-time dashboard, OTel-compatible spans. Self-hosted, MIT licensed.91299MIT
- AlicenseBqualityFmaintenanceTrack LLM token costs across Claude, GPT and Gemini. MCP server + CLI with optimization hints and $ savings estimates.8151MIT
- FlicenseNot gradedqualityDmaintenanceEnables AI cost calculation, comparison, and optimization across major providers like Anthropic, OpenAI, Google, Meta, and Mistral. Supports cost estimation, budget-aware model finding, and token estimation through a simple API and MCP integration.-
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/andreisirbu91-lab/MCPSpend'
If you have feedback or need assistance with the MCP directory API, please join our Discord server