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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds value beyond that by defining scope (only the user's own items in their workspace) and enumerating the returned fields, which matters since there is no output schema. It does not mention ordering or result caps, but the schema covers the cap.

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?

Three sentences, each doing distinct work: scope, usage triggers, and return shape. It is front-loaded on what the tool returns and wastes no words.

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 usefully enumerates the returned fields (id, title, status, due date, priority, project, source) and pins down the scope, which is what an agent needs to interpret results. Minor omissions like ordering or total-count behavior are the only remaining 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 description coverage is 100%, so every parameter is already documented with defaults, max values and date format. The description only loosely echoes project and due-date filtering ('due this week', 'project X') without adding syntax or semantics beyond the schema, so the 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?

The description states a specific verb and resource ('List the user's to-dos') and immediately scopes them ('their own items in their workspace'), so an agent knows exactly what dataset comes back. The sibling tools are all meeting-related, so no todo-sibling differentiation is required, but the phrasing would still distinguish it cleanly.

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 gives concrete trigger phrases — 'what is on my plate', 'what is due this week', 'open tasks for project X' — which map well onto real user intents. It stops short of explicit when-not-to-use guidance or naming an alternative tool, which is the only gap.

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