MCP Observatory: one read only walk over every https endpoint in the official registry

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

With no annotations, the description carries the full burden. It discloses that the data is empirical ('observed in the wild'), includes counts, and is not an invented specification. This is meaningful behavioral context for a zero-parameter reference tool. It doesn't describe return formatting, but the scope is simple enough that the description adds adequate transparency.

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?

The entire description is one sentence that front-loads the subject and scope, adds the key detail about counts, and closes with an important caveat. Every clause earns its place; there is no 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?

For a zero-parameter tool with no annotations and no output schema, the description is nearly complete: it says what data is covered, its provenance, and that it contains counts. The main missing piece is an explicit statement of what the returned data structure looks like, but the description gives enough for an agent to know what the tool offers.

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?

The tool has zero parameters, so the baseline is 4. The description doesn't add parameter-specific detail because there are none to document. This is appropriate.

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 clearly identifies the tool as an observational guide to field names used by 152 servers to disclose operator compensation, with counts. It uses specific nouns ('field names observed in the wild') and specifies the scope ('the 152 servers'). It doesn't use an action verb like 'retrieve' or 'list', and doesn't name a sibling, so it earns a 4 rather than a 5.

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?

The description implies usage: when you need to know how servers actually disclosed operator compensation, consult this guide rather than a specification. The phrase 'Not a specification we invented' implicitly warns against treating it as normative. However, it gives no explicit comparison with sibling tools like lookup, method, or summary, so it stops at implied usage.

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

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

There are no annotations, so the description carries the burden. The past-tense 'what happened when we contacted' plus 'returns the record hash and the procedure to recompute it' conveys that this is a historical lookup with a defined output. It does not discuss side effects, but none are implied for a lookup tool.

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 short sentences, each earning its place: one states the core operation, one states the return value, and one states a critical caveat. There is no filler or redundant repetition of schema details.

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 simple two-parameter lookup with no output schema, the description covers the operation, the return content, and the prerequisite. The only slight gap is that it never explicitly says to provide exactly one of host or address, though 'one address, or an aggregate for one host' strongly implies it.

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 both host and address already have descriptive schema entries. The description rephrases the one-address-versus-host distinction but does not add significant new parameter meaning beyond what the schema provides, 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 operation: look up what happened for one address or a host aggregate, and returns the record hash plus recomputation procedure. It also explicitly disclaims address listing, which distinguishes this tool from any sibling that might appear to list observatory data.

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?

The description provides an explicit prerequisite: the caller must already hold the address or host because there is no listing tool. It does not name sibling alternatives directly, but the warning about not being able to list addresses gives clear context for when this tool can and cannot be used.

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

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

With no annotations present, the description carries the full burden of behavioral disclosure. It does this thoroughly: read-only, no tool called, robots.txt honored, no record mutation, rate limited, and contacts an external server on the user's behalf. This gives the agent a clear safety and side-effect profile.

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?

The description is four short sentences, each earning its place: main action, read-only confirmation, robots.txt behavior, non-mutation, and rate limiting. It is front-loaded with the core purpose and contains no 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?

For a single-parameter network-probing tool with no output schema, the description covers what it does, what it reports, its safety constraints, and its side-effect boundary. An agent has enough context to decide when to invoke it and what to expect from the result.

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?

The schema already fully documents the single parameter, address, with format and example guidance. The description does not add new parameter-level meaning beyond confirming it is a single https address, so the baseline of 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 uses a specific verb and resource: 'Contact one https address now and report what we see,' followed by the exact three checks it performs. It also distinguishes itself from the broader observatory workflow by stating it does NOT change the published record, which separates it from the next full walk.

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 gives clear context: use this for an immediate, one-off live probe of a single address, and explicitly states what it is not for by saying 'This does NOT change the published record - the next full walk does that.' However, it does not explicitly name sibling alternatives like lookup or state for reviewing existing records.

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

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

No annotations are provided, so the description carries the full burden of disclosing behavior. It does not say whether the tool is read-only, what it returns, or whether it has side effects. The mention of mistakes and corrections adds content-level transparency but not operational transparency.

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?

The description is a single compact sentence with no redundancy. It front-loads the main idea and lists three substantive aspects, though the phrasing is somewhat elliptical and could be clearer about the tool's action.

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 zero-parameter informational tool the description is serviceable: it tells the user what content the method covers. However, it omits what the tool returns and when to call it, and with no output schema or annotations the agent receives no additional context to compensate.

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?

The tool has zero parameters and schema coverage is 100%, so the baseline of 4 applies. The description does not need to explain parameters because there are none.

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 the subject matter clearly enough: it explains how the walk was run, what was corrected, and the four rules. However, it lacks a verb and never states what the tool actually does—whether it returns, displays, or reports this information. The purpose is inferred rather than explicit.

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?

The description provides no guidance on when to use this tool versus siblings like mcp_observatory_summary, mcp_observatory_state, or mcp_observatory_disclosure_guide. An agent must guess from the tool name and context when this tool is the right choice.

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

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

With no annotations provided, the description carries the full behavioral burden. It discloses the type of information the tool provides: what was measured, when, over what population, and caveats about what the measurement cannot tell you. This is meaningful behavioral context beyond the tool's name.

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?

The description is two short sentences with no wasted words. The first sentence lists exactly what content to expect, and the second provides a direct usage instruction. It is tightly structured and easy to parse.

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 zero-parameter, stateless informational tool, the description covers the essential context an agent needs: what the tool reports and when to use it. It does not describe output formatting or return structure, but there is no output schema and the tool's purpose is simple enough that this is not a major gap.

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?

The tool has zero parameters and 100% schema description coverage, so there are no parameter semantics to clarify. The description appropriately focuses on the tool's output and usage intent rather than inventing parameter detail.

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 clearly communicates what the tool returns: the scope and limitations of measurements on this server. It is specific enough to orient an agent, though it does not explicitly contrast itself with the sibling 'summary' or 'method' tools, so some differentiation is left to inference.

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 gives an explicit usage rule: 'Read this before quoting any number from this server.' This tells the agent when the tool is appropriate and frames it as a mandatory prerequisite for citing data. It does not name alternatives or exclusions, but the guidance is actionable and context-rich.

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

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

With no annotations, the description carries the burden of disclosure. It usefully reveals that the tool reports counts rather than raw records and distinguishes published vs corrected numbers. However, it does not explain what 'published' vs 'corrected' means, the response format, or any limitations.

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?

The description is very short and every sentence contributes information about the content of the summary. The opening fragment 'The counts, as published and as corrected' is slightly cryptic but not padded or 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?

For a no-input, no-output-schema tool, the description gives a reasonable overview of what is counted but leaves important gaps: the published/corrected distinction is unexplained, no return structure is described, and sibling differentiation is absent. An agent could call it correctly but may not understand the full result.

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?

The tool has zero parameters, and the empty schema already communicates that. The description adds relevant context about what the parameterless summary measures, which is sufficient.

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 the resource (the summary) and specifies exactly what it contains: counts of addresses that answered, tools exposed, and operators disclosing compensation. It is not a tautology and clearly points to an aggregate reporting tool, though it relies on a noun phrase rather than an explicit verb like 'returns' or 'provides'.

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?

The description implies the tool is used when aggregate counts are needed, but it gives no explicit guidance about when to prefer this over siblings like lookup, state, or method. There are no stated exclusions or alternative conditions.

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