Skip to main content
Glama
ondraulehla

mcpcost

by ondraulehla
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

mcpcost

CI npm mcpcost license

Is that MCP server alive, and what does it cost your context window?

Live board: mcpcost.ulehla.dev

mcpcost probes every remote server in the official MCP registry and records, for each one:

  • whether it answers initialize and tools/list, and how fast

  • the protocol version it negotiates

  • whether it needs auth, and which scheme (from WWW-Authenticate)

  • whether it asks for payment (HTTP 402)

  • how many tools it has and how many tokens their definitions cost

mcpcost: what do your own servers cost?

npx mcpcost                     # reads Claude Code, Claude Desktop, Cursor, VS Code, Windsurf and Gemini CLI configs
npx mcpcost --config .mcp.json  # one file
npx mcpcost --budget 30000      # exit 1 when the total is above the budget, for CI
npx mcpcost --claude            # exact counts from the Anthropic count_tokens endpoint (free, needs ANTHROPIC_API_KEY)
npx mcpcost mcp                 # the same measurements as an MCP server over stdio, for your agent

It starts every configured server the way your client does, lists the tools and prints the token cost per server and in total. See packages/mcpcost.

In CI, as a GitHub Action

GitHub Marketplace

- uses: ondraulehla/mcpcost@v1
  with:
    config: .mcp.json   # one or more config files, one per line
    budget: 30000       # fail when the tool definitions cost more than this

The job summary gets a table with every server, its result and its cost, plus the most expensive tools. A pull request that adds a 40 000-token server fails the check. Set claude: true and put ANTHROPIC_API_KEY in env for exact counts from the free count_tokens endpoint; the default is the o200k_base estimate. Outputs: tokens, servers, over-budget.

Related MCP server: UsageWall

The board

mcpcost.ulehla.dev is rendered on the edge from a D1 database, ships no JavaScript, and refreshes every night.

  • Overview: the share of servers that answer, token cost percentiles, and a form to check any server

  • Check: probes one URL live, with the same steps as the daily run; the exact token count runs in the browser

  • Statistics: results by cause, token cost and tool count percentiles, the heaviest tool sets, protocol versions, auth schemes, transports, biggest publishers

  • Servers: full-text search over name, title, description and host (word prefixes, so git copilot finds the GitHub Copilot servers), filters by result, protocol and transport, seven sorts, and every filter is a plain URL you can share

  • Server page: status, latency, protocol, capabilities, the most expensive tools, servers with the same tool set, history, and the badge

  • Hosts: the 500 biggest publishers with how many distinct tool sets they actually serve

For agents and scripts

  • JSON: /api/s/<name>.json, /api/servers.json?q=…&status=ok&sort=tokens, /api/check.json?url=…, /api/summary.json

  • MCP server over Streamable HTTP, no auth: https://mcpcost.ulehla.dev/mcp with the tools lookup_server, search_servers, check_server, registry_summary. The manifest for the registry is site/server.json.

  • /llms.txt lists all of it. /tokens answers the general question: how many context tokens does an MCP server cost.

Each server on the board gets a page and a badge:

[![mcpcost](https://mcpcost.ulehla.dev/badge/io.github.you/your-server.svg)](https://mcpcost.ulehla.dev/s/io.github.you/your-server)

First full run, 2026-10-03

The registry held 38 942 latest entries. 24 294 of them have a remote endpoint, and the probe connected to all of them in 40 minutes.

Result

Servers

Share

alive: initialize and tools/list succeed

12 975

53 %

needs auth (401, 403)

5 836

24 %

not MCP: HTTP 200 but no valid MCP reply

1 800

7 %

not found (404, 405, 410)

881

4 %

no DNS

728

3 %

rate limited (429)

500

2 %

payment required (402)

434

2 %

server error (5xx)

349

1 %

other

307

1 %

TLS error

259

1 %

timeout

204

1 %

refused

21

0 %

Of the 12 975 servers that answered:

  • the median tool set costs 1 727 tokens, the 90th percentile 7 429, the 99th 28 200

  • 208 servers cost more than 20 000 tokens, 46 more than 50 000, and 3 more than a whole 200k window

  • the heaviest is com.replynodes/mcp: 66 tools, 431 925 tokens

  • the median server has 8 tools, the largest 1 385

  • median initialize latency is 455 ms, the 90th percentile 1.5 s

  • 60 % negotiate protocol 2025-11-25, 24 % still 2025-03-26, 4 % 2024-11-05

  • 122 servers answer with protocol 2026-07-28, which the current TypeScript SDK rejects

The registry is lumpy. 16 161 of 16 534 hosts publish one server. Five hosts publish more than 6 000 entries between them: one Workers subdomain with 2 365 near-identical entries, a gateway with 1 716 entries of which 1 321 return a JSON-RPC error on initialize, and a host with 276 entries that all answer 402.

How it works

registry ──▶ probe/run.ts ──▶ data/raw/probe-run.json
                                   │
                        probe/build-data.ts
                                   │
               data/latest/{servers,summary,hosts}.json
                                   │
                           probe/to-sql.ts ──▶ import.sql ──▶ D1
                                                                │
                              site/ (Astro on Workers) ◀────────┘

  • packages/mcpcost/ the library and the CLI mcpcost: registry client, remote and stdio probe, config discovery, token counting

  • probe/ the batch runner and the data pipeline

  • site/ the board: Astro 7 with the Cloudflare adapter on Workers, rendered from D1 with FTS5 search, SVG badges, no client JavaScript

  • .github/workflows/probe.yml runs the whole pipeline daily and commits summary.json and hosts.json

  • .github/workflows/deploy.yml deploys the site when site/ changes

Methodology

  • Transport. The probe uses the official TypeScript SDK as a client. Streamable HTTP first, SSE when that is the only remote.

  • No GET stream. The probe answers 405 to the SDK's standalone GET, so it never opens a server-to-client stream. The probe needs no server-initiated messages, and some servers stall tools/list while that stream is open (DeepWiki held it for 15 s and never answered the POST meanwhile).

  • Exact token count. The daily run asks the Anthropic count_tokens endpoint for every alive server: one request with the server's tools plus a marker tool, one with the marker tool only, and the difference is what the tools cost in claude-opus-5-5. A second count uses Claude Code's mcp__<server>__ prefix on each tool name. The endpoint is free and calls no model. A server is counted again only when its tool definitions change. About 5 % of servers publish a schema the endpoint refuses; they show the estimate and the reason.

  • Estimate. Each tool is serialised as compact JSON with name, description and input_schema, and counted with the o200k_base tokenizer. The exact count is about 1.9 times the estimate at the median. The estimate needs no key and is the same for every server.

  • Same tool set. A hash of the sorted tool names and schema sizes marks servers that serve identical tools under different names.

  • Timeouts. 15 seconds per request. At most one probe runs against a host at a time.

  • Identification. Every request carries the User-Agent mcpcost/<version> (+https://github.com/ondraulehla/mcpcost). To exclude a server, open an issue with its registry name.

Run it

npm install
npm run probe -- --sample 200 --per-host 2        # a sample, results in data/samples/
npm run probe -- --all --out data/raw/probe-run.json
node --import tsx probe/build-data.ts --in data/raw/probe-run.json --out data/latest
node --import tsx probe/to-sql.ts --in data/latest --out data/latest/import.sql
npm test --workspaces --if-present

Site, locally against a local D1:

cd site
npm run db:schema:local && npm run db:import:local
npm run dev

Deploying needs a Cloudflare account with a D1 database named mcpcost (wrangler d1 create mcpcost, then put the id in site/wrangler.jsonc). The workflows expect the repository secrets CLOUDFLARE_API_TOKEN (Workers Scripts: Edit, D1: Edit) and CLOUDFLARE_ACCOUNT_ID.

Licence

MIT

Available Tools

4 tools
lookup_serverLook up a registry server on the boardAInspect

Latest daily probe of a server in the official MCP registry: status, exact token cost in Claude, tool count, latency, history. Accepts the registry name (io.github.owner/name) or the server URL.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameOrUrlYes

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It does disclose that the data is a 'latest daily probe', which tells the agent the figures are cached/snapshotted rather than live — a genuinely useful trait. However, it says nothing about what happens for an unknown server, auth requirements, or 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, zero waste: the return contents are front-loaded and the input contract follows. Each clause (probe freshness, field list, accepted formats) earns its place given there is no output schema.

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 one-parameter lookup tool with no output schema and no annotations, the description usefully covers both what comes back and what to pass in. Minor gaps remain around error/not-found behavior and whether the probe requires the server to already be listed in the registry.

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 description coverage is 0% for the single required parameter, so the description must carry it — and it does, specifying the two accepted input forms (registry name in io.github.owner/name format, or the server URL). That is exactly the format guidance the bare 'string' schema omits, though it does not say whether one form is preferred or when one fails.

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 (look up) and resource (a server in the official MCP registry) and enumerates what the probe returns (status, token cost, tool count, latency, history). This clearly distinguishes it from search_servers (discovery) and measure_server (measurement), though it never names those siblings explicitly.

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 scoping phrase 'in the official MCP registry' narrows the domain, but there is no statement of when to prefer this over measure_server, measure_config, or search_servers, and no prerequisite or exclusion guidance. An agent must infer the single-server-identity vs. discovery/measurement split on its own.

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

measure_configMeasure a config fileAInspect

Measures every server in an MCP config file (.mcp.json, Claude Desktop, Cursor, VS Code or Windsurf format): starts each one the way the client would and reports tokens per server and in total.

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYesPath to the config file
windowNo
noStdioNoMeasure remote servers only, do not start local ones

TDQS

A3.6/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 and does disclose a key side effect that is not visible in the schema: it 'starts each one the way the client would,' i.e. it spawns server processes. It also states what is reported (tokens per server and in total). It omits failure behavior when a server cannot start, timeouts, and whether spawned processes are cleaned up.

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?

A single front-loaded sentence: verb and scope come first, the supported formats and the output shape follow. It is dense but every clause earns its place; only the parenthetical format list makes it slightly heavy for one sentence.

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?

Good coverage of the return content despite no output schema, and the config-format enumeration is useful. But with no annotations and a partially documented schema, the description should say more about what happens when a server fails to start, how long measurement takes, and what 'window' controls.

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 67%: 'path' and 'noStdio' are documented in the schema, but 'window' has no description anywhere and the description does not explain it. The description does add value by naming which client formats the path may point to, but it adds nothing for the two undocumented-behavior parameters beyond the schema.

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 ('Measures') and resource ('every server in an MCP config file'), and enumerates the supported config formats, which tells the agent exactly what input to supply. The phrase 'every server' implicitly distinguishes it from the singular measure_server sibling, but it never names or contrasts that sibling explicitly.

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?

Usage is implied by the scope: use this when you have a whole config file rather than a single server. However, there is no explicit when-to-use/when-not guidance and no reference to measure_server for the single-server case, leaving the agent to infer the selection rule from scope alone.

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

measure_serverMeasure one serverAInspect

Starts or connects to one MCP server, lists its tools and reports the result, the protocol version and the token cost of its tool definitions. Give either a remote URL or a local command.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlNoRemote endpoint, https://…/mcp or an SSE URL
windowNoContext window for the share, default 200000
commandNoLocal server command with its arguments, for example "npx -y @modelcontextprotocol/server-filesystem /tmp"

TDQS

A3.6/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It does disclose the key side effect that the tool launches or connects to a server and lists its tools, and it names the reported outputs. However, it says nothing about auth requirements, process-spawn side effects, timeouts, or failure behavior when a URL/command is unreachable.

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 tight sentences, zero filler, with the action front-loaded and the input requirement placed last where it is easy to find. Every clause earns its place.

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?

There is no output schema, so the description must cover returns — and it does, naming the result, protocol version, and token cost. It is nearly complete for a 3-param, 0-required tool, though it omits error/timeout behavior and how the token cost is computed.

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%, so the baseline is 3. The description adds a small amount of meaning with the 'either a remote URL or a local command' mutual-exclusivity hint, but it never mentions the `window` parameter or clarifies the relationship between url/command and the token-cost share.

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 gives a concrete verb chain (starts/connects, lists tools, reports) and a specific resource (one MCP server), plus the concrete outputs: protocol version and token cost of tool definitions. It does not name or differentiate itself from siblings like measure_config or lookup_server, so it falls short of a 5.

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?

'Give either a remote URL or a local command' describes the input mode but not when to choose this tool over measure_config, lookup_server, or search_servers. Usage is implied by the verb ('measure one server') rather than stated, with no exclusions or prerequisites.

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

search_serversSearch the boardBInspect

Finds registry servers by words in their name, title, description or host, sorted by exact Claude token cost by default. Twenty per page.

ParametersJSON Schema
NameRequiredDescriptionDefault
pageNo
sortNo
queryNo
statusNo

TDQS

B3.3/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the default sort (exact Claude token cost) and pagination size (twenty per page), but says nothing about read-only safety, rate limits, or what a result entry contains. Partial disclosure for an unannotated 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?

Two tight sentences, front-loaded with purpose and search scope, followed by the default ordering and page size. No filler.

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?

For a 4-parameter search tool with no annotations and no output schema, the description covers query behavior, default sort, and pagination, but omits the meaning of the status filter values and any hint at the shape of returned results. Adequate but with clear gaps.

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 description coverage is 0% with 4 parameters, so the description must compensate. It explains the query semantics (matching words in name/title/description/host), the default sort (Claude token cost), and the page size (twenty), but leaves the status enum values and the page parameter's meaning completely undefined.

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 (finds) and resource (registry servers) and even names the fields searched (name, title, description, host), so the agent knows this is a keyword search over server metadata. It does not explicitly differentiate itself from the sibling lookup_server, which is the only gap.

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 guidance on when to use this versus lookup_server or measure_server, and no mention of when to apply the status filter or non-default sorts. Usage must be inferred entirely from the name and description.

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. 4 tool updatesv0.1.0
    • First observedlookup_server
    • First observedmeasure_config
    • First observedmeasure_server
    • First observedsearch_servers
Deploy Server
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

A3.7/5.0

Scored across 4 tools

Disambiguation4/5

measure_server, measure_config, lookup_server and search_servers each target a distinct input (single live server, config file, registry entry, registry query). The only soft overlap is measure_server vs lookup_server, since both report a server's token cost, but the descriptions clearly separate live measurement from cached registry probe data.

Naming Consistency5/5

All four names follow the same verb_noun convention (measure_*, lookup_*, search_*), lower snake_case throughout with no deviations. The pattern is predictable and self-explanatory.

Tool Count5/5

Four tightly scoped tools cover the domain of token-cost measurement without redundancy. Each one maps to a distinct workflow (single server, config file, registry lookup, registry discovery), so nothing feels padded or missing.

Completeness4/5

The surface covers live measurement, bulk config measurement, registry lookup and registry search, giving a full path from discovery to cost comparison. Minor gaps remain, such as comparing two servers side by side or exporting results, but core workflows are covered.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers