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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds a genuine behavioral fact beyond the structured data: results are lightweight summaries lacking full answer text and sources, which tells the agent not to expect complete content 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?

A single sentence with the core purpose front-loaded and the routing hint carried in a tight parenthetical. No filler, nothing to trim.

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?

No output schema exists, but the description compensates by characterizing the return shape (lightweight summaries, no full text or sources). Combined with annotations covering safety and a fully documented schema, an agent has nearly everything needed; only ordering/pagination behavior is unspecified.

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 100%, and the schema already documents limit (default 20, max 50), promptId filtering, and workspaceId sourcing from list_workspaces. The description adds nothing about parameters, so the baseline 3 applies.

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 recent AI chat executions") and immediately qualifies the payload as lightweight summaries, which cleanly separates it from get_chat. An agent can distinguish this from the sibling get_chat without opening either 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?

Explicitly routes the agent to get_chat when full answer text and sources are needed, which is the key decision point against the most confusable sibling. It does not state exclusions (e.g. that this is a workspace-scoped listing, or anything about ordering), but the primary alternative is named with its selecting condition.

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