team_delete

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. The description adds the important note that team_id is never auto-resolved (addressing a potential failure mode). However, it doesn't disclose whether the delete is permanent or recoverable, what the output schema looks like, or whether there are cascading effects on related resources (tasks, meetings, briefings associated with the team). For a destructive mutation tool with zero annotation coverage, this is a meaningful gap.

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?

The description is a single concise sentence that front-loads the core purpose and includes the critical usage constraint. It's efficient with zero waste. However, given the tool's destructive nature and absence of annotations, a slightly larger description covering behavioral aspects would arguably justify the space — but as written, it is tight and to the point.

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?

For a destructive mutation tool with zero annotations, the description is thin. It confirms the delete action and parameter requirement but omits crucial context: what happens to the team's associated data, whether deletion is permanent or reversible, permission/auth requirements, and what the output/return value indicates. An output schema exists but the description doesn't reference what it would convey. Given the complexity of team deletion (likely cascading effects across tasks, meetings, briefings), the description is not complete enough.

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% — the single team_id parameter is documented in the schema as 'Team ID or name to delete'. The description adds only that it's REQUIRED and never auto-resolved, which reinforces rather than extends the schema. Since the parameter is simple (one field, no enum, no nested objects), the baseline 3 is appropriate; the description doesn't add semantic detail beyond what the schema provides.

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 states a clear action: 'Delete a team' — a specific verb ('Delete') with a specific resource ('a team'). Among siblings, team_delete is distinct from team_close, team_status, and team_list, and the name itself communicates the destructive intent clearly. It could benefit from noting scope (e.g., permanent vs soft delete), but the core purpose is clear.

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?

The description emphasizes that team_id is REQUIRED and never auto-resolved, which is a meaningful usage constraint. It doesn't explicitly say when NOT to use this or name a sibling alternative, but the destructive nature combined with the sibling set (team_close, team_status) makes the intended usage reasonably clear. Close siblings like team_close are not explicitly differentiated, so a 4 rather than 5.

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