sprrint_projects_delete

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

With no annotations, the description carries the burden of behavioral disclosure. It clearly indicates the destructive nature and enforces a confirmation rule: confirm must exactly match the project name. However, it does not disclose irreversibility, cascading effects on tasks/members/sprints, or permission requirements, which leaves meaningful gaps for a delete operation.

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 carry all the core information with no filler. The destructive action is front-loaded, and the critical confirmation requirement immediately follows. Nothing extraneous is present.

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 tool with no annotations and no output schema, the description is too thin. It omits whether deletion is permanent, what happens to associated resources, and how the project parameter is identified. The lack of sibling differentiation also means an agent cannot confidently choose this over archive.

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 must compensate. It clarifies that the confirm parameter must be the exact project name, but it never explains what the project parameter should be (ID, name, slug) or how the two parameters relate. This is only partial compensation for two undocumented required parameters.

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 uses a specific verb and resource: 'Delete a project.' It also adds a key mechanical detail—that confirm must be the exact project name—which clarifies what the deletion requires. It does not explicitly contrast with the sibling archive/restore tools, so it loses the top score.

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?

There is no guidance on when to use this tool versus alternatives such as sprrint_projects_archive or sprrint_projects_restore. The description implies deletion is separate from archival, but it never states when permanent deletion is appropriate or when a safer alternative should be used.

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