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

Annotations only declare readOnlyHint=true; the description adds substantial behavior beyond that: login/auth requirement, role-based scoping (non-managers see only their own), default organization scope and the 20-org cap, per-organization failure surfaced in 'failed', and per-org truncation at 100 items. These are the operational edge cases an agent must anticipate and they are not derivable from structured fields.

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?

It is extremely compact, with every clause carrying real information (auth, ordering, role scoping, default scope, cap, failure, truncation, sibling routing) and no filler. Structure is the weak point: it is a single semicolon-delimited run of fragments with no front-loaded purpose statement, so an agent must parse the whole string to extract the intent.

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 cross-organization read tool with no output schema, the description covers the critical return-side edge cases (failed and truncated) and the access model, which is what matters most. The primary return shape (the task list itself) and any pagination beyond the per-org 100 cap are left implicit, a minor gap given the schema already documents both parameters fully.

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%: the status enum and organizationIds (including the 20-item cap and the 'omitting means all my organizations' default) are already documented in the schema. The description mostly restates those facts ('默认全部在册组织，超过20须点名') rather than adding syntax or format detail, so it sits at the baseline for full-coverage schemas.

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 names the resource and its scope clearly: 'cross-organization tasks sorted by deadline', merged across registered organizations, with non-managers restricted to their own tasks. It does not lead with an explicit verb+object statement (it opens with an auth note '登录'), but the purpose is unambiguous once read and the title reinforces it.

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?

It explicitly routes to alternatives: reporting progress belongs to set_organization_task_status, and cross-organization personal todos belong to get_my_work. It also states the selection conditions (non-managers see only their own tasks; default is all registered organizations; more than 20 must be named explicitly), which is exactly the when/when-not guidance an agent needs.

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