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

With no annotations provided, the description carries the full burden of behavioral disclosure, but it only adds scope context ('shared task queue for humans and agents'). It does not disclose that the list omits done/cancelled items by default (exclude_closed=true), the default sorting/pagination behavior, or that this is a safe read-only operation.

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?

A single nine-word sentence that leads with the verb and resource and appends a scoping parenthetical. Every word earns its place, with no filler or repetition of schema details.

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?

The rich input schema (89% coverage, defaults, enums) and presence of an output schema cover parameter semantics and return values. The description is adequate for a straightforward list operation but leaves gaps in usage guidance and behavioral disclosure that an agent navigating 70+ siblings would benefit from.

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 89% (all params except limit have descriptions), so the schema does the heavy lifting and the baseline is 3. The description adds little parameter-level meaning, though 'shared task queue for humans and agents' hints at the org-wide scope behind the 'mine' and 'assignee' filters. It does not compensate for the undocumented 'limit' param, but min/max constraints make it self-explanatory.

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 org work items', and the parenthetical 'shared task queue for humans and agents' clarifies the org-wide scope. This distinguishes it from task-specific siblings like work_subtasks_list, work_comment_list, and work_followers_list, and from agent_run_list, so an agent can select it without opening the schema.

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 is implied: an agent would call this when it needs to enumerate org work items. However, there is no explicit when-to-use/when-not-to-use guidance or named alternatives, despite many list-capable siblings (work_get for single items, work_subtasks_list for nested tasks, agent_run_list for agent runs).

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