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

Annotations already declare readOnly, idempotent, non-destructive, so safety carries little weight here. The description adds genuinely useful behavior: only the newest audit is reported, issues are ordered worst first, a few example pages are included per issue kind, schedule reports the next crawl, and audit is null when never crawled — the last being a real edge case an agent must handle.

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-loaded with the resource, then the return contract, then the scope exclusion — a sensible ordering with no filler. The parenthetical lists (score range, site-wide checks) are long but each item conveys distinct content rather than restating the name.

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?

An output schema exists, so return values need not be explained, yet the description still previews the payload shape and the null-audit case without redundancy. What's missing is only guidance on what an agent should do when audit is null or how stale a 'newest audit' might be.

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 single workspaceId parameter is fully documented in the schema (100% coverage), including the omit-when-single-workspace case. The description adds no parameter-level detail beyond that, 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?

Names a specific resource (Kooga's crawl of the site, from the newest audit) and enumerates what the response contains: score, pages checked, site-wide checks, and issues. It explicitly bounds the scope against the closest conceptual siblings, stating 'These are the site's own pages, not rankings or AI visibility', which separates it from readRankings and readPerceptions.

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?

Usage context is clear (retrieve the latest crawl's findings, including next scheduled crawl) and the closing exclusion tells the agent when to look elsewhere for rankings or AI visibility. It stops short of naming those sibling tools directly or stating what to do when audit is null beyond noting the value.

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