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

Annotations already signal readOnly, idempotent, and non-destructive behavior, but the description adds real behavioral detail: the tool is synchronous, usually returns within about 30 seconds, reuses a check from the past hour, and degrades the isitagentready.com secondary signal to 'unavailable' when that service is down. These specifics go beyond the annotations and help an agent anticipate latency and failure modes. Missing are explicit response type details, but the extra context merits a solid 4.

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 a clear purpose and follows with structured sections (Headline, Secondary) and appended notes on latency and caching. The first sentence is both meaningful and compact. The parenthetical listing Open Service Profile details is dense but packed with necessary signal, so nothing is extraneous; slight formatting improvements could improve scannability, but it remains 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?

Given the tool is a check with no output schema, the description does not say what the 'final result' actually looks like (boolean, report, level, etc.). It describes inputs, checks, performance, and caching but leaves the return contract vague—an agent may not know whether to expect a machine-readable verdict, a structured report, or a human-readable sentence. The tool itself is relatively simple, and the annotations fill some gaps, but the missing return description prevents a higher score.

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 JSON schema already fully describes the single 'url' parameter, including 'http or https' and 'The scheme is optional', so schema coverage is 100%. The description adds no additional parameter nuance beyond this. The mention of manifest path is about the tool's internal checks, not parameter usage, so the parameter semantics rely on the schema alone – baseline 3 is 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's headline 'Check whether a local service business is legible to AI agents' provides a specific verb and resource, and then elaborates with concrete checks: Open Service Profile conformance (manifest at /​/​/.well-known/open-service-profile, validated against the spec, including LocalBusiness and ScheduleAction JSON-LD) and the isitagentready.com signal. This level of detail clearly distinguishes it from sibling tools like check_ai_visibility or check_site_speed without needing to name them.

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 implies the use case—assessing AI-agent legibility of a local business—and gives no wrong-context instructions. However, it does not explicitly state when to use this tool versus alternatives such as check_ai_visibility or check_local_rank, nor does it mention any preconditions or exclusions (e.g., the URL must be publicly reachable). It would be stronger with a direct 'Use this when...' or a quick contrast to sibling checks.

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