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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile needs no restatement. The description adds one piece of behavior beyond them — that each project carries an open-task count — plus the "Shared" scope qualifier. It says nothing about pagination behavior, default result size, or whether archived projects are returned by default, which are the behaviors an agent actually needs to reason about here.

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 compact sentences, both front-loaded and free of filler; the cross-reference to create_task is placed where it will be read first. The opening is a bare noun fragment rather than a statement of what the call returns, which is slightly clipped even for a terse definition.

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 the description is not obligated to explain the return shape, though it volunteers the open-task count. For a paginated list tool with three undocumented parameters, however, the definition leaves out default ordering, default archive filtering, and page-size behavior — enough gaps that an agent could mis-call it or miss results.

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 0% across three parameters (limit, cursor, include_archived), so the description carries the full burden and adds none of it. The most consequential omission is include_archived: nothing states whether archived projects are excluded by default or what including them changes. Pagination via limit (max 50) and cursor is likewise never mentioned.

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 concretely ("Shared task projects") and clarifies scope with the parenthetical about project ids. Combined with the tool name, an agent knows this is the enumerator for the project entities that create_task, create_project, and list_tasks orbit. It stops short of an explicit verb statement like "list all projects," relying on the name for that.

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?

The parenthetical "create_task requires one of these project ids" is a genuinely useful usage signal — it tells the agent to call this before create_task to obtain a valid id. There is no explicit when-not guidance, and nothing tells the agent how this relates to list_tasks versus get_task or when to prefer it over them.

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