github-tools

Unarchive a GitHub project item

github_project_item_unarchive

DestructiveIdempotent

Restore an archived project item to its board with field values preserved; non-archived items remain unchanged.

Instructions

Bring an archived item back onto a project board the viewer may update, with its field values. An item that is not archived is left as it is (changed: false). An item is named by its node ID (PVTI_…), which also tells its board (a project given beside it must be that board), or by an issue or pull request (12, #12, owner/repo#12 or its URL) that is on the board the lookup finds. A draft can only be named by its ID. A board is named by project: its number, owner/number or its URL, used as it is; any other project is a title, and no project is Roadmap: the open board of that whole title is looked up, never guessed, in owner's boards if owner is given, else in the boards linked to repo, then its organization's, then the viewer's. Needs a token with the project scope; if GitHub reports missing scopes, run gh auth refresh -s project.

Input Schema

Name	Required	Description
`item`	Yes	The board item: its node ID (PVTI_…), or an issue or pull request as 12, #12, owner/repo#12 or its URL, found on the board that project, owner and repo choose. A draft can only be named by its ID.
`repo`	No	owner/name; defaults to the working tree's repository (its origin). Where the board lookup starts, the owner of a bare board number, and the repository of a bare issue or pull request number.
`owner`	No	A user or organization login, or "@me": the owner of a numbered board, else the only owner searched for a title.
`project`	No	The board, as its number, owner/number or its URL (used as it is; a bare number takes owner, else the owner of repo or of the working tree's repository), or as its title, looked up among open boards (whole title, case-insensitive). Default: the title Roadmap.

Output Schema

Name	Required	Description
`changed`	Yes	false when the item was already in the wanted state.
`item_id`	Yes
`project`	Yes
`archived`	Yes	Whether the item is archived now.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.7.0Nov 6, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already declare the mutation profile (readOnlyHint=false, destructiveHint=true, idempotentHint=true), and the description earns extra credit on top: it discloses the idempotent no-op result (changed: false, item untouched), that field values are restored, and the exact auth requirement plus the remediation command 'gh auth refresh -s project' when scopes are missing. That is material behavior an agent cannot infer from structured fields.

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 core action is front-loaded in the first clause, but the remaining text is a dense run-on chain of semicolon-joined clauses covering item grammar, board grammar, lookup order, and auth. Every fact is relevant, yet the packing makes it hard to scan and pushes secondary details ahead of a clean summary.

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?

With an output schema present, return values need no explanation, and the description covers the remaining gaps for a 4-parameter mutation tool: default resolution order, ID vs. issue/PR vs. draft naming, board/item consistency, idempotency, and auth failure handling. An agent has everything needed to invoke it correctly.

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 100%, so the baseline is 3, but the description adds the project resolution cascade that the schema does not spell out: an owner's boards first, then boards linked to repo, then the organization's, then the viewer's, with the Roadmap title default and an explicit 'never guessed' guarantee. The item-naming grammar largely restates the schema, which keeps this from a 5.

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 ('Bring an archived item back onto a project board') and immediately scopes it to boards the viewer may update, with field values preserved. It also distinguishes the no-op case (not archived → changed: false), which lets an agent tell this apart from github_project_item_archive and github_project_item_edit without opening schemas.

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 preconditions and exclusions: the item must be archived, the token needs the project scope, and a project passed alongside an item ID must be that item's board. It falls short of naming a sibling alternative (e.g. use github_project_item_edit for field changes), so routing guidance is implied by state rather than explicit.

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