Skip to main content
Glama

Delete GitHub Milestone

delete_github_milestone
Destructive

Permanently delete a GitHub milestone and unassign its issues without deleting them.

Instructions

Permanently delete a GitHub milestone. Issues assigned to the milestone will be un-assigned but not deleted.

Input Schema

NameRequiredDescriptionDefault
repoNoLEAVE EMPTY to auto-detect
ownerNoLEAVE EMPTY to auto-detect
confirmNoMust be set to true to confirm deletion
use_test_dbNo
milestone_numberNoMilestone number to delete

Output Schema

NameRequiredDescriptionDefault
codeNoError code (e.g. VALIDATION_ERROR, INTERNAL_ERROR)
errorNoHuman-readable error message
detailsNoAdditional error context
messageNo
successNo
categoryNoError category (validation, query, connection, internal)
suggestionNoSuggested fix for the error
instructionNo
recoverableNoWhether the error is recoverable
milestoneNumberNo
aggregated_errorsNoDetails of individual errors in a multi-step operation
requiresUserInputNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv9.0.0

TDQS

A4/5.0
Behavior4/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 still adds real value annotations cannot express: deletions are permanent and assigned issues are un-assigned rather than deleted — the key downstream side effect. It stops short of stating auth requirements or what the response reports.

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

Conciseness5/5

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

Two short sentences, front-loaded with the permanence warning and followed by the collateral-effect disclosure. Nothing is wasted or repeated from the schema.

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

Completeness4/5

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

An output schema exists, so return values need not be described, and the irreversible side effects are covered. The remaining gap is that nothing warns the agent about the confirm:true requirement or the openWorld auth context, which matters for a destructive cross-system operation.

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

Parameters3/5

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

Schema description coverage is 80%, with repo/owner/milestone_number/confirm all documented in the schema itself. The description adds no parameter-level detail (e.g. what milestone_number refers to or why confirm exists), and use_test_db plus the confirm const constraint are undocumented — baseline 3 is appropriate.

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

Purpose5/5

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

States a specific verb and resource ('Permanently delete a GitHub milestone'), which cleanly separates it from the sibling create_github_milestone, update_github_milestone, get_github_milestone and get_github_milestones.

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

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The destructive intent is implied by 'Permanently delete', but the description never says when to prefer this over update_github_milestone or to verify existence via get_github_milestone first. No explicit when-not or prerequisite guidance beyond what the tool name conveys.

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