verifier

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

Since annotations are absent, the description fully owns behavioral disclosure. It reveals that the tool performs re-derivation against a public primary source (Tier-2 truth checks) and flags tool-description drift (rug-pull signal), which are non-obvious behaviors. It does not mention side effects or potential failures, but the read-only nature is implied by the 'verification record' framing.

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 information-dense with no fluff, packing multiple data points into a single well-structured sentence. It front-loads the core purpose and uses em-dashes and commas effectively. It is slightly long but every clause adds value.

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?

Without an output schema, the description outlines the return content in plain language, covering the main data points. It also provides prerequisite guidance (find_servers) and an example. It stops short of explaining error handling or output format, leaving a minor gap, but overall it is quite complete for the tool's simplicity.

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 provides zero description for the 'name' parameter, so the description compensates by naming it, specifying it must be an exact registry name, and providing a concrete example ('com.trimtabist/us-tariff-ledger'). This sufficiently clarifies the parameter's meaning for a single-parameter tool.

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 states that the tool returns a full verification record for a single server by exact registry name, and enumerates the specific data points it provides (outcome, tool count, drift signal, verifiability grade, Tier-2 truth checks). This distinguishes it from sibling tools like find_servers (which is for discovery) and list_findings (which is for broader views).

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 explicitly directs users to 'use find_servers first if you don't have it,' establishing a clear precondition and naming a sibling tool as an alternative. It also scopes usage to one exact server, but does not explicitly state when NOT to use this tool or how it compares to registry_pulse.

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 full burden. It discloses that the tool returns matching registry names with each one's latest outcome and rejects empty queries. This adds meaningful behavioral context, though it omits details like case sensitivity or pagination limits.

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 exactly two sentences, front-loaded with the primary action, and includes usage guidance, examples, and a return-value summary without any redundant fluff. Every clause earns its place.

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 one-parameter server lookup, the description covers purpose, usage, return format, and a boundary condition (empty query). It also names a sibling tool for context, making it situationally complete for its complexity.

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 documents the query parameter at 100% coverage with a description and example. The tool description reinforces the fragment substring concept but adds no new parameter syntax or format details beyond what the schema provides.

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 'look up' with a clear resource ('servers by fragment of their registry name') and explicitly distinguishes this from sibling tool check_server by framing it as a discovery step. The examples ('tariff', 'vessel') further cement its purpose.

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 explicitly tells the agent to use this tool to DISCOVER the exact name before calling check_server, which is direct when-to-use guidance. It also provides example queries and notes the empty-query rejection, giving actionable conditions.

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 burden. It offers some behavioral context by stating the corrections log is 'what we published, then corrected, never deleted' and that it is 'public,' implying non-destructive and accessible. However, it does not disclose return format, pagination, or any side effects, leaving gaps typical of a minimal viable description.

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 sentences with no fluff. The first sentence defines what the tool returns, the second gives usage context and confirms no arguments. Every word earns its place, and information is front-loaded.

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-argument list tool with no output schema, the description is sufficiently complete. It describes the content (findings, falsification tests, corrections log), the purpose (citing established knowledge or past mistakes), and the public nature. It does not explicitly state the return type, but the use case implies a list of entries. Given the low complexity, this is nearly complete.

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 0 parameters, so the baseline is 4 per the rubric. The description explicitly states 'No arguments,' which reinforces the empty schema. Since schema coverage is 100% (vacuously), there is no additional parameter meaning needed, though the explicit statement adds a small clarity bonus.

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 states the tool lists the observatory's ruled findings with claims and falsification tests, plus the public corrections log. It provides a specific verb ('list') and resource ('observatory's ruled findings'), and distinguishes itself from server-focused sibling tools (check_server, find_servers, registry_pulse) by focusing on findings and corrections.

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 gives explicit context for when to use the tool: 'Call this to cite what has been established, or to see where we were wrong.' It does not mention alternatives or when-not-to-use, but the purpose is clear enough that the context is unambiguous, especially given the distinct sibling names.

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 transparency burden. It discloses that every number is re-derivable and that grades are observed/reported/derived, giving an honest picture of data provenance. The no-argument, read-only nature is implied by 'state... in one shot', though it does not explicitly rule out side effects.

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 front-loaded with the 'Call this FIRST' directive and uses a compact, dense structure to enumerate all metrics. Every clause adds distinct value; there is no filler or redundancy, ending efficiently with 'No arguments'.

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?

Given the lack of an output schema, the description does a good job describing the expected metrics in prose (server counts, handshake answers, login barriers, costume-farm concentration, Tier-2 summary) and explains the grading approach. It is complete enough for an agent to know what the tool will return, though exact field names are not specified.

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 input schema has zero parameters and the description explicitly states 'No arguments.' This matches the 100% schema-description coverage and the 0-param baseline, so the description adds no further parameter detail because none is needed.

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 states the tool's purpose: provide a one-shot summary of the MCP tool ecosystem, including server counts, handshake success, login barriers, costume-farm concentration, and Tier-2 truth summary. The verb 'Call this FIRST' combined with the explicit list differentiates it from sibling tools like check_server and find_servers.

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 explicitly says 'Call this FIRST', giving clear precedence over sibling tools. It does not enumerate when not to use the tool or mention alternatives, but the 'first' guidance establishes a clear usage context for an initial high-level overview.

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