Anchor Terminal

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

Annotations already declare readOnly/openWorld/idempotent/non-destructive, and the description adds substantial context beyond them: it never invokes the server's tools, requires public HTTPS endpoints, sends no credentials, and is rate-limited to a few checks per ten minutes. These are exactly the operational facts an agent needs before calling.

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 purpose and the 'use before adding an unknown server' directive are front-loaded, and no sentence is filler. The first sentence is long and heavily comma-listed, which costs some immediate readability, keeping it short of a 5.

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 two-parameter audit tool with no output schema, the description covers what is inspected, the safety profile, rate limits, and the local-server fallback. The enumeration of individual checks is deferred to an external URL, a minor gap for an agent that wants the full checklist inline.

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 parameters (url, budget) are documented in the schema itself. The description only loosely connects to `budget` via 'what the list costs in tokens' and adds no syntax or format detail beyond the schema, 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 states a specific verb and resource — read another MCP server's tool list and report issues such as tool poisoning, contradictory safety hints, undocumented parameters, and token cost. It is clearly distinct from siblings like compare_tools and get_tool, which operate on the already-known catalog rather than probing an unknown remote server.

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 explicit timing ('Use it before adding a server you don't know') and explicit exclusions with an alternative ('For local servers or ones that need a key, run anchor check on your own machine'). It also states access preconditions (HTTPS/public addresses, no credentials), which further scopes when this tool applies.

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?

Annotations already declare readOnly, idempotent, non-destructive behavior, so the description is free to focus on output shape, which it does well: it lists the comparison dimensions and the mismatch-handling branch that returns a short explanation rather than an error. That edge-case behavior is genuinely useful context beyond the annotations, though it does not mention any limits or failure modes for bad slugs.

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 purpose is front-loaded in the first clause, and the enumerated output contents are dense and useful. The closing format sentence overlaps with the schema's format enum, a minor redundancy, but overall the description is efficient.

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?

With annotations covering safety and no output schema, the description is complete enough for an agent to know what it will receive and how mismatched pairs are handled. It could add guidance on resolving invalid slugs or when comparison is preferable to two single lookups, but the core behavior is covered.

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%, so both listing identifiers and the format enum are already fully documented. The description only restates the format options (markdown default, slim, json), adding slight emphasis on the default but no syntax or behavior beyond the schema; baseline 3 applies when the schema does the heavy lifting.

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?

States a specific operation (two listings head to head) and enumerates exactly what the output contains: category-by-category scores, side-by-side facts, verdicts, agent notes. It is clearly distinguishable from single-listing siblings like get_tool because it explicitly takes a pair and frames the result as a comparison.

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 is implied by 'two listings head to head' and the note that mismatched pairs get a short explanation, but there is no explicit when-to-use statement or routing to alternatives such as calling get_tool twice or using search_tools to resolve slugs. The schema mentions search_tools for slugs, but the description itself offers no such 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?

Goes well beyond the annotations by disclosing rate limits (three an hour, ten a day per address), that a human replies to email, that the reply carries a reference id, and that one call suffices. These are operational facts an agent cannot infer from destructiveHint=false / idempotentHint=false.

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?

Purpose is front-loaded in the first clause, then constraints, then the kind taxonomy. Dense parenthetical shorthand ('waitlist (product letme, only email needed)') is efficient but slightly cryptic. No sentences are purely 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?

With 8 parameters, no output schema, and a mutation-style tool, the description covers the essentials: what is sent, where it goes, throughput limits, and what comes back. It omits which optional parameters matter per kind, though the schema descriptions cover that 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?

Schema coverage is 100% and the enum descriptions already spell out every kind, so the description's kind list largely restates structured data. It adds only marginal detail, such as 'waitlist (product letme, only email needed)', which is also in the schema. Baseline 3 is the right call when the schema carries the load.

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?

States a specific verb and recipient ('Sends a message to the Anchor Terminal team') and clarifies the channel is the same one the site's forms use, with a human replying by email. An agent can tell it is a contact-form tool. It does not distinguish itself from the sibling file_issue, which is the one adjacent tool an agent might confuse it with.

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?

'Use it only when your user asks you to get in touch' is an explicit inclusion rule plus an exclusion, rare in this dataset. The per-kind mapping (listing needs url, claim/dispute concerns a listing, waitlist needs only email) gives concrete routing guidance for each use case.

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?

Annotations already flag this as a non-destructive mutation, but the description adds substantial context beyond them: rate limits (10/hour, 40/day per address), the signature requirement using the review Ed25519 key, and refusal rules for PII, secrets, links, and security reports. This is exactly the kind of consequence and constraint disclosure 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and scope are front-loaded and every clause carries real information (JSON shape, signing, privacy, security redirect, rate limits). It loses a point for being a single dense run-on block where the embedded JSON spec is hard to parse in prose form.

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?

With no output schema, the description never says what comes back (issue URL or id, confirmation), which an agent would want after filing. Everything else an agent needs to invoke it correctly — body contract, signing, limits, refusals — is present.

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%, but the schema only says body is 'JSON text'. The description supplies the entire effective contract for body — kind, about, listing, title (120 char cap), text (1,200 cap), called, calledAt — and clarifies that key/signature are the base64url Ed25519 pair over those exact bytes. This is far more than 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?

States a specific verb and resource (files an issue) plus the destination (/issues/) and its public, readable-by-anyone nature. It also enumerates the subject matter (site bugs, API, MCP server, listing corrections) so an agent can tell it apart from contact and submit_review.

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?

Explicit when-to-use (bug on site/letme.dev/API/MCP, wrong score or fact) and when-not (never security problems, which go to /.well-known/security.txt; such filings are refused). It names the alternative channel directly rather than leaving routing to inference.

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?

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds genuinely non-structured behavior: results are sorted cheapest first, the payload includes input/output prices, a blended 3:1 figure, context size, supported features, rate-limit docs, and that units appear in the result.

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?

It is a single run-on sentence built from stacked parentheticals, which makes it hard to parse and pushes the key mode distinction (models vs. unit-based tool prices) into the middle. The information is compact but not front-loaded or structured.

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?

With no output schema, the description must carry return-value burden, and it does list the returned fields, the sort order, and that units are echoed in the result. Only the exact response shape and error/empty-result behavior remain unspecified.

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%, so both parameters are already documented and a 3 would be the baseline. The description adds meaning beyond the schema by defining the 'blended 3:1' ratio and clarifying that an empty unit means model tokens while a unit value switches to per-call tool pricing.

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 identifies the resource (model token prices per million, or per-call prices for tools when a unit is set) and the ordering (cheapest first), so an agent can infer this is a pricing lookup. However it is a verbless noun phrase with no explicit statement of what the tool does, and it never differentiates itself from siblings like compare_tools or get_tool.

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 'or with unit set ... per-call prices for tools' clause implies the two modes (models vs. tools) and thereby when to supply a unit, but this is only implied. There are no explicit when-to-use/when-not statements and no mention of when to prefer compare_tools or get_tool instead.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered structurally. The description adds genuine behavioral context beyond that: the three output formats including a token-minimizing 'slim', and the important fallback that a registry server absent from the directory still returns its registry entry. It doesn't mention rate limits or error behavior, which keeps it below 5.

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 core action and identifier source are front-loaded in the opening clause, and nearly every phrase carries new information. It loses a point for being a single long comma-spliced sentence that takes effort to parse rather than being broken into distinct statements.

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?

With no output schema, the description appropriately carries the burden of describing the return payload field by field, which it does. Coverage of format trade-offs and slug resolution is sufficient for correct invocation; only minor gaps like pagination or error shape remain, and those are not essential here.

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%, so the baseline is 3. The description still earns credit above baseline by explaining that the slug accepts alternative identifiers (package name, GitHub owner/repo, registry name) and that the response reports which slug the input resolved to — resolution semantics the schema description only partially conveys.

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?

States a specific verb and resource ('One listing in full by its slug') and immediately ties the slug source to the sibling search_tools, so an agent can distinguish retrieval from discovery without opening a schema. The enumerated payload (snippets, auth, prices, provenance, hosted tools, changes) makes the scope concrete.

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 parenthetical '(from search_tools)' establishes the expected workflow: search first, then fetch by slug. The format note gives a hint about when to prefer slim over json, but there is no explicit statement of when not to use this tool or which siblings (e.g. check_server, verify_listing) cover overlapping ground.

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?

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower; the description adds genuine behavioral context by disclosing return shape (capabilities grouped with their listings) and ordering semantics ('best first'), which no output schema provides. It stops short of describing pagination or how many results come back.

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?

Two short clauses with no filler; what is returned comes first and the parameter note follows. Slightly telegraphic ('best first') but every phrase carries information.

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?

With no output schema, the description must convey what comes back, and it does (capabilities plus their listings, ranked). A single optional filter keeps complexity low, so this is nearly enough; only result volume / pagination behavior is unaddressed.

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% and the prefix parameter is already documented with examples in the schema. The description's 'prefix narrows it, e.g. web.' largely restates that, adding only the 'starts-with' narrowing intent rather than new format or edge-case 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?

States a specific verb+resource: lists every capability the directory tracks with the listings providing it. The parenthetical examples (inference.llm, web.search, …) make the resource concrete and distinguish it from sibling tools like search_tools or get_tool, though it never explicitly contrasts with search_tools.

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 is only implied: 'prefix narrows it, e.g. web.' suggests a browse-then-narrow flow but does not say when to call this versus search_tools, or that it should be used for discovery rather than lookup.

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?

Annotations already declare readOnly, idempotent, non-destructive, and non-open-world behavior, so the safety profile is covered. The description adds meaningful return-format context by saying the page is returned as Markdown matching what a person reads and by naming the slim/json alternatives, though it does not discuss errors, rate limits, or pagination.

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 compact and front-loads the main capability before listing examples and parameter details. The first sentence is dense with a long example list, but no sentence is wasted.

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 read-only page fetcher with full schema coverage and rich annotations, the description supplies the needed scope, examples, output format, and a pointer to the agent guide. Nothing essential for correct invocation appears to be missing.

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%, so both parameters are already documented in the schema. The description restates that path is the page's path and that format defaults to markdown with slim and json options, but adds little syntactic or semantic detail beyond the schema itself.

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 and resource: reading any page of anchorterminal.com as Markdown. It enumerates representative page types (/top/, /categories/search/, /benchmark/, /prices/, /sunsets/, /agents/), which makes the scope concrete and distinguishable from structured sibling tools like get_tool or get_prices.

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 clearly establishes when to use this tool: to fetch any human-readable page of the site. The examples imply broad page-reading coverage, but it does not explicitly say when to prefer get_tool, get_prices, or search_tools instead, so it stops short of full alternative routing.

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?

Annotations already cover read-only/idempotent safety, and the description adds genuinely non-obvious behavior: results come in three ordered tiers with different evidence provenance, and filters apply unevenly across tiers. That scoping rule is exactly the kind of thing an agent could not infer and would otherwise get wrong.

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 sentences, front-loaded with the core purpose before the tier detail. The final sentence is long and packs several clauses, but every clause carries distinct information about result ordering or filter scope.

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?

With no output schema and 20 parameters, the description carries the return-value burden and does it well by naming the tiers and their fields (grade, score, x402, agent-ready). It does not address how many indexed/registry results come back or whether limit governs them, a modest gap for a search 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 coverage is 100%, so the baseline is 3, and the description earns an extra point by disclosing the AND-semantics of q and which filters are honored on which result tiers. It stops short of explaining defaults such as limit applying only to graded listings, which is left to the schema.

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?

States a specific verb and a broad but enumerated resource set ('tools, APIs, MCP servers, models and data providers') and immediately clarifies it is a directory search rather than a fetch, distinguishing it from siblings like get_tool and list_capabilities. The three-tier return structure further pins down what kind of result the agent gets.

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?

Explains the matching rule ('every word in q has to match') and routes to /benchmark/ and /categories/ plus list_capabilities for capability ids, which is real usage guidance. It does not explicitly say when to prefer it over get_tool or compare_tools, so the alternative-routing is implied rather than stated.

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?

Beyond the annotations (idempotentHint=true, readOnlyHint=false), the description discloses substantial behavior: publishing is immediate, effectiveness depends on evidence, x402 payments are checked by hand, account/proof are kept private, and the reply states what would raise it. This is rich context the annotations do not carry.

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?

Purpose is front-loaded, but the remainder is a single dense run-on laced with nested parentheses that is hard to parse on first read. Every clause carries information, yet the packing hurts scanability.

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 complex tool with nested objects and no output schema, the description covers both submission methods and gestures at the post-submit reply. It stops short of detailing the response, but the evidence-scoring concept is explained well enough to call it correctly.

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% so baseline is 3, but the description goes further by spelling out the JSON body fields (tool, rating, outcome, text, etc.) that the schema's body param only labels generically as 'the review as JSON text.' This adds real meaning about what to put in body.

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 opening sentence 'Publish a review of a listing you used' states a specific verb and resource, and the two submission paths are clearly named. It does not differentiate from siblings like file_issue, but the publish-a-review scope is unmistakable.

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 two concrete paths (raw body+key+signature vs signed envelope) and explains that a review 'counts for little until evidence of use backs it,' which sets expectations. There is no explicit when-not/routing-to-alternative guidance against siblings, keeping it short of a 5.

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?

Annotations only say readOnlyHint=false, idempotentHint=true and openWorldHint=true; the description explains why — one fetch of a public page with no credentials, redirects confined to the domain, result persisted and re-checked weekly. It also discloses concrete rate limits (ten an hour per address, twenty a day per listing) and the crucial side-effect boundary that grades/ranks/reviews are untouched.

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?

Front-loaded with the core mechanism, then constraints, then the use-condition and rate limits; nearly every clause carries information. It is a dense single paragraph, so the operational caveats (limits, weekly re-check) are buried mid-flow rather than being easy to scan.

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 two-parameter write-ish operation with no output schema, the description covers inputs, network behavior, persistence, side effects and throttling — enough to call it safely. It does not say what the caller receives (verified/pending/failed), which is the one gap an agent must discover at runtime.

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 schema field descriptions already state the accepted URL locations and the slug forms. The prose largely restates those constraints ('on the listing's own domain, or in the README of its repository on GitHub'), adding only the fetch-scope detail rather than new per-parameter meaning, 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?

States a specific verb (verify/prove) and resource (a listing, on behalf of its vendor) plus the exact evidence it looks for (/badges/{slug}.svg or /tools/{slug}). An agent can distinguish this from check_server, get_tool or read_page without opening any schema.

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?

Explicit gating condition: 'Use it only when your user runs the product and has put the link there,' which excludes the common misuse of verifying someone else's listing. It also pre-empts a false expectation by stating it never changes grade, rank or review, and the slug schema note points agents back to search_tools for slug discovery.

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