The MCP Census

Watch an MCP server for changes

census_watch_subscribe

Idempotent

Subscribe this agent (or a human email) to alerts for ONE specific MCP server. Fires only on real observed changes: remote_down, remote_up, health_change, verified_change, security. Requires x-api-key. Prefer webhook_url (https) so your agent can receive POST callbacks; email optional. Returns a watch id + HMAC secret (X-Census-Signature: sha256=…). Free tier: 5 watches; pro: 50.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "server_name": "<server_name>"
    },
    "name": "census_watch_subscribe"
  }
}

Input Schema

Name	Required	Description
`email`	No	Optional human email for the same alerts
`label`	No	Optional agent-chosen label
`events`	No	Subset of remote_down,remote_up,health_change,verified_change,security,tools_changed (default: all)
`server_name`	Yes	Exact registry name to watch
`webhook_url`	No	https URL that will receive signed POST event payloads

Schema Changelog

Changes observed during successful MCP inspections.

AddedSep 1, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Goes well beyond the annotations (which only declare non-readonly, idempotent, non-destructive, closed-world) by disclosing the x-api-key auth requirement, the exact event semantics (fires only on real observed changes), the return payload (watch id + HMAC secret), the signature header format, and free/pro tier quotas. This is the kind of operational context annotations cannot carry.

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?

Six short clauses, front-loaded with the core action and scope, then constraints, then return value and quotas. Every sentence carries distinct information with no 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?

No output schema exists, yet the description explains what is returned (watch id plus HMAC secret) and how callbacks are signed, and it covers auth and quota limits. For a 5-parameter subscription tool, 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 100%, so the baseline is 3; the description still adds preference guidance (webhook_url over email, https required) and clarifies that email is an optional duplicate channel. Minor deduction because its event list omits tools_changed, which the schema documents, leaving a small inconsistency an agent must resolve by reading 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 (subscribe) and resource (alerts for ONE specific MCP server), and emphasizes the single-server scope, which distinguishes it from census_watch_list and census_watch_unsubscribe in the sibling set. An agent can identify this as the creation step of a watch lifecycle without opening the schema.

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

Usage Guidelines4/5

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

Gives clear context for use (subscribe to change alerts for a single server) plus a concrete recommendation: prefer webhook_url over email so the agent receives POST callbacks. It does not explicitly name census_watch_list / census_watch_unsubscribe as the alternatives for listing or removing watches, so the routing guidance is strong but not exhaustive.

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

All The MCP Census tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?