mcpcost

Compare servers side by side

compare_servers

Read-onlyIdempotent

Compare two to five MCP servers by status, access, tool count, token cost, context-window share, and initialize latency, with cheapest, priciest, and spread, to choose between similar servers.

Instructions

Puts two to five servers next to each other from the board's latest daily probe: status, how a client gets in, tool count, token cost (exact in Claude when counted, else the estimate), share of a 200k window and initialize latency, with the cheapest, the most expensive and the spread. Use it to choose between servers that do the same job; use lookup_server for the full record of one server, search_servers to find candidates, and measure_server to measure a server that is not in the registry. Instant, no connection to the servers, with registry names or endpoint URLs as the registry lists them. A name the board does not know gets a row with status "unknown" and the comparison goes on. format picks the text layout (JSON, a Markdown table, or CSV to paste into a spreadsheet); the structured content is always JSON.

Input Schema

Name	Required	Description	Default
`format`	No	The layout of the text content: json (default), markdown (a table with a summary line), or csv (a header row, then one row per server)
`servers`	Yes	Two to five registry names (io.github.owner/name) or https URLs of MCP endpoints

Output Schema

Name	Required	Description
`format`	No
`servers`	No	One row per requested server, in the order given
`cheapest`	No	The server with the fewest tokens, when two or more rows are measured
`measured`	No	How many rows have a token number
`tokenSpread`	No	Tokens between the most expensive and the cheapest
`mostExpensive`	No

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.3.4Oct 24, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the readOnly/idempotent/openWorld annotations, it discloses that the call is instant with no live connection, that data comes from the board's last daily probe, and that unknown names produce an "unknown" row rather than an error. It also clarifies that structured content is always JSON regardless of format — behavior the annotations cannot express.

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?

Front-loaded with purpose and comparison dimensions, with routing and format notes after. It is one dense paragraph with several parenthetical asides (token cost caveat, format parenthetical) that could be broken into shorter sentences, but no sentence is filler.

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 shape need not be described, yet the description still enumerates the compared metrics. Combined with the unknown-name fallback, the error model, and the no-network note, an agent has everything needed to call it correctly.

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 already 100%, so baseline is 3; the description still adds value by explaining accepted server identifiers (registry names or endpoint URLs "as the registry lists them") and what each format layout produces. It stops short of elaborating on edge cases like duplicate entries or mixed name/URL lists.

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 ("puts two to five servers next to each other") plus the exact dimensions compared (status, access, tool count, token cost, window share, init latency, cheap/expensive/spread). The scope of 2-5 and the source (board's latest daily probe) further disambiguate it from siblings that fetch a single record.

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?

Gives an explicit selection rule ("use it to choose between servers that do the same job") and names three alternatives with the condition that selects each: lookup_server for a full record, search_servers to find candidates, measure_server for unregistered servers. An agent needs no inference to route correctly.

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

Deploy Server