github-tools

Take GitHub pull requests out of a stack

github_stack_unlink

DestructiveIdempotent

Remove unmerged pull requests from a GitHub stack while keeping merged and queued ones in place; pull requests stay open and can be relinked later.

Instructions

Take the pull requests out of a native stack, named by its number or by a pull request in it. Every unmerged pull request leaves (open, draft and closed ones); merged and queued ones stay in the stack, and remaining shows what is left, null when the stack is gone. The pull requests stay open with their branches and bases as they were, and nothing is deleted: github_stack_link can build the stack again. A pull request in no stack is left alone: nothing is sent and changed is false. A pull request is 12, #12, owner/repo#12 or its URL.

Input Schema

Name	Required	Description
`pr`	No	A pull request in the stack. The pull request, as 12, #12, owner/repo#12 or its URL.
`repo`	No	owner/name; defaults to the working tree's repository (its origin). Used for a bare number.
`stack`	No	The stack's number (not a pull request's).

Output Schema

Name	Required	Description
`repo`	Yes
`changed`	Yes	False when the pull request was in no stack, or none of the stack's pull requests could leave.
`foreign`	Yes
`removed`	Yes	The pull requests that left the stack.
`remaining`	Yes	What is left of the stack (merged and queued pull requests stay); null when it is gone.
`stack_number`	Yes	The stack that was taken apart; null when the pull request was in none.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.7.0Nov 6, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond destructiveHint=true by scoping the destruction precisely: stack membership for open/draft/closed PRs is removed, while merged and queued entries survive, and branches, bases, and the PRs themselves are untouched. It also discloses reversibility, the null `remaining` outcome when the stack empties, and the `changed: false` no-op path for an unstacked PR.

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

Conciseness4/5

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

The core action and its inverse are front-loaded, and each following sentence carries distinct information (survivors, reversibility, no-op case, identifier formats). It is a single dense block rather than scannable bullets, but no sentence is filler.

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

Completeness5/5

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

For a three-parameter mutation with an output schema, this covers everything an agent needs: which entities are affected, what is preserved, what is returned in the degenerate cases, and how to undo it. Return-value details are left to the output schema, as appropriate.

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

Parameters4/5

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

Schema coverage is already 100%, so the baseline is 3, but the description adds the structural fact the schema does not state: the stack is identified either by its own number or by any pull request inside it. It also repeats the accepted PR reference forms, which is redundant with the schema but harmless.

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 concrete verb and resource ('take the pull requests out of a native stack') and immediately names the inverse sibling, github_stack_link, so the agent can separate the two without opening either schema. The naming forms accepted for identifying the stack are spelled out in the same breath.

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

Usage Guidelines4/5

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

Gives clear conditions: unmerged PRs leave, merged and queued ones stay, and a PR in no stack is a no-op. The alternative (github_stack_link) is named, but only as a way to rebuild afterwards rather than as an explicit 'use that tool when you want to add' routing rule.

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