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

Annotations already declare the mutation profile (readOnlyHint=false, destructiveHint=false), so the description's job is to add context, and it does: crawling is asynchronous unless crawl_site is invoked. It omits what happens if the domain already exists, which matters given idempotentHint=false — duplicate handling is left unexplained.

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 tight sentences with the core action first and the crawl timing second; every clause 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?

Covers creation and crawl timing but, with no output schema, says nothing about what is returned (site ID? confirmation?) or how duplicate domains are handled. For a non-idempotent creation tool those are meaningful gaps.

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 75%: domain, sitemap_url and llms_txt_url are documented inline, and language has an enum plus a default. The description adds no meaning for language, sitemap_url or llms_txt_url beyond what the schema states, so 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 and resource ('Adds a website (domain) to the Anole account') and scopes it to account-level site creation. It also names the sibling it pairs with (crawl_site), so an agent can tell it apart from crawl_site without opening 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?

Explains the follow-on behavior: the site is crawled automatically in the next background cycle, or immediately if the agent calls crawl_site. That gives a clear decision point for the crawl step, though it doesn't address when to use add_site versus checking list_sites first for an existing domain.

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