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

Annotations carry readOnlyHint=false, and the description explains why without contradicting it: it never modifies the website but does read it and store a result on CanAIReadMe. It adds latency (10-40s), caching/freshness behavior (default 7 days), cost (free), and a data-provenance model (observed vs claimed vs verified, confidence, source URL/quote). This is substantially richer than 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?

Front-loads the one-line purpose, then usage triggers, then behavioral caveats, then exclusions — a sensible ordering. The middle paragraph is dense with proviso clauses and could be tightened, but nearly every sentence carries information an agent needs.

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 an output schema existing, the description helpfully characterizes the return shape (Business Passport v1 with provenance, confidence, source, and explicit unknowns) plus latency, caching, and a prompt-injection caveat on quoted values. Nothing needed to call this correctly or interpret it 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 100%, so the baseline is 3, but the description adds cross-parameter meaning: the 7-day freshness default that max_age_hours tunes, the fact that analyze_if_missing=false suppresses the slow first-read path, and the timing semantics behind wait_seconds. It does not restate the numeric bounds the schema already gives.

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 verb+resource ('Returns what a specific business is, from its website') and enumerates the content domains it covers (identity, offerings, prices, audience, contactability). It explicitly distinguishes itself from the sibling audit_ai_visibility, so an agent can route between them without reading 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 affirmative triggers with sample user phrasings ('What does acme.com do?', 'Does this company publish prices?') plus a usage moment ('before comparing or recommending businesses'). It also supplies explicit exclusions: don't use for scoring/auditing (name the alternative), category search, or general concept explanation.

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