Skip to main content
Glama
Sign In
mcpcost

mcpcost

by ondraulehla
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Measure one server now

measure_server
Read-onlyIdempotent

Connect to an MCP server by URL or launch a local command to report its protocol version, tool count, and context-token cost, helping assess unregistered or local servers.

Instructions

Measures one MCP server now: connects to a remote URL, or starts a local command and stops it after tools/list, then reports the result, the protocol version, the tool count and the context-token cost of the tool definitions (o200k_base estimate; the exact Claude count when ANTHROPIC_API_KEY is set). Use it for a server that is not in the official registry, or for a local command; for a registry server prefer lookup_server, which answers from the daily board without a connection. Sends no credentials: a server that needs them comes back with status "auth", not an error. 15 s timeout per request. Give url or command, not both.

Input Schema

NameRequiredDescriptionDefault
urlNoRemote endpoint to connect to, https://…/mcp (Streamable HTTP) or an …/sse URL. Use this or command.
windowNoContext window in tokens for shareOfWindow; default 200000 (Claude)
commandNoLocal server command with its arguments, started with stdio and stopped after tools/list, for example "npx -y @modelcontextprotocol/server-filesystem /tmp". Use this or url.

Output Schema

NameRequiredDescriptionDefault
errorNoThe first line of the failure, when status is not ok
statusNook (answered initialize and tools/list), auth (needs credentials), payment (402), not_found, protocol_error (not MCP), timeout, dns, tls, refused, server_error, rate_limited, newer_protocol, or for a local command: install_failed, no_bin, needs_env, needs_args, needs_network, crashed
targetNoThe url or command that was measured
topToolsNoThe ten most expensive tools: name and o200k_base tokens
latencyMsNoinitialize and toolsList, milliseconds
toolCountNoHow many tools tools/list returned
serverInfoNoname, version and title the server reports in initialize
claudeErrorNoWhy the Anthropic endpoint refused to count, for example a schema it does not accept
claudeTokensNoExact count from the Anthropic count_tokens endpoint, names as published; only with ANTHROPIC_API_KEY
shareOfWindowNoPercent of the context window the tool definitions take, exact when claudeTokens is present, else the estimate
protocolVersionNoThe MCP protocol version the server negotiated
toolsTokensEstimateNoo200k_base tokens over the compact JSON of every tool definition; the exact Claude count is about 1.9 times this at the median
claudeTokensClaudeCodeNoThe same with the Claude Code prefix mcp__<server>__ on each tool name

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.3.4
    • changedInput schema / properties / command / description
      Previous value: -"Local server command with its arguments, for example \"npx -y @modelcontextprotocol/server-filesystem /tmp\""New value: +"Local server command with its arguments, started with stdio and stopped after tools/list, for example \"npx -y @modelcontextprotocol/server-filesystem /tmp\". Use this or url."
    • changedInput schema / properties / url / description
      Previous value: -"Remote endpoint, https://…/mcp or an SSE URL"New value: +"Remote endpoint to connect to, https://…/mcp (Streamable HTTP) or an …/sse URL. Use this or command."
    • changedInput schema / properties / window / description
      Previous value: -"Context window for the share, default 200000"New value: +"Context window in tokens for shareOfWindow; default 200000 (Claude)"
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "properties": {
+    "claudeError": {
+      "description": "Why the Anthropic endpoint refused to count, for example a schema it does not accept",
+      "type": "string"
+    },
+    "claudeTokens": {
+      "description": "Exact count from the Anthropic count_tokens endpoint, names as published; only with ANTHROPIC_API_KEY",
+      "type": "integer"
+    },
+    "claudeTokensClaudeCode": {
+      "description": "The same with the Claude Code prefix mcp__<server>__ on each tool name",
+      "type": "integer"
+    },
+    "error": {
+      "description": "The first line of the failure, when status is not ok",
+      "type": "string"
+    },
+    "latencyMs": {
+      "description": "initialize and toolsList, milliseconds",
+      "type": "object"
+    },
+    "protocolVersion": {
+      "description": "The MCP protocol version the server negotiated",
+      "type": "string"
+    },
+    "serverInfo": {
+      "description": "name, version and title the server reports in initialize",
+      "type": "object"
+    },
+    "shareOfWindow": {
+      "description": "Percent of the context window the tool definitions take, exact when claudeTokens is present, else the estimate",
+      "type": "number"
+    },
+    "status": {
+      "description": "ok (answered initialize and tools/list), auth (needs credentials), payment (402), not_found, protocol_error (not MCP), timeout, dns, tls, refused, server_error, rate_limited, newer_protocol, or for a local command: install_failed, no_bin, needs_env, needs_args, needs_network, crashed",
+      "type": "string"
+    },
+    "target": {
+      "description": "The url or command that was measured",
+      "type": "string"
+    },
+    "toolCount": {
+      "description": "How many tools tools/list returned",
+      "type": "integer"
+    },
+    "toolsTokensEstimate": {
+      "description": "o200k_base tokens over the compact JSON of every tool definition; the exact Claude count is about 1.9 times this at the median",
+      "type": "integer"
+    },
+    "topTools": {
+      "description": "The ten most expensive tools: name and o200k_base tokens",
+      "items": {
+        "properties": {
+          "name": {
+            "type": "string"
+          },
+          "tokens": {
+            "type": "integer"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "type": "object"
+}
  2. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare read-only, idempotent, open-world, non-destructive, so the bar is lower, yet the description adds substantial operational context: no credentials are sent, auth-requiring servers return status "auth" rather than an error, there is a 15 s per-request timeout, and local commands are terminated after tools/list. These are exactly the behaviors an agent needs to predict outcomes and avoid misinterpreting failures.

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?

Single dense paragraph, but front-loaded with the core action and organized as action → outputs → usage routing → safety/timeout constraints. Every sentence carries information; the only cost is that the density makes it slightly harder to scan than a bulleted form.

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?

An output schema exists so return values needn't be spelled out, yet the description still previews the key results. Combined with timeout, auth behavior, and process lifecycle, an agent has everything needed to invoke this correctly on the first try.

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 coverage is 100%, so the baseline is 3; the description earns extra credit by stating the mutual exclusivity of url and command and by noting the token-count estimation modes (o200k_base vs exact Claude count when ANTHROPIC_API_KEY is set), which explains the meaning of the reported cost. The `window` parameter's role in shareOfWindow is left to the schema.

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?

States a specific verb and resource ('Measures one MCP server now') and enumerates the mechanism (connect to remote URL or start a local command), plus exactly what is reported: result, protocol version, tool count, context-token cost. It also distinguishes itself from lookup_server by naming it explicitly.

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

Usage Guidelines5/5

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

Explicit routing rules: use this for servers not in the official registry or for local commands, and prefer lookup_server for registry servers because it answers from the daily board without a connection. It also states the url-vs-command exclusion ('Give url or command, not both'), removing the main invocation ambiguity.

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

Deploy Server

Other Tools