brick.blue

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, and the description reinforces rather than contradicts them while adding genuinely new context: 'no account' (no auth needed) and a preview of return contents. It stops short of noting any rate limits or pagination on the daily tallies.

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 question ('whether one listed agent kept answering'), then supporting detail. It is dense but a touch run-on, packing return contents into a trailing sentence that repeats material already stated earlier.

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?

No output schema exists, so the description carries the return-value burden and does so ('the uptime figures, the daily tallies and the list of changes'), plus the safety and auth posture. An agent has everything it needs to call this 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 0% and the only hint about agentId is the phrase 'one listed agent', which implies the ID must reference a registered/listed agent but gives no format, casing, or lookup guidance. With a single required param and no schema documentation, a 3 is the ceiling for the added meaning here.

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 subject and scope: uptime over 7/30/90 days, daily tallies, and every state change with its underlying error. It explicitly contrasts itself with the sibling get_agent, so an agent can distinguish the two without opening either 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?

'Use it before depending on an agent for repeated calls' names the decision this tool informs, and it names the alternative (get_agent) with the condition that selects it ('shows only its current state'). Both when-to-use and the alternative-routing rule are explicit.

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=true, idempotentHint=true and destructiveHint=false, so safety is covered. The description adds real behavioral value beyond that: the result is a signed document, each signal carries its source, and absent signals appear as «none» rather than being omitted — a return-shape detail an agent cannot get from structured fields.

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?

One front-loaded sentence that leads with the key framing ('everything the hub knows ... as one signed document') before enumerating signals. The long em-dash list is dense but every item is informative; minimal waste.

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 bears the full burden of explaining return content, and it does so by enumerating the signal categories and noting source attribution and «none» placeholders. Coverage of parameter semantics and usage routing is the remaining 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 description coverage is 0% for the single required agentId, so the description carries the burden. It only implies the parameter is an agent identifier ('about an agent') and says nothing about ID format, accepted values, or what happens with an unknown agent.

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 resource and scope: a single signed composite document aggregating every trust signal the hub holds about an agent. This is clearly broader than siblings like agent_liveness or get_agent, though the description never names those siblings to make the boundary 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?

No when-to-use guidance and no alternatives named. The agent must infer from 'everything the hub knows' that this is the holistic trust lookup, but nothing states when to prefer it over agent_liveness, get_agent, or search_agents.

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 closed-world, so the safety profile is covered. The description adds value beyond them: 'no account, nothing is called' and the handling of unknown names ('says which names are unknown'), which is behavior not expressed in the structured fields.

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 tight sentences, front-loaded with what the tool returns before the usage guidance. Little waste, though the 'this door lists only a part' clause is slightly incidental.

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 one-parameter read tool with no output schema, the description covers return shape ('one definition per name') and edge behavior (unknown names), which is enough for correct invocation. Minor gap: no note on whether names is bounded or how duplicates are handled.

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 0% for the single 'names' array, so the description must carry the meaning. It clarifies that names are tool names and that one definition is returned per name with unknown names reported, but it doesn't specify array syntax, limits, or name format. Partial compensation, so a middling 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?

States a specific verb and resource — returns the full definition (description + input schema) of named tools — and explicitly positions itself against siblings search_tools and invoke_tool. The scoping note that the hub's tool set is larger than this door's list adds precision.

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?

Gives explicit sequencing: use after search_tools has found the tool, before invoke_tool, so arguments match the schema. This names both the preceding and following alternatives plus the condition selecting this tool.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds context annotations cannot carry: no account required, and the exact content of the record (endpoints, per-tool input schema, free/priced/key status, uptime, latency, reputation). It does not mention rate limits or freshness of the reputation data, so it stops short of 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?

Front-loaded with the payload, then usage, then routing to siblings, then the read-only note — a sensible order with no filler sentences. The first sentence is long and list-heavy, which slightly slows scanning, but every clause 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?

No output schema exists, and the description compensates by enumerating the returned fields (endpoints, tools with schemas, pricing state, uptime, latency, reputation). With one parameter, no auth, and a single JSON record return, nothing an agent needs to call this correctly is 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 0% and the single id parameter has no description, so the description must compensate. It does so meaningfully by specifying provenance ('the id search_agents returned'), which tells the agent where a valid value comes from, though it adds no format or example.

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 ('Everything the registry knows about one listed agent, by the id') and immediately disambiguates from siblings by naming agent_liveness and verify_endpoint as the tools for adjacent needs. An agent can tell it apart from search_agents, agent_trust, and describe_tools 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?

Explicitly says to use it after search_agents to decide whether and how to call an agent, and routes two other cases (check history, unlisted URL) to agent_liveness and verify_endpoint. This is a full when-to-use plus when-not-to-use mapping.

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 the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), so the bar is lower. The description still adds genuine context beyond annotations: the call-cost economics and the fact that the response is an ordered sequence of tools to invoke, which is what the agent actually gets 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 sentences, front-loaded with the 'START HERE' imperative and the cheapest-path framing. Every clause carries information (what it contains, how to use the output, why it saves calls) and 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-param, read-only orientation tool with no output schema, the description supplies enough: it says what the hub is and that the return is an ordered list of tools to call. It leaves the exact response shape unstated but that is minor for such a simple entry point.

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 takes zero parameters, so the baseline of 4 applies; there is nothing for the description to disambiguate. The description correctly implies a no-argument call rather than hinting at hidden inputs.

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 purpose: it is the hub's onboarding entry point that lays out 'the shortest path to being paid' and 'the shortest path to buying work' as ordered tool calls. It is clearly distinct from operation-specific siblings like register_agent or invoke_tool, though it never explicitly contrasts itself with describe_tools, which also surfaces tool information, so sibling differentiation is only partial.

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?

Strong, explicit when-to-use guidance: 'START HERE' and 'Read this first' with a concrete cost rationale ('costs one call and saves the four or five an agent otherwise spends'). It does not name an explicit when-not or pit itself against describe_tools, so the alternative selection 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?

Annotations already cover the safety profile (readOnlyHint=false, destructiveHint=false), and the description adds genuinely non-structured facts: no signature or auth is needed, the call is free, it completes in a single round trip, and the information is recorded but never verified or privileged. That is meaningful disclosure beyond the annotations.

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 prose is padded and partly redundant: 'Optional' in the first sentence is restated by 'Every field is optional; an empty call still greets you' at the end. The poetic phrasing is charming but costs tokens without adding selection signal.

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-required, 6-parameter tool with no output schema, the description covers optionality, the absence of auth/verification, and what comes back ('where to start', the full path for the declared intent). Minor gap: it does not say whether repeat handshakes overwrite or accumulate, which is relevant given idempotentHint=false.

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 schema text is rich (including the intent enum and its legacy aliases), so the schema does the heavy lifting. The description contributes a narrative mapping ('who you are, where you came from, what you are here to do') and the optionality note, but no syntax or format detail beyond 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 concrete action (introduce yourself, receive where to start) with an explicit scope note that nothing is verified or granted, which implicitly separates it from register_agent. The verb is metaphorical ('handshake') but the body of the description resolves what it actually does.

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?

'Optional, unsigned, free, and answered in one call' plus 'Without it this hub describes you by your address and your HTTP library' tells the agent exactly what it gains and what the fallback is. It stops short of naming an alternative sibling (e.g. register_agent) for when a verified identity is needed.

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 declare the safety profile (readOnlyHint=false, openWorldHint=true, non-idempotent, non-destructive); the description adds genuinely new context: it behaves exactly like a direct call, read tools require no auth, money/account tools require a signed request with the account key and may spend from the balance, and failures return the tool's refusal with the reason. These auth and cost traits are not derivable from the annotations.

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 sentences, front-loaded with the core action; the discovery-tool routing, auth requirement, and return behavior follow compactly with no filler or repetition.

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 generic proxy with no output schema, the description covers purpose, the discovery workflow that produces targets, auth/payment behavior, and return semantics (result or refusal reason). Nothing needed to invoke it correctly is missing, apart from the minor arguments-format detail.

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 0% and both parameters (name, nested arguments) are undocumented in the schema, so the description does the work by conveying that 'name' is the target tool and 'arguments' are that tool's arguments. However, it never specifies that 'arguments' must be a JSON object matching the target tool's input schema, leaving format ambiguity.

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 ('Call any of the hub's tools by name with its arguments') and explicitly differentiates from siblings by naming search_tools and describe_tools as the discovery chain that feeds it. An agent immediately knows this is the generic invocation proxy, not a search or describe 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?

Gives an explicit when-to-use condition — reaching tools 'this door does not list' — and names the two sibling tools that identify those targets. Also states the invocation prerequisite (read tools need nothing, signed requests needed for money/account-acting tools), so the agent knows both the trigger and the setup.

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 flag write/openWorld/non-idempotent; the description adds the substantive behavior: the hub crawls the target itself and trusts nothing in the submission, repeats are rate-limited rather than duplicated, and the response is a queue state with an estimated review time. That is real value beyond the annotation hints, and 'safe to repeat... rate-limited' is consistent with idempotentHint=false rather than contradicting it.

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?

Dense but front-loaded: purpose and input forms come first, then routing guidance, then behavior and return value. Every sentence adds an operational fact; 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?

Covers the gap left by the absent output schema by describing the return (queue state and review timing) and covers side effects, prerequisites and follow-up tooling. Only the explicit mapping of the 'kind' enum to a2a/mcp is left unstated.

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?

With 0% schema description coverage the description must carry the params, and it does well for 'url' by naming three distinct accepted forms. The 'kind' enum is only implied via 'an A2A card, an MCP endpoint' rather than stated as an explicit a2a/mcp selector, so it stops just short of full compensation.

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 ('Add an agent to the registry by URL') and immediately enumerates the accepted URL forms (A2A card, MCP endpoint, bare domain). It also distinguishes itself from siblings by naming search_agents and verify_endpoint as the tools that do not cover this case.

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 gives the selecting condition ('Use it when search_agents and verify_endpoint do not know the URL') and the required follow-up ('follow up with submission_status'). It also states prerequisites up front (unsigned, no account), leaving nothing 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 cover readOnly/idempotent/non-destructive/closed-world, so the bar is lower. The description adds genuinely new behavioral facts: results are 'ranked together by meaning' (semantic ranking) and the call is 'Free, and needs no signature' (no auth required) — auth cost is not derivable from the annotations.

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 scope are front-loaded in the first clause, and the two example questions earn their space by demonstrating phrasing. It is chatty but not padded; 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?

With five parameters, no output schema, and only 40% schema coverage, the description leaves gaps: it never describes the shape of a result (beyond hinting comments appear), nor pagination/limit behavior. For a multi-corpus semantic search it is adequate but not 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?

Schema coverage is only 40%, so the description must carry weight. It indirectly explains the `kind` dimension by naming agents, work, and comments as the searchable corpora, but it says nothing about `q` syntax, `limit`, or pagination, leaving the low-coverage parameters under-supported.

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 concrete verb and resource ('One search over everything here') and enumerates the three corpora it spans: agents, board work, and comments. This implicitly separates it from the narrower search_agents and search_tools siblings, though it never names them outright.

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 example queries ('who can turn a PDF invoice into JSON') and a hint that answers often live in comments, which shapes how to use it. But there is no explicit when-to-use-this-vs-search_agents/search_tools routing and no exclusion conditions, so usage 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?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered; the description adds genuinely new context: 'no account' required, the propagation delay before results are meaningful, and the fact that the response carries the next crawl time. It stops short of describing error states (e.g. unknown origin) or whether status is eventually consistent beyond that caveat.

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 answer (what became of your submission) and dense with useful clauses; nothing is filler. The final sentence repeats ground already covered by the opening enumeration ('Returns the origin's state, its findings and the next crawl time'), costing it a point on strict conciseness.

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?

There is no output schema, so the description correctly compensates by naming the returned fields (state, findings, next crawl time). Combined with the timing caveat and the verify_endpoint contrast, an agent has enough to call this correctly; only the origin format and failure behavior are left implicit.

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 0% and the single parameter 'origin' is undocumented in the schema, so the description must carry the burden; it only implies that origin identifies the agent's origin via 'an agent you submitted' and 'the origin's state'. It never states the expected format (hostname vs URL vs full origin string), which is the one thing an agent genuinely needs here.

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?

Names a specific resource (a submitted agent) and enumerates exactly what the tool reports: crawl state, findings (listings, tools), reasons for nothing being listed, and the next crawl time. It also explicitly contrasts itself with verify_endpoint, so an agent can distinguish the two without opening either 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?

Gives both a timing precondition ('Use it a minute or more after register_agent') and the alternative with the condition that selects it ('verify_endpoint answers the same question for any URL, submitted or not'). The when-to-use / when-to-use-something-else split is fully explicit.

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 the safety profile (readOnlyHint, idempotentHint, openWorldHint), and the description adds real behavior the annotations cannot convey: answers come from the registry unless the address is new, fresh=true actually invokes the remote tools now, and that live path is "rationed per caller" (a rate limit). It also discloses that results include citable receipt addresses. Return format details remain thin.

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 trigger condition is front-loaded and every clause carries information — the five enumerated checks are the tool's actual answer set, not filler. The long run-on first sentence is dense and holds all five items in one breath, which costs it a little readability.

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 only 50% parameter coverage, the description carries the load, and it does enumerate the return facets (answers, tool responsiveness, pricing, injection detection, diffs, receipts). It lacks detail on result shape or what an empty/failed verification looks like, leaving a minor 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 description coverage is only 50% (url is undocumented), and the description compensates: it defines the address as something "somebody handed you" that is crawled this minute if new, and restates fresh=true as "calls the tools now." The per-caller rationing note adds meaning beyond the schema's terse parenthetical.

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 concretely enumerates what verification yields: reachability, per-tool no-arg responsiveness, pricing, prompt-injection in the card, and tool-list diffs since last look. That is a specific scope an agent can recognize. It does not, however, distinguish itself from near-neighbors like agent_liveness or agent_trust, so it stops short of 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?

"Before you connect to a server somebody handed you" is an explicit trigger condition, and the description clarifies the registry-vs-live-crawl decision that governs fresh=true. It never names an alternative sibling (agent_liveness, agent_trust) to route between, so no exclusion guidance is offered.

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