Verdict — Send anything. Get the truth.

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

With no annotations, the description carries the full burden and does disclose meaningful traits: content is processed but not stored, and output includes a signed certificate and shareable link. It does not cover latency, failure modes, or explicit rate-limit/credit-exhaustion behavior, so it stops short of full transparency.

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?

A single well-formed sentence that front-loads the input contract before the output list. The output enumeration is long but every item is informative, 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?

With no output schema and no annotations, the description takes on both roles and does reasonably well: it names the verdict scale, the warning score, next steps, and the certificate/link artifacts, and states the data-handling policy. What is missing is sibling routing and any hint about credits being consumed per call.

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 both parameters are already documented, including the 10–8000 character range and the subscription code semantics. The description only hints at the subscription code's credit-allowance behavior, adding little beyond the schema; 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 (check) and resource (message/text) and enumerates the input types it covers, plus the exact verdict vocabulary returned. It is largely distinguishable from check_url, but the description explicitly invites pasting a 'link', which blurs the boundary with the URL-oriented siblings.

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 the input enumeration ('paste any suspicious text'), but there is no explicit when-to-use/when-not guidance and no mention of the alternatives check_url or screen_urls. The inclusion of 'link' as an accepted input actively leaves the routing question open.

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 and does so well: it discloses safe server-side fetching, the specific detection techniques (look-alike domains, domain age, sender rules, URLhaus list), and what the response contains. It omits auth requirements and any rate/credit limits beyond the schema's subscriptionCode hint.

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 dense sentences with the core action front-loaded and no wasted framing. The list of checks is informative rather than padding, though the second sentence leans on the reader knowing check_message's return shape.

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 compensates by naming the return contents (verdict, checks, certificate, share link). It is nearly complete for a read-only check tool, with the only gap being that the return shape is delegated to check_message rather than described 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 description coverage is 100%, so both parameters are already documented in the schema. The description adds no syntax, format, or constraint detail beyond what the schema provides, making the baseline of 3 appropriate.

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 ('Check one web link') and enumerates the checks performed, which is more than a tautology. It distinguishes itself from check_message by scoping to a single URL, though it does not explicitly differentiate itself from the screen_urls sibling.

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: the mention of returning the same result as check_message hints that this tool is the URL-specific entry point. There is no explicit guidance on when to prefer this over check_message or screen_urls, and no stated prerequisites.

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 to lean on, the description carries the full behavioral burden and does so well: it discloses server-side following, the exact verdict categories, the warning score and flags output, per-item refusal of private/internal links, per-item invalid-entry reporting with batch isolation, and credit consumption. These are the failure modes and side effects an agent most needs to know.

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?

Four dense sentences, front-loaded with the capability and cap, then the outputs, then the edge-case handling and cost. No sentence is filler — each conveys capability, return shape, or failure behavior.

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 must explain return values, and it does: verdict enum, warning score, and top warning flags. Combined with per-item error handling and credit cost, an agent has everything needed to invoke and interpret the call 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 description coverage is 100%, so both parameters are already documented in the schema, including the 1–25 range and the subscriptionCode credit semantics. The description reinforces the 25-item cap but adds nothing new about the parameters themselves, making the baseline 3 appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource ('screen up to 25 links in one call') and states the batch scope explicitly, which implicitly separates it from the single-item sibling check_url. An agent can tell at a glance this is the bulk-screening tool rather than a one-off check.

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 clear usage context — batch screening up to 25 links, cost of one credit per screen — so the agent knows the capacity and billing model before calling. It does not, however, explicitly route single lookups to check_url or state exclusions, so it stops 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.