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

The description goes beyond the annotations by detailing scoring methodology, the 25-point breakdown per dimension, the fallback to an estimated score when website_url is absent, and the JSON return structure. Annotations already mark readOnlyHint=true and destructiveHint=false, and the description is consistent with that safe read-only behavior.

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 well-structured with a clear opening, a scannable bullet list of dimensions, a 'Use this when' section, and concrete examples. Every section earns its place, and the key behavioral conditions are front-loaded before the lower-level details.

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 reasonably complex audit tool, the description covers inputs, outputs, scoring dimensions, fallback behavior, and example invocations. It even describes the JSON return contents. It is slightly incomplete only in not routing the agent to sibling tools when a simpler visibility check is more appropriate, and in not explaining the required non-website parameters.

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 description only highlights website_url, which is the optional field, while omitting any mention of the required company_name, service, and city fields. It does add important conditional meaning for website_url, but the burden of explaining the other parameters falls entirely on the schema. This is adequate but not comprehensive.

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 opens with a specific verb and resource: 'Perform a full 4-dimension AI visibility audit of a business's website and return a score from 0–100.' It clearly lists the four assessed dimensions, so an agent knows exactly what the tool produces. However, it does not explicitly distinguish itself from the sibling avenity_check_visibility, which appears to overlap in purpose.

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 gives explicit use cases: 'detailed breakdown to explain the problem to a client,' 'identify the single highest-impact fix,' and 'client proposal or consulting recommendation.' It also explains the conditional behavior based on presence of website_url. It lacks explicit when-not-to-use guidance or alternative tool routing, so it does not earn a 5.

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