Check AI visibility

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

With annotations already covering the read-only/open-world safety profile, the description adds substantial behavioral context beyond them: the subscription requirement and free-trial terms, the distinction between `sources: null` and an absent `sources` key, the instruction to treat `competitor` rows as context rather than placement targets, and the `name_warning` caveat to relay rather than present as settled fact. It also discloses that trend data is computed from stored snapshot history.

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 purpose and trigger queries before details, and every sentence carries distinct information — nothing is redundant. It is long (roughly 280 words), but the density is justified given the subscription requirement, return-value semantics, and caveat handling it must convey that no output schema exists to cover.

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 values, and it does: score range, per-engine breakdown, top competitor, `sources` semantics including null vs absent, trend data, and the `name_warning` case. It also covers the access prerequisite (subscription/trial) and the fallback sibling tool, leaving nothing an agent needs to invoke it correctly 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?

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema for the optional parameters: it warns that "a guessed name is scored as if confirmed, so supply one only when it is actually known," and explains the detection-fallback behavior for `business_location` (widening to country or dropping place, "right for a national or global business and wrong for a local one"). This goes beyond the schema's plain descriptions.

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 line, "Check how visible a website is to AI assistants right now," pairs a specific verb with a precise resource and temporal scope, going well beyond the title. It further delimits the purpose by enumerating the exact user queries that trigger this tool ("does ChatGPT/Perplexity/Claude/Gemini recommend this business") and lists the concrete outputs (0–100 score, per-engine breakdown, top competitor), leaving no ambiguity about what it 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?

The description explicitly says "Use this whenever someone asks..." followed by five concrete query patterns, giving unmistakable when-to-use guidance. It also provides an explicit conditional alternative: if the user lacks a subscription, "call get_sample_audit first to show them the exact output format, free and with no API key," which is as clear a routing rule as the calibration 5 example.

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