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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is fully covered. The description adds real value beyond them by disclosing sort order, the default status filter, and the two-value source taxonomy, though it omits pagination behavior and how the cursor interacts with the ordering.

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 dense sentence with the most decision-relevant facts first: scope, ordering, sources, default filter. No filler, though the punctuation-heavy parenthetical makes it slightly harder to parse at a glance.

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 values need not be described, and annotations fully cover the safety profile. For a read-only, three-parameter list tool the description supplies scope, ordering, source values and the default filter, which is enough to call it correctly; only pagination nuance is thin.

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%, so the description carries the burden, and it only addresses status indirectly via "Default status filter: pending." The limit parameter (capped at 50) and the cursor parameter (page continuation, max 500 chars) get no explanation anywhere, so an agent must guess at paging semantics.

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 (scheduled messages) and distinguishes two origins, inbox-scheduled sends and MCP-scheduled requests, with the source values given explicitly. It also commits to an ordering (soonest first). It does not name a sibling it replaces, but the scheduled scope is specific enough to separate it from list_messages or get_follow_up_queue.

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?

"Default status filter: pending" implies the primary use case (checking what is queued to go out), but there is no explicit when-to-use or when-not-to-use guidance and no mention of an alternative tool for reviewing already-sent content. Usage is inferable rather than stated.

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