Health and token cost of every remote MCP registry server, probed daily. Look up, search, or probe.
Scored across 5 tools
Each tool targets a distinct mode of access: live probe (check_server), single registry record (lookup_server), multi-server comparison (compare_servers), discovery/ranking (search_servers), and registry-wide aggregates (registry_summary). Descriptions explicitly cross-reference each other to steer selection, e.g. 'use lookup_server instead of check_server for registry servers'.
All snake_case with a clear verb_noun shape (check_server, lookup_server, search_servers, compare_servers). The one deviation is registry_summary, which is noun-only rather than verb-led, but it remains readable and predictable.
Five tools, each covering a genuinely different query pattern (single live, single cached, multi, search, aggregate) with no filler. This is well-scoped for a registry cost/latency board.
Covers discovery, per-server detail, live probing of unregistered URLs, side-by-side comparison, and whole-registry statistics, which spans the domain well. Minor gaps: no explicit way to fetch a full per-tool cost breakdown beyond 'most expensive tools', and history/trends over time are absent.
Connects to an MCP server URL now (initialize and tools/list, 10 s timeout) and reports status, protocol, how a client gets access, tool names and the token cost of the tool definitions: exact in Claude when the counter is available, else an estimate from the schema size. Use it for a URL that is not in the official registry, or to see the state this minute; for a registry server prefer lookup_server, which is instant. Sends no credentials: a server that needs them comes back with status "auth", not an error. A URL that is not https, or a server that does not answer, returns its failure as status and error.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The https URL of the MCP endpoint, Streamable HTTP (…/mcp) or SSE (…/sse) |
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| error | No | The first line of the failure, when status is not ok |
| tools | Yes | The tool names, in the order the server lists them |
| status | Yes | ok (answered initialize and tools/list), auth (needs credentials), payment (402), needs_url (every URL in the registry has a placeholder each user fills in; not called), unprobed (an entry the probe does not run yet: an MCPB bundle, an OCI image, a NuGet or Cargo package, or nothing to connect to), not_found, protocol_error (not MCP), timeout, dns, tls, refused, server_error, rate_limited, newer_protocol, unsupported_version (rejects the protocol version the client asks for); package servers also install_failed, no_bin, needs_env, needs_args, needs_network, needs_old_sdk (starts and lists its tools only with mcp<2), crashed. A failure counts as down only after two days of failed probes (see failingSince) |
| authKind | No | How a client gets in: oauth-dcr, oauth, token or unknown |
| latencyMs | Yes | |
| toolCount | No | |
| authScheme | No | The WWW-Authenticate scheme of a server that needs auth |
| httpStatus | No | The HTTP status of the first response |
| serverInfo | No | name, version and title from initialize |
| toolsBytes | Yes | Bytes of the compact JSON of every tool definition |
| claudeError | No | |
| claudeModel | No | |
| statusLabel | Yes | The status in words |
| authMetadata | No | authorizationServers, scopesSupported, dynamicRegistration, pkce, grantTypes |
| claudeTokens | No | Exact count from the Anthropic count_tokens endpoint |
| estimateNote | Yes | |
| protocolVersion | No | |
| authDocumentation | No | The publisher's guide to getting access |
| toolsTokensEstimate | Yes | Tokens estimated from the schema size at the registry median of 4.42 bytes per token |
| claudeTokensClaudeCode | No | The exact count with the Claude Code prefix on each tool name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent/openWorld annotations, it discloses the 10 s timeout, that no credentials are sent, that an auth-requiring server returns status "auth" rather than an error, and that non-https URLs or unresponsive servers surface as status+error fields. These are exactly the behaviors an agent needs to interpret a surprising result.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the action, and each sentence carries distinct information (behavior, routing, auth semantics, failure mode). The token-cost clause ("exact in Claude when the counter is available, else an estimate from the schema size") is the densest part and could be trimmed without loss.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, yet the description still summarizes the returned fields and, importantly, explains the non-error failure conventions. Combined with the auth and https notes, an agent has everything needed to call it and read the result correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already specifies the https URL format with …/mcp and …/sse examples. The description adds a real constraint on top (a non-https URL returns its failure as status), but does not extend the parameter semantics much further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (connects to an MCP server URL now, runs initialize and tools/list) and enumerates what it reports: status, protocol, access method, tool names, token cost. It is immediately distinguishable from lookup_server, which reads the registry rather than probing live.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use: a URL not in the official registry, or to see the state this minute. It also names the alternative (lookup_server) and the condition that selects it (registry server, instant). No inference required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Puts two to five registry 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 check_server for a URL that is not in the registry. Instant, no connection to the servers. 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.
| 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 the servers' https URLs as the registry lists them |
| Name | Required | Description |
|---|---|---|
| format | Yes | |
| servers | Yes | One row per requested server, in the order given |
| cheapest | Yes | The server with the fewest tokens, when two or more rows are measured |
| measured | Yes | How many rows have a token number |
| tokenSpread | Yes | Tokens between the most expensive and the cheapest |
| mostExpensive | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and open-world, but the description adds real context the annotations cannot: the data comes from the board's latest daily probe, token cost is exact in Claude when counted and an estimate otherwise, no connection is made to the servers, and a name missing from the board yields an "unknown" row rather than an error. Only the latency/rate characteristics of the daily probe freshness are left implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and alternatives, and every sentence carries information (data source, cost methodology, edge case, format). The middle sentence is a dense run-on enumerating six dimensions, but nothing is redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 need not be described, and the description still covers provenance, the cost-estimate caveat, the unknown-name edge case and the format/structured-content split. Nothing an agent needs to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, but the description still adds meaning: format selects the text layout only while the structured content is always JSON, and the servers parameter tolerates unknown names (returning an "unknown" row). Those are semantics beyond the schema text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (compares) and resource (two to five registry servers) and enumerates exactly what dimensions are compared: status, client access, tool count, token cost, share of 200k window, initialize latency, cheapest/most expensive/spread. This is clearly distinguishable from lookup_server, search_servers and check_server.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the selecting condition ("Use it to choose between servers that do the same job") and routes to each alternative with its own condition: lookup_server for a full record, search_servers to find candidates, check_server for a URL not in the registry. That is a complete when/when-not/alternatives map.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reads the board's latest daily probe of one server in the official MCP registry: status, how a client gets access, the exact Claude token cost of its tool definitions, tool count, latency and the most expensive tools. Instant, no connection to the server. Use it when the server is in the registry; use search_servers when you do not know its name, and check_server to probe a URL that is not in the registry. A name or URL that is not on the board returns isError with a short message.
| Name | Required | Description | Default |
|---|---|---|---|
| nameOrUrl | Yes | The registry name, for example io.github.owner/name, or the server's https URL as the registry lists it. The name is exact; the URL must match the registry entry. |
| Name | Required | Description |
|---|---|---|
| url | Yes | The endpoint the board probes |
| down | No | True when the server has failed for two days or more; a more recent failure is "no answer", not down |
| host | Yes | The endpoint host |
| name | Yes | The registry name, io.github.owner/name |
| page | Yes | The server's page on the board |
| title | No | The title the registry gives |
| status | Yes | ok (answered initialize and tools/list), auth (needs credentials), payment (402), needs_url (every URL in the registry has a placeholder each user fills in; not called), unprobed (an entry the probe does not run yet: an MCPB bundle, an OCI image, a NuGet or Cargo package, or nothing to connect to), not_found, protocol_error (not MCP), timeout, dns, tls, refused, server_error, rate_limited, newer_protocol, unsupported_version (rejects the protocol version the client asks for); package servers also install_failed, no_bin, needs_env, needs_args, needs_network, needs_old_sdk (starts and lists its tools only with mcp<2), crashed. A failure counts as down only after two days of failed probes (see failingSince) |
| authKind | No | How a client gets in: oauth-dcr (clients register themselves), oauth (client id from the publisher), token (a key in the Authorization header), unknown |
| probedAt | Yes | ISO 8601 time of the probe |
| topTools | No | The five most expensive tools: name and o200k_base tokens |
| latencyMs | No | |
| toolCount | No | How many tools tools/list returned |
| authScheme | No | The WWW-Authenticate scheme of a server that needs auth |
| httpStatus | No | The HTTP status of the first response |
| claudeError | No | Why the Anthropic endpoint refused to count |
| claudeModel | No | The model the exact count is for |
| shareOf200k | No | Percent of a 200k window, exact when claudeTokens is present |
| statusLabel | Yes | The status in words, as the board shows it |
| toolsTokens | No | o200k_base estimate over the compact JSON of the tool definitions; the exact count is about 1.9 times this at the median |
| authMetadata | No | authorizationServers, scopesSupported, dynamicRegistration, pkce, grantTypes, from the OAuth metadata |
| claudeTokens | No | Exact count from the Anthropic count_tokens endpoint, names as published |
| failingSince | No | For a server with no valid answer: the first probe of its current run of failed probes, ISO 8601 |
| protocolVersion | No | The MCP protocol version the server negotiated |
| toolsTokensNote | No | |
| authDocumentation | No | The publisher's guide to getting access |
| claudeTokensClaudeCode | No | The exact count with the Claude Code prefix mcp__<server>__ on each tool name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/openWorld, and the description adds real context beyond them: results are a 'daily probe' (so data can be up to a day stale) and 'instant, no connection to the server' (no live network call). It also discloses the error contract for unknown names. Only gap is any note on result caching or limits, which is minor here.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences, front-loaded with what is returned, then the when-to-use routing, then the error case. No filler and no repetition of the name/title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with full schema coverage, annotations, and an output schema, the description covers purpose, freshness, live-vs-cached behavior, alternatives, and error handling. Nothing an agent needs before calling is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single parameter's description already explains the registry-name format and the URL-must-match rule. The description echoes that a name or URL is required but adds no syntax or edge-case detail beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource ('Reads the board's latest daily probe of one server in the official MCP registry') and enumerates the returned facets: status, access method, token cost, tool count, latency, most expensive tools. That is enough for an agent to distinguish it from compare_servers or registry_summary without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the positive condition ('use it when the server is in the registry') and names both alternatives with their selecting conditions: search_servers when the name is unknown, check_server for a URL not in the registry. It even documents the failure path for names not on the board.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Aggregates of the latest daily run over the whole official MCP registry: how many servers answer and why the rest do not, token cost percentiles and the exact-to-estimate ratio, how servers authenticate, protocol versions, transports, the heaviest servers and the biggest publishers. Use it for the state of the registry as a whole; use lookup_server or search_servers for one server. No input; the answer is a few kilobytes of JSON.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| ok | No | Servers that answered initialize and tools/list |
| probed | No | Servers probed in this run |
| byStatus | No | Servers per status |
| noAnswer | No | Of the failing servers, the ones that are not down yet: no valid answer for less than two days, per status |
| probedAt | Yes | ISO 8601 time of the run |
| authKinds | No | Servers that need auth, per kind of access: oauth-dcr, oauth, token, unknown |
| protocols | No | Alive servers per negotiated protocol version |
| toolCount | No | median, p90, max |
| transports | No | |
| authSchemes | No | Servers that need auth, per WWW-Authenticate scheme |
| toolsTokens | No | o200k_base estimate: median, p90, p99, max, total |
| claudeTokens | No | Exact Claude counts: model, counted, refused, median, p90, p99, max, histogram, ratioToEstimate |
| registryEntries | No | Entries in the registry |
| registryWithRemote | No | Entries with a remote endpoint |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, open-world and non-destructive, so safety is covered. The description adds real context beyond them: the data is as of the 'latest daily run' (freshness caveat) and the response is 'a few kilobytes of JSON' (payload size), both of which matter for planning a call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with what is aggregated before the routing guidance. The middle clause is dense with enumerated dimensions, but every element is informative rather than filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, yet the description still previews the JSON contents, and it covers freshness, payload size, and routing. Nothing an agent needs in order to call this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline is 4. The description explicitly says 'No input', removing any ambiguity that an argument might be expected.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource ('Aggregates of the latest daily run over the whole official MCP registry') and enumerates the dimensions covered. It explicitly distinguishes its whole-registry scope from per-server siblings (lookup_server, search_servers), so an agent can route without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the condition that selects this tool ('state of the registry as a whole') and names the alternatives to use for a single server. The contrast is explicit rather than inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Finds servers on the board by words in their name, title, description or host, with optional filters, sorted by exact Claude token cost (highest first) by default. With no query and no filter it ranks the whole board, so page 1 is the most expensive servers in the registry and sort=claude-asc the cheapest. Use it to discover servers or to rank them by cost; use lookup_server once you have a name, compare_servers for a few side by side, registry_summary for the totals. Returns up to 20 servers per page with name, host, status, tool count and tokens. Page numbers go to 20; after that pass the next value of the previous answer as cursor. Sorting by the estimate, latency, protocol or registry date needs a query or a small status; on a bigger list the answer keeps the token order and says so in sort.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number, 1 to 20, twenty servers each; default 1. Not with cursor. | |
| sort | No | claude = exact Claude tokens, highest first (default); claude-asc = lowest first; tokens = the o200k_base estimate; tools = tool count; latency = initialize time; name; updated = registry date | |
| query | No | Words to match, three or more characters each, as prefixes: "git copilot" finds the GitHub Copilot servers. Omit for the whole list. | |
| cursor | No | The `next` value of a previous answer, to continue from there; replaces page | |
| status | No | ok = answers and lists tools; auth = needs credentials; payment = 402; newer_protocol = a protocol newer than the SDK; down = no valid answer for two days or more; noanswer = no valid answer for less than two days. Omit for all. |
| Name | Required | Description |
|---|---|---|
| next | No | The cursor for the next page, when hasNext |
| page | No | The page number, absent when a cursor was used |
| sort | Yes | The sort that was applied |
| hasNext | Yes | |
| servers | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, open-world, but the description adds substantive traits they cannot express: default ordering is exact Claude token cost descending, empty query returns the full ranked board, paging caps at 20, and continuation uses the `next` value as `cursor`. It also discloses a non-obvious fallback: when sorting by estimate, latency, protocol or registry date on a bigger list, the answer keeps token order and says so in `sort`.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and defaults, then alternatives, then returns and paging mechanics – a sensible information order. It is dense and slightly overpacked (the return-field list is partly redundant given the output schema), but almost every clause carries operative information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter, optional-only search tool with full schema coverage, annotations and an output schema, the description covers the remaining unknowns: default ordering, whole-board behavior, pagination limits and cursor handoff, and sort degradation. An agent can call this correctly on the first attempt.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description goes beyond it by explaining prefix matching with a concrete example ('git copilot' finds GitHub Copilot servers), the three-character minimum, and that `cursor` replaces `page`. Minor gap: it does not elaborate the sort enum values beyond the schema's own explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Finds servers on the board') plus the matched fields (name, title, description, host) and the default ranking rule. Siblings are named explicitly, so an agent can distinguish search_servers from lookup_server, compare_servers and registry_summary without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use routing: 'use lookup_server once you have a name, compare_servers for a few side by side, registry_summary for the totals.' It also states the degenerate case (no query, no filter ranks the whole board) and warns that some sorts need a query or a status filter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_server1 field changedOutput schema / properties / status / descriptionPrevious value: -"ok (answered initialize and tools/list), auth (needs credentials), payment (402), needs_url (every URL in the registry has a placeholder each user fills in; not called), unprobed (an entry the probe does not run yet: an MCPB bundle, an OCI image, a NuGet or Cargo package, or nothing to connect to), not_found, protocol_error (not MCP), timeout, dns, tls, refused, server_error, rate_limited, newer_protocol, unsupported_version (rejects the protocol version the client asks for); package servers also install_failed, no_bin, needs_env, needs_args, needs_network, crashed. A failure counts as down only after two days of failed probes (see failingSince)"New value: +"ok (answered initialize and tools/list), auth (needs credentials), payment (402), needs_url (every URL in the registry has a placeholder each user fills in; not called), unprobed (an entry the probe does not run yet: an MCPB bundle, an OCI image, a NuGet or Cargo package, or nothing to connect to), not_found, protocol_error (not MCP), timeout, dns, tls, refused, server_error, rate_limited, newer_protocol, unsupported_version (rejects the protocol version the client asks for); package servers also install_failed, no_bin, needs_env, needs_args, needs_network, needs_old_sdk (starts and lists its tools only with mcp<2), crashed. A failure counts as down only after two days of failed probes (see failingSince)"lookup_server1 field changedOutput schema / properties / status / descriptionPrevious value: -"ok (answered initialize and tools/list), auth (needs credentials), payment (402), needs_url (every URL in the registry has a placeholder each user fills in; not called), unprobed (an entry the probe does not run yet: an MCPB bundle, an OCI image, a NuGet or Cargo package, or nothing to connect to), not_found, protocol_error (not MCP), timeout, dns, tls, refused, server_error, rate_limited, newer_protocol, unsupported_version (rejects the protocol version the client asks for); package servers also install_failed, no_bin, needs_env, needs_args, needs_network, crashed. A failure counts as down only after two days of failed probes (see failingSince)"New value: +"ok (answered initialize and tools/list), auth (needs credentials), payment (402), needs_url (every URL in the registry has a placeholder each user fills in; not called), unprobed (an entry the probe does not run yet: an MCPB bundle, an OCI image, a NuGet or Cargo package, or nothing to connect to), not_found, protocol_error (not MCP), timeout, dns, tls, refused, server_error, rate_limited, newer_protocol, unsupported_version (rejects the protocol version the client asks for); package servers also install_failed, no_bin, needs_env, needs_args, needs_network, needs_old_sdk (starts and lists its tools only with mcp<2), crashed. A failure counts as down only after two days of failed probes (see failingSince)"search_servers1 field changedOutput schema / properties / servers / items / properties / status / descriptionPrevious value: -"ok (answered initialize and tools/list), auth (needs credentials), payment (402), needs_url (every URL in the registry has a placeholder each user fills in; not called), unprobed (an entry the probe does not run yet: an MCPB bundle, an OCI image, a NuGet or Cargo package, or nothing to connect to), not_found, protocol_error (not MCP), timeout, dns, tls, refused, server_error, rate_limited, newer_protocol, unsupported_version (rejects the protocol version the client asks for); package servers also install_failed, no_bin, needs_env, needs_args, needs_network, crashed. A failure counts as down only after two days of failed probes (see failingSince)"New value: +"ok (answered initialize and tools/list), auth (needs credentials), payment (402), needs_url (every URL in the registry has a placeholder each user fills in; not called), unprobed (an entry the probe does not run yet: an MCPB bundle, an OCI image, a NuGet or Cargo package, or nothing to connect to), not_found, protocol_error (not MCP), timeout, dns, tls, refused, server_error, rate_limited, newer_protocol, unsupported_version (rejects the protocol version the client asks for); package servers also install_failed, no_bin, needs_env, needs_args, needs_network, needs_old_sdk (starts and lists its tools only with mcp<2), crashed. A failure counts as down only after two days of failed probes (see failingSince)"check_server1 field changedOutput schema / properties / status / descriptionPrevious value: -"ok (answered initialize and tools/list), auth (needs credentials), payment (402), needs_url (every URL in the registry has a placeholder each user fills in; not called), unprobed (an entry the probe does not run yet: an MCPB bundle, an OCI image, a NuGet or Cargo package, or nothing to connect to), not_found, protocol_error (not MCP), timeout, dns, tls, refused, server_error, rate_limited, newer_protocol; package servers also install_failed, no_bin, needs_env, needs_args, needs_network, crashed. A failure counts as down only after two days of failed probes (see failingSince)"New value: +"ok (answered initialize and tools/list), auth (needs credentials), payment (402), needs_url (every URL in the registry has a placeholder each user fills in; not called), unprobed (an entry the probe does not run yet: an MCPB bundle, an OCI image, a NuGet or Cargo package, or nothing to connect to), not_found, protocol_error (not MCP), timeout, dns, tls, refused, server_error, rate_limited, newer_protocol, unsupported_version (rejects the protocol version the client asks for); package servers also install_failed, no_bin, needs_env, needs_args, needs_network, crashed. A failure counts as down only after two days of failed probes (see failingSince)"lookup_server1 field changedOutput schema / properties / status / descriptionPrevious value: -"ok (answered initialize and tools/list), auth (needs credentials), payment (402), needs_url (every URL in the registry has a placeholder each user fills in; not called), unprobed (an entry the probe does not run yet: an MCPB bundle, an OCI image, a NuGet or Cargo package, or nothing to connect to), not_found, protocol_error (not MCP), timeout, dns, tls, refused, server_error, rate_limited, newer_protocol; package servers also install_failed, no_bin, needs_env, needs_args, needs_network, crashed. A failure counts as down only after two days of failed probes (see failingSince)"New value: +"ok (answered initialize and tools/list), auth (needs credentials), payment (402), needs_url (every URL in the registry has a placeholder each user fills in; not called), unprobed (an entry the probe does not run yet: an MCPB bundle, an OCI image, a NuGet or Cargo package, or nothing to connect to), not_found, protocol_error (not MCP), timeout, dns, tls, refused, server_error, rate_limited, newer_protocol, unsupported_version (rejects the protocol version the client asks for); package servers also install_failed, no_bin, needs_env, needs_args, needs_network, crashed. A failure counts as down only after two days of failed probes (see failingSince)"search_servers1 field changedOutput schema / properties / servers / items / properties / status / descriptionPrevious value: -"ok (answered initialize and tools/list), auth (needs credentials), payment (402), needs_url (every URL in the registry has a placeholder each user fills in; not called), unprobed (an entry the probe does not run yet: an MCPB bundle, an OCI image, a NuGet or Cargo package, or nothing to connect to), not_found, protocol_error (not MCP), timeout, dns, tls, refused, server_error, rate_limited, newer_protocol; package servers also install_failed, no_bin, needs_env, needs_args, needs_network, crashed. A failure counts as down only after two days of failed probes (see failingSince)"New value: +"ok (answered initialize and tools/list), auth (needs credentials), payment (402), needs_url (every URL in the registry has a placeholder each user fills in; not called), unprobed (an entry the probe does not run yet: an MCPB bundle, an OCI image, a NuGet or Cargo package, or nothing to connect to), not_found, protocol_error (not MCP), timeout, dns, tls, refused, server_error, rate_limited, newer_protocol, unsupported_version (rejects the protocol version the client asks for); package servers also install_failed, no_bin, needs_env, needs_args, needs_network, crashed. A failure counts as down only after two days of failed probes (see failingSince)"check_server1 field changedOutput schema / properties / status / descriptionPrevious value: -"ok (answered initialize and tools/list), auth (needs credentials), payment (402), needs_url (every URL in the registry has a placeholder each user fills in; not called), not_found, protocol_error (not MCP), timeout, dns, tls, refused, server_error, rate_limited, newer_protocol; package servers also install_failed, no_bin, needs_env, needs_args, needs_network, crashed. A failure counts as down only after two days of failed probes (see failingSince)"New value: +"ok (answered initialize and tools/list), auth (needs credentials), payment (402), needs_url (every URL in the registry has a placeholder each user fills in; not called), unprobed (an entry the probe does not run yet: an MCPB bundle, an OCI image, a NuGet or Cargo package, or nothing to connect to), not_found, protocol_error (not MCP), timeout, dns, tls, refused, server_error, rate_limited, newer_protocol; package servers also install_failed, no_bin, needs_env, needs_args, needs_network, crashed. A failure counts as down only after two days of failed probes (see failingSince)"lookup_server1 field changedOutput schema / properties / status / descriptionPrevious value: -"ok (answered initialize and tools/list), auth (needs credentials), payment (402), needs_url (every URL in the registry has a placeholder each user fills in; not called), not_found, protocol_error (not MCP), timeout, dns, tls, refused, server_error, rate_limited, newer_protocol; package servers also install_failed, no_bin, needs_env, needs_args, needs_network, crashed. A failure counts as down only after two days of failed probes (see failingSince)"New value: +"ok (answered initialize and tools/list), auth (needs credentials), payment (402), needs_url (every URL in the registry has a placeholder each user fills in; not called), unprobed (an entry the probe does not run yet: an MCPB bundle, an OCI image, a NuGet or Cargo package, or nothing to connect to), not_found, protocol_error (not MCP), timeout, dns, tls, refused, server_error, rate_limited, newer_protocol; package servers also install_failed, no_bin, needs_env, needs_args, needs_network, crashed. A failure counts as down only after two days of failed probes (see failingSince)"search_servers1 field changedOutput schema / properties / servers / items / properties / status / descriptionPrevious value: -"ok (answered initialize and tools/list), auth (needs credentials), payment (402), needs_url (every URL in the registry has a placeholder each user fills in; not called), not_found, protocol_error (not MCP), timeout, dns, tls, refused, server_error, rate_limited, newer_protocol; package servers also install_failed, no_bin, needs_env, needs_args, needs_network, crashed. A failure counts as down only after two days of failed probes (see failingSince)"New value: +"ok (answered initialize and tools/list), auth (needs credentials), payment (402), needs_url (every URL in the registry has a placeholder each user fills in; not called), unprobed (an entry the probe does not run yet: an MCPB bundle, an OCI image, a NuGet or Cargo package, or nothing to connect to), not_found, protocol_error (not MCP), timeout, dns, tls, refused, server_error, rate_limited, newer_protocol; package servers also install_failed, no_bin, needs_env, needs_args, needs_network, crashed. A failure counts as down only after two days of failed probes (see failingSince)"check_server1 field changedOutput schema / properties / status / descriptionPrevious value: -"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; package servers also install_failed, no_bin, needs_env, needs_args, needs_network, crashed"New value: +"ok (answered initialize and tools/list), auth (needs credentials), payment (402), needs_url (every URL in the registry has a placeholder each user fills in; not called), not_found, protocol_error (not MCP), timeout, dns, tls, refused, server_error, rate_limited, newer_protocol; package servers also install_failed, no_bin, needs_env, needs_args, needs_network, crashed. A failure counts as down only after two days of failed probes (see failingSince)"lookup_server3 fields changedOutput schema / properties / downAdded value: +{
+ "description": "True when the server has failed for two days or more; a more recent failure is \"no answer\", not down",
+ "type": "boolean"
+}Output schema / properties / failingSinceAdded value: +{
+ "description": "For a server with no valid answer: the first probe of its current run of failed probes, ISO 8601",
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / status / descriptionPrevious value: -"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; package servers also install_failed, no_bin, needs_env, needs_args, needs_network, crashed"New value: +"ok (answered initialize and tools/list), auth (needs credentials), payment (402), needs_url (every URL in the registry has a placeholder each user fills in; not called), not_found, protocol_error (not MCP), timeout, dns, tls, refused, server_error, rate_limited, newer_protocol; package servers also install_failed, no_bin, needs_env, needs_args, needs_network, crashed. A failure counts as down only after two days of failed probes (see failingSince)"registry_summary1 field changedOutput schema / properties / noAnswerAdded value: +{
+ "additionalProperties": {
+ "type": "number"
+ },
+ "description": "Of the failing servers, the ones that are not down yet: no valid answer for less than two days, per status",
+ "type": "object"
+}search_servers3 fields changedInput schema / properties / status / descriptionPrevious value: -"ok = answers and lists tools; auth = needs credentials; payment = 402; newer_protocol = a protocol newer than the SDK; down = every other failure. Omit for all."New value: +"ok = answers and lists tools; auth = needs credentials; payment = 402; newer_protocol = a protocol newer than the SDK; down = no valid answer for two days or more; noanswer = no valid answer for less than two days. Omit for all."Input schema / properties / status / enumPrevious value: -[
- "ok",
- "auth",
- "payment",
- "newer_protocol",
- "down"
-]New value: +[
+ "ok",
+ "auth",
+ "payment",
+ "newer_protocol",
+ "down",
+ "noanswer"
+]Output schema / properties / servers / items / properties / status / descriptionPrevious value: -"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; package servers also install_failed, no_bin, needs_env, needs_args, needs_network, crashed"New value: +"ok (answered initialize and tools/list), auth (needs credentials), payment (402), needs_url (every URL in the registry has a placeholder each user fills in; not called), not_found, protocol_error (not MCP), timeout, dns, tls, refused, server_error, rate_limited, newer_protocol; package servers also install_failed, no_bin, needs_env, needs_args, needs_network, crashed. A failure counts as down only after two days of failed probes (see failingSince)"check_server2 fields changedInput schema / properties / url / descriptionPrevious value: -"https URL of the MCP endpoint"New value: +"The https URL of the MCP endpoint, Streamable HTTP (…/mcp) or SSE (…/sse)"Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "authDocumentation": {
+ "description": "The publisher's guide to getting access",
+ "type": "string"
+ },
+ "authKind": {
+ "description": "How a client gets in: oauth-dcr, oauth, token or unknown",
+ "type": "string"
+ },
+ "authMetadata": {
+ "additionalProperties": {},
+ "description": "authorizationServers, scopesSupported, dynamicRegistration, pkce, grantTypes",
+ "type": "object"
+ },
+ "authScheme": {
+ "description": "The WWW-Authenticate scheme of a server that needs auth",
+ "type": "string"
+ },
+ "claudeError": {
+ "type": "string"
+ },
+ "claudeModel": {
+ "type": "string"
+ },
+ "claudeTokens": {
+ "description": "Exact count from the Anthropic count_tokens endpoint",
+ "type": "integer"
+ },
+ "claudeTokensClaudeCode": {
+ "description": "The exact count with the Claude Code prefix on each tool name",
+ "type": "integer"
+ },
+ "error": {
+ "description": "The first line of the failure, when status is not ok",
+ "type": "string"
+ },
+ "estimateNote": {
+ "type": "string"
+ },
+ "httpStatus": {
+ "description": "The HTTP status of the first response",
+ "type": "integer"
+ },
+ "latencyMs": {
+ "additionalProperties": false,
+ "properties": {
+ "initialize": {
+ "type": "number"
+ },
+ "toolsList": {
+ "type": "number"
+ }
+ },
+ "type": "object"
+ },
+ "protocolVersion": {
+ "type": "string"
+ },
+ "serverInfo": {
+ "additionalProperties": {},
+ "description": "name, version and title from initialize",
+ "type": "object"
+ },
+ "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; package servers also install_failed, no_bin, needs_env, needs_args, needs_network, crashed",
+ "type": "string"
+ },
+ "statusLabel": {
+ "description": "The status in words",
+ "type": "string"
+ },
+ "toolCount": {
+ "type": "integer"
+ },
+ "tools": {
+ "description": "The tool names, in the order the server lists them",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "toolsBytes": {
+ "description": "Bytes of the compact JSON of every tool definition",
+ "type": "integer"
+ },
+ "toolsTokensEstimate": {
+ "description": "Tokens estimated from the schema size at the registry median of 4.42 bytes per token",
+ "type": "integer"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "url",
+ "status",
+ "statusLabel",
+ "toolsBytes",
+ "toolsTokensEstimate",
+ "estimateNote",
+ "tools",
+ "latencyMs"
+ ],
+ "type": "object"
+}compare_serverslookup_server2 fields changedInput schema / properties / nameOrUrl / descriptionPrevious value: -"Registry name or https URL of the server"New value: +"The registry name, for example io.github.owner/name, or the server's https URL as the registry lists it. The name is exact; the URL must match the registry entry."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "authDocumentation": {
+ "description": "The publisher's guide to getting access",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "authKind": {
+ "description": "How a client gets in: oauth-dcr (clients register themselves), oauth (client id from the publisher), token (a key in the Authorization header), unknown",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "authMetadata": {
+ "anyOf": [
+ {
+ "additionalProperties": {},
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "authorizationServers, scopesSupported, dynamicRegistration, pkce, grantTypes, from the OAuth metadata"
+ },
+ "authScheme": {
+ "description": "The WWW-Authenticate scheme of a server that needs auth",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "claudeError": {
+ "description": "Why the Anthropic endpoint refused to count",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "claudeModel": {
+ "description": "The model the exact count is for",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "claudeTokens": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Exact count from the Anthropic count_tokens endpoint, names as published"
+ },
+ "claudeTokensClaudeCode": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "The exact count with the Claude Code prefix mcp__<server>__ on each tool name"
+ },
+ "host": {
+ "description": "The endpoint host",
+ "type": "string"
+ },
+ "httpStatus": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "The HTTP status of the first response"
+ },
+ "latencyMs": {
+ "additionalProperties": false,
+ "properties": {
+ "initialize": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "milliseconds"
+ },
+ "toolsList": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "milliseconds"
+ }
+ },
+ "type": "object"
+ },
+ "name": {
+ "description": "The registry name, io.github.owner/name",
+ "type": "string"
+ },
+ "page": {
+ "description": "The server's page on the board",
+ "type": "string"
+ },
+ "probedAt": {
+ "description": "ISO 8601 time of the probe",
+ "type": "string"
+ },
+ "protocolVersion": {
+ "description": "The MCP protocol version the server negotiated",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "shareOf200k": {
+ "description": "Percent of a 200k window, exact when claudeTokens is present",
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "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; package servers also install_failed, no_bin, needs_env, needs_args, needs_network, crashed",
+ "type": "string"
+ },
+ "statusLabel": {
+ "description": "The status in words, as the board shows it",
+ "type": "string"
+ },
+ "title": {
+ "description": "The title the registry gives",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "toolCount": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "How many tools tools/list returned"
+ },
+ "toolsTokens": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "o200k_base estimate over the compact JSON of the tool definitions; the exact count is about 1.9 times this at the median"
+ },
+ "toolsTokensNote": {
+ "type": "string"
+ },
+ "topTools": {
+ "anyOf": [
+ {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "name": {
+ "type": "string"
+ },
+ "tokens": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "name",
+ "tokens"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "The five most expensive tools: name and o200k_base tokens"
+ },
+ "url": {
+ "description": "The endpoint the board probes",
+ "type": "string"
+ }
+ },
+ "required": [
+ "name",
+ "host",
+ "status",
+ "page",
+ "url",
+ "statusLabel",
+ "probedAt"
+ ],
+ "type": "object"
+}registry_summary1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "authKinds": {
+ "additionalProperties": {
+ "type": "number"
+ },
+ "description": "Servers that need auth, per kind of access: oauth-dcr, oauth, token, unknown",
+ "type": "object"
+ },
+ "authSchemes": {
+ "additionalProperties": {
+ "type": "number"
+ },
+ "description": "Servers that need auth, per WWW-Authenticate scheme",
+ "type": "object"
+ },
+ "byStatus": {
+ "additionalProperties": {
+ "type": "number"
+ },
+ "description": "Servers per status",
+ "type": "object"
+ },
+ "claudeTokens": {
+ "additionalProperties": {},
+ "description": "Exact Claude counts: model, counted, refused, median, p90, p99, max, histogram, ratioToEstimate",
+ "type": "object"
+ },
+ "ok": {
+ "description": "Servers that answered initialize and tools/list",
+ "type": "integer"
+ },
+ "probed": {
+ "description": "Servers probed in this run",
+ "type": "integer"
+ },
+ "probedAt": {
+ "description": "ISO 8601 time of the run",
+ "type": "string"
+ },
+ "protocols": {
+ "additionalProperties": {
+ "type": "number"
+ },
+ "description": "Alive servers per negotiated protocol version",
+ "type": "object"
+ },
+ "registryEntries": {
+ "description": "Entries in the registry",
+ "type": "integer"
+ },
+ "registryWithRemote": {
+ "description": "Entries with a remote endpoint",
+ "type": "integer"
+ },
+ "toolCount": {
+ "additionalProperties": {},
+ "description": "median, p90, max",
+ "type": "object"
+ },
+ "toolsTokens": {
+ "additionalProperties": {},
+ "description": "o200k_base estimate: median, p90, p99, max, total",
+ "type": "object"
+ },
+ "transports": {
+ "additionalProperties": {
+ "type": "number"
+ },
+ "type": "object"
+ }
+ },
+ "required": [
+ "probedAt"
+ ],
+ "type": "object"
+}search_servers6 fields changedInput schema / properties / cursor / descriptionPrevious value: -"The `next` value of a previous answer, to continue from there"New value: +"The `next` value of a previous answer, to continue from there; replaces page"Input schema / properties / page / descriptionAdded value: +"Page number, 1 to 20, twenty servers each; default 1. Not with cursor."Input schema / properties / query / descriptionPrevious value: -"Words to match, three or more characters each"New value: +"Words to match, three or more characters each, as prefixes: \"git copilot\" finds the GitHub Copilot servers. Omit for the whole list."Input schema / properties / sort / descriptionAdded value: +"claude = exact Claude tokens, highest first (default); claude-asc = lowest first; tokens = the o200k_base estimate; tools = tool count; latency = initialize time; name; updated = registry date"Input schema / properties / status / descriptionPrevious value: -"ok = answers and lists tools"New value: +"ok = answers and lists tools; auth = needs credentials; payment = 402; newer_protocol = a protocol newer than the SDK; down = every other failure. Omit for all."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "hasNext": {
+ "type": "boolean"
+ },
+ "next": {
+ "description": "The cursor for the next page, when hasNext",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "page": {
+ "description": "The page number, absent when a cursor was used",
+ "type": "integer"
+ },
+ "servers": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "claudeTokens": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Exact count from the Anthropic count_tokens endpoint, names as published"
+ },
+ "host": {
+ "description": "The endpoint host",
+ "type": "string"
+ },
+ "name": {
+ "description": "The registry name, io.github.owner/name",
+ "type": "string"
+ },
+ "page": {
+ "description": "The server's page on the board",
+ "type": "string"
+ },
+ "protocolVersion": {
+ "description": "The MCP protocol version the server negotiated",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "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; package servers also install_failed, no_bin, needs_env, needs_args, needs_network, crashed",
+ "type": "string"
+ },
+ "title": {
+ "description": "The title the registry gives",
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "toolCount": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "How many tools tools/list returned"
+ },
+ "toolsTokens": {
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "o200k_base estimate over the compact JSON of the tool definitions; the exact count is about 1.9 times this at the median"
+ }
+ },
+ "required": [
+ "name",
+ "host",
+ "status",
+ "page"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "sort": {
+ "description": "The sort that was applied",
+ "type": "string"
+ }
+ },
+ "required": [
+ "sort",
+ "hasNext",
+ "servers"
+ ],
+ "type": "object"
+}search_servers1 field changedInput schema / properties / page / maximumPrevious value: -1000New value: +20search_servers1 field changedInput schema / properties / page / maximumPrevious value: -20New value: +1000check_serverlookup_serverregistry_summarysearch_serversSearch and browse every MCP server in the Model Context Protocol registry.
Live public MCP Index. Search, recommend, and call healthy MCP servers.
Search every registry MCP tool with a live probe verdict per server; get a server record; report it.
Look up MCP Registry declarations, npm package status, and daily observations of MCP servers.
Add one secure layer between your agents and this server.