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

Annotations already declare readOnlyHint=true, so the safety profile is covered, and the description adds genuinely new behavioral context: the result is aggregated across all domains in a single call and each entry carries a domain, an id/key, and the next tool to invoke. It stops short of noting ordering guarantees, truncation/limit behavior, or cost of the fan-out, so not a 5.

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 core purpose, then the routing rule, then the return shape — a sensible order with no filler. The middle list of item types is long but each element earns its place by telling the agent what to expect back.

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 carries the burden of return-value disclosure and does so (entries name domain, id/key, and next tool). An agent could call it correctly from this. Missing only edge-case detail on ranking and limit interaction with the all-domains default.

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 both parameters are already documented; baseline 3 applies. The description reinforces domain scoping ('across ALL of the user's domains', 'without naming a specific domain') but adds nothing about what limit does or how it ranks entries.

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+resource ('prioritised to-do list') and enumerates exactly what it aggregates (critical/high issues, open quests, next growth-plan step, stale scans, missing integrations), which cleanly separates it from siblings like quests_and_issues or growth_plan that cover only one domain.

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?

Explicitly says 'Start here when the user asks what to improve, what to do next, or to "optimise the site" without naming a specific domain' and gives the reason — it saves querying every project separately. That is an unambiguous when-to-use rule plus the condition that selects it over per-domain siblings.

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