List Deleted Team Entries

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

Annotations already declare readOnly/idempotent/non-destructive, so the description's burden is lower; it still adds two non-obvious facts: results are soft-deleted records (not a full listing) and the operation requires TEAM_DB_PATH. It does not describe ordering, retention window, or what "recently" means, so it is not a 5.

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?

Two short sentences, front-loaded with the action and the qualifying condition, with zero filler. The brevity is a virtue here, though it leaves the prerequisites sitting after the core statement rather than being woven into operating guidance.

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?

Annotations and an output schema carry the safety profile and return shape, so the description needn't explain results. However, for a five-parameter paginated/filterable list tool with 20% schema coverage, the description leaves an agent guessing about paging and DB/project scoping.

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?

Five parameters with only 20% schema description coverage, and the description mentions none of them. limit/offset pagination defaults, use_test_db DB switching, and project_number scoping are undocumented in both places; only workspace_id carries a schema description.

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 and resource ("List ... team entries") plus the distinguishing qualifier "recently soft-deleted ... that can be restored," which separates it from get_recent_entries or search_entries. It does not explicitly contrast with the sibling team_restore_entry or the non-team list_deleted_entries, leaving the pairing implicit.

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?

No statement of when to reach for this tool versus team_search, get_recent_entries, or the local list_deleted_entries. The phrase "that can be restored" hints at a restore workflow but never names team_restore_entry as the follow-up or states that only soft-deleted records appear here.

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