verifier

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

With no annotations, the description carries the transparency burden. It discloses that the tool returns change data (diff) and lists the categories of changes, making the behavioral scope clear. It does not discuss output format or side effects, but as a read-only query this is acceptable.

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 packs the purpose, content, and usage tip into a compact form. Every phrase is informative, with 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 diff tool with no output schema, the description provides a complete overview: what it returns, when to use it, and the date format. It could benefit from explaining the response structure, but the sibling context and simplicity make it sufficient.

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 fully describes the 'since' parameter (YYYY-MM-DD, omit for latest diff), so the baseline is 3. The description reinforces the date concept but adds little beyond the schema, so it doesn't warrant a higher score.

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 a diff/report of changes in the tool economy since a date, enumerating specific change types (verdict flips, deaths, revivals, new servers, confirmed drift). This distinguishes it from sibling tools like registry_pulse (likely a snapshot) and find_tools (search).

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 advises polling weekly to keep a local view current without re-crawling, which conveys a clear usage pattern. It also implies this is a delta update rather than a full crawl, though it doesn't name alternative tools for when not to use it.

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 of behavioral disclosure. It details the complete response structure, including the verdict, rating groups (REACH, USE, TRUST), cluster tag, distinctiveness score, and not_claimed block, giving the agent a clear picture of what to expect. However, it does not explicitly mention error handling or prerequisites beyond the exact name requirement, but the read-only nature is strongly implied by 'evidence behind the verdict'.

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 moderately long but efficiently packs the tool's purpose, usage, and return structure into a few sentences. The detailed REACH/USE/TRUST breakdown may be dense, but every clause adds value, making it appropriately sized for a complex evidence-returning tool.

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?

This tool has no output schema, so the description must explain return values, and it does so extensively by listing all rating groups and their fields. It also provides context on how to use it relative to should_i_use, covering the main operational decisions, though it omits explicit error/not-found behavior.

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 already contains a description for the 'name' parameter with an example, and the tool description reinforces 'by exact registry name'. Since schema coverage is 100%, the description adds minimal additional param semantics beyond restating the exactness requirement, meriting the baseline score.

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?

Description opens with 'The FULL evidence behind the verdict for ONE server, by exact registry name', which clearly identifies the tool's function as retrieving complete evidence for a single server. It explicitly differentiates from sibling should_i_use by stating 'call should_i_use first for the one-word decision; call this when you want the whole record.'

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 explicit usage guidance: 'call should_i_use first for the one-word decision; call this when you want the whole record.' This directs when to use this tool versus the sibling tool, making the usage context unmistakable.

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 transparency load. It discloses key behaviors: full-text stemmed BM25 search, ranking order (best-rated first), dead/costume-farm/walled servers sink, and each row's contents (verdict, cluster, distinctiveness, matching tool names). This goes well beyond a basic description, though it omits details like pagination or exact response format.

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 longer than average but every sentence adds value: examples, search mechanics, output contents, ranking criteria. It is front-loaded with the main purpose and then details behavior. Slightly dense but not wasteful; appropriate for the tool's complexity.

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?

Despite no output schema and no annotations, the description fully explains what the tool returns (each row carries verdict, cluster, distinctiveness, matching tool names), how results are ranked, and how to formulate queries. It gives enough context for an agent to select and invoke the tool correctly without further calls. The 6 parameters are all covered by the schema, and the description fills the gaps for the key 'need' parameter and the response structure.

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 description coverage is 100%, so the baseline is 3. The description enhances the primary 'need' parameter with examples and explains how the search interprets it ('your words need not appear in any tool's name'). It also explicitly names the argument ('Argument: need'), adding clarity beyond the schema. The other parameters are well-covered in the schema and need no extra elaboration.

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 states a specific verb + resource: 'Find and RANK the trustworthy tool for a NEED.' It explains full-text search over tool names and descriptions with BM25 ranking, clearly distinguishing this from sibling tools like check_server or list_findings. Concrete examples ('screen a company for sanctions', 'US tariff data') reinforce the 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 gives clear usage instructions: describe the task in plain words, and explains that the search is full-text so exact tool names are not required. It also tells the agent when to pick from results ('you can pick without a second call') and how servers are ranked (alive, non-costume, current-protocol on top). It lacks an explicit statement of when NOT to use this tool, but the context implies it is the primary discovery mechanism.

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.

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

With no annotations provided, the description fully carries the transparency burden. It discloses fire-and-forget semantics, the discard rule ('a 'worked' report on a server we saw dead is discarded'), the accumulate-only behavior ('Does NOT change the current rating yet'), and the binding via call_hash. This is rich behavioral context beyond what any schema or annotation might provide.

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 moderately sized but dense and purposeful. It front-loads the core purpose, adds key behavioral caveats, and ends with a clear args list. Every sentence earns its place, though the phrasing is somewhat jargon-heavy ('outside-in probing', 'load-bearing') which slightly reduces clarity.

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 six-parameter tool with no output schema and no annotations, the description provides strong context: what, when, why, and key behavioral rules. It explains the data flow to the observatory and the anchoring against probes. Minor gaps include no explicit mention of what the tool returns, but the word 'fire-and-forget' implies no meaningful return value.

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 description coverage is only 17%, so the description must compensate. It does by explaining 'ok' as success/failure, latency_ms as latency, cost_tokens as cost, and call_hash as 'a hash binding the report to a real call.' While not every parameter gets a dedicated line, the narrative plus the args list provide sufficient semantic grounding.

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: 'AFTER your agent calls a tool, fire-and-forget how it went — success/failure, latency, cost.' It identifies a specific verb (report), resource (how a tool call went), and distinguishes itself from siblings like check_server and should_i_use by being a post-call observability feedback mechanism.

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 to use it after an agent calls a tool ('AFTER your agent calls a tool') and clarifies it is fire-and-forget. It also states an important exclusion: 'Does NOT change the current rating yet (probing stays load-bearing).' While it doesn't name sibling alternatives, the timing and exclusion make usage clear.

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 discloses that matching is against registry names only, returns candidate names with liveness outcomes, and rejects empty queries. It does not explicitly state read-only status or behavior on no matches, but the phrasing implies a read-only resolution operation, making it fairly transparent.

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 three sentences with no wasted words. The first sentence states the purpose and usage context, the second clarifies the scope and alternatives, and the third states the return value and rejection behavior. Every sentence 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?

The tool is simple (one parameter, no output schema), and the description provides all necessary context: what it does, when to use it, what it returns, and an edge-case behavior (empty query rejected). It fully compensates for the lack of an output schema by describing the return format meaningfully.

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 description coverage is 100% for the single 'query' parameter, which is described as 'a fragment of a registry name'. The tool description adds context beyond the schema by clarifying that the query is matched against registry NAMES only (not capabilities), reinforcing the fragment semantics. This adds meaningful value over the schema alone.

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: resolving a partial or misspelled server name to its exact registry ID. It specifies the verb 'Resolve', the resource (server name), and the output (exact registry id), while also distinguishing itself from sibling tools like find_tools by noting it matches against names only, not capabilities.

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?

Explicitly instructs to use this tool before calling should_i_use / check_server, and provides an explicit alternative for capability-based queries ('for "which tool does X" use find_tools'). This gives clear when-to-use and when-not-to-use guidance.

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 clearly discloses the tool's main behavior: returns a verdict, a reason, and the full rating, and defines each verdict value. However, it does not mention potential edge cases like network failures, timeout behavior, or whether the tool has any side effects, though the mutating nature is clearly absent from the 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 front-loaded with the core command ('THE GATE — call this before...'), then delivers verdict semantics and alternatives in a compact, scannable format. Every sentence adds necessary information, and the example is valuable for parameter format.

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?

The description explains the return value (one-word verdict, reason, full rating) and the meaning of each verdict, which is essential given the absence of an output schema. It also covers sibling alternatives. It could be more complete by mentioning the batch 'names' parameter and error handling, but overall it is sufficiently complete for a simple vetting tool.

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 description coverage is 100%, so the baseline is 3. The description adds a concrete example and stresses 'exact' registry name, which reinforces the 'name' parameter. However, the narrative only mentions 'name' and omits the 'names' array parameter, although the schema already documents it fully, so no significant gap exists.

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 action: 'call this before your agent depends on a tool you don't already trust' and specifies the resource (exact server registry name) and output (one-word verdict allow/warn/block with reason and full rating). It also distinguishes itself from siblings by explicitly directing users with a 'NEED' to find_tools and those with a 'fuzzy name' to resolve_server_name.

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?

Usage context is explicit: use before depending on an untrusted tool. It also provides concrete alternatives for different situations ('If you have a NEED not a name, use find_tools; if you have a fuzzy name, use resolve_server_name'), and explains the meaning of each verdict ('block' = don't depend, 'warn' = look first, 'allow' = safe to depend).

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