What happened when we contacted one address, or an aggregate for one host. Returns the record hash and the procedure to recompute it. There is no tool here that lists addresses; you must already hold the one you are asking about.
| Name | Required | Description | Default |
|---|---|---|---|
| host | No | A host, e.g. example.com. Returns counts for that host, not a roster. | |
| address | No | The full declared endpoint, e.g. https://example.com/mcp |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
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.
Add one secure layer between your agents and this server.
Each tool covers a clearly separate concern: aggregate counts, per-address records, live probing, methodology, measurement metadata, and disclosure field names. The only mild overlap (counts in summary vs disclosure_guide) is disambiguated by their descriptions.
All tools share the mcp_observatory_ prefix and snake_case, but the suffixes are mostly nouns (state, summary, method, lookup, disclosure_guide) with one verb-like exception (measure_now). This is a minor deviation rather than a chaotic mix.
Six tools is well-scoped for a read-only observatory server. Each tool adds a distinct capability and none feel redundant or padding.
The surface covers the main tasks: querying recorded results, running a live probe, understanding methodology and limitations, and getting aggregate counts. The notable gap is the explicit absence of any tool listing addresses, but that can be worked around by obtaining addresses from the official registry.