mcpcost

Registry summary

registry_summary

Read-onlyIdempotent

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.

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 25, 2026

addedOutput schema / properties / noAnswer

Added 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"
+}

Changed1 schema field changedOct 24, 2026

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"
+}

First observedOct 15, 2026

TDQS

A4.6/5.0

Behavior4/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

All mcpcost tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.