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

Annotations already cover read-only, idempotent, closed-world, non-destructive semantics, so the description is free to add what annotations cannot: that results are ordered by priority ('in the order it matters') and paginated via a `next` token. That ordering claim is genuinely useful behavioral context an agent would otherwise not know.

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 short sentences, front-loaded with the resource and its contents, then the usage directive, then pagination. No sentence is redundant.

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 return-value explanation is correctly omitted; the description still signals result shape (ordered priority list) and pagination. Workspace scoping is left entirely to the schema, which is acceptable given the schema documents it.

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 67% — cursor and workspaceId are well documented in-schema, limit is undocumented but bounded by min/max. The description reinforces pagination by explaining that `next` yields the following page 'when there is more', which clarifies how the cursor parameter is produced and consumed.

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 a specific resource ('everything waiting for the merchant') and enumerates its contents — proposals to approve, questions, things to do — which separates it from siblings like readAnswers or readIdeas. It never names a sibling directly, so the differentiation is implicit rather than explicit.

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?

'Read it before telling them what needs them' gives a clear directive on when to call it, and the enumeration implies the situations it covers. No exclusions or named alternative tools are given, so the guidance is strong but not exhaustive.

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