Skip to main content
Glama
deanchong
by deanchong

post_batch_delete_issues

Destructive

Delete multiple issues in a single request. Deleted issues go to trash and can be restored later.

Instructions

Delete multiple issues. Delete multiple issues in a single request. Deleted issues are moved to the trash and can be restored later if needed.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bodyYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

C2.9/5.0
Behavior3/5

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

Annotations already declare destructiveHint=true and idempotentHint=false, so the safety profile is covered. The description adds genuinely useful context beyond annotations: deletions are soft (moved to trash) and reversible via restore. It still omits batch limits, partial-failure behavior, and whether the whole request is atomic.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The first two sentences are near-duplicates ("Delete multiple issues. Delete multiple issues in a single request."), wasting one of only three sentences. The trash/restore clause is front-loaded well once reached, but the redundancy costs efficiency.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive batch mutation with no output schema, the description covers the key durability behavior (trash + restore) but is silent on batch size limits, failure/partial-success semantics, and id format. Annotations cover the safety hints, so the remaining gaps are moderate rather than severe.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Parameter count is 1 with 0% schema coverage; the body array (a list of issues with ids) is never described in prose. The description does not compensate for the coverage gap by explaining the expected payload shape, id type, or any size constraint, leaving the agent to infer the body format.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb+resource ("Delete multiple issues") and the word "multiple" implicitly distinguishes it from the single-item sibling delete_issue. However, it never names delete_issue explicitly, so differentiation relies on inference from the batch phrasing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 batch tool versus repeated delete_issue calls, no stated batch-size limit, and no prerequisites (e.g., permissions or locked issues). The only usage-relevant content is the undeclared semantics of a batch request.

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

Deploy Server

Other Tools