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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds non-annotated behavior: newest-first ordering, a fixed page size of 25, the per-row fields returned, and that a single-id fetch can surface submissions a reviewer may also see. No destructive, auth, or rate-limit caveats beyond that.

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?

Dense but front-loaded: the list behavior and ordering come first, then the filter and the single-id mode. Every clause carries information, though the appositive-heavy style makes it one long breathless run rather than cleanly separated sentences.

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?

Output schema exists, so return fields need not be spelled out, yet the description still names what each row carries. Pagination, ordering, and auth scope (this key's own account) are covered; only the exact semantics of the alternate `status: all` value and page-boundary behavior are left implicit.

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 only 33% (page and status are undocumented in the schema), but the description compensates: it explains `status: open` as the filter for pending items and states the 25-per-page size, effectively documenting page. It adds meaning to `id` as well (yours or any a reviewer may see, with comment thread).

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?

States a specific verb+resource (list this key's own submissions), enumerates the record types covered (proposed changes, new-entry proposals, claims, reports, applications), and scopes it to the key's own account, which cleanly separates it from list_review_queue and list_applications. An agent can identify 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?

Gives clear context for how to steer the tool — `status: open` for the still-waiting ones, `id` to fetch a single submission with its comment thread — but never explicitly names an alternative sibling (e.g. list_review_queue) or states when not to use this tool. Clear context, no exclusions.

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