backlog
An MCP server that wraps GitHub Issues as a lightweight backlog for Claude Code. Lets Claude create, track, and resolve work items using your GitHub repo as the backend — no extra database or token management required.
How it works
The server exposes 12 tools to Claude via the Model Context Protocol:
| Tool | Description |
|---|---|
create_backlog_item |
Open a new issue with type and priority labels |
list_backlog_items |
List issues filtered by status, type, or priority |
get_backlog_item |
Fetch full issue details including comments |
search_backlog |
Full-text search across open issues |
start_working_on |
Mark an item in-progress |
add_progress_note |
Add a comment to track progress or log a decision |
complete_backlog_item |
Close an issue with a resolution summary |
reopen_backlog_item |
Reopen a closed issue with rationale |
migrate_branch_issues |
Transfer issues from one branch scope to another |
create_spike |
Open a formal research spike |
check_research |
Surface prior research before starting an investigation |
save_research_output |
Persist spike findings to research/ in the working repo |
All GitHub operations go through the gh CLI — no personal access tokens to manage.
Prerequisites
- Python 3.10+
- uv installed (
curl -LsSf https://astral.sh/uv/install.sh | sh) - GitHub CLI installed and authenticated (
gh auth login)
Installation
uvx gh-backlog-mcp --setup
That's it. uvx fetches the package from PyPI on demand — no cloning, no pip install. The setup command:
- Verifies
ghis installed and authenticated - Registers the MCP server in
~/.claude.json - Prints a CLAUDE.md snippet to add to your project
Labels are created automatically on first use in each repo. Restart Claude Code after setup to pick up the server.
Configuration
Setup registers the server in ~/.claude.json using uvx:
{
"mcpServers": {
"backlog": {
"type": "stdio",
"command": "uvx",
"args": ["gh-backlog-mcp"]
}
}
}
The repo is auto-detected from the current working directory via gh repo view. The server targets whichever GitHub repo you have open — no configuration needed.
Labels
The server auto-creates these label groups on first use in each repo:
| Group | Values |
|---|---|
| Status | backlog, in-progress, blocked |
| Type | feature, bug, design, research, question |
| Modifier | spike — stacks with research to mark formal investigations |
| Priority | priority:high, priority:medium, priority:low |
Branch Scoping
Issues are automatically scoped to the current git branch via branch:X labels. When you create or list backlog items, the server detects your current branch and applies the corresponding label.
- Auto-detect —
create_backlog_item,list_backlog_items,search_backlog, andcreate_spikeall default to the current git branch - Cross-branch view — pass
branch="all"to any of these tools to see/create items across all branches - Explicit branch — pass
branch="feature/foo"to target a specific branch regardless of what you have checked out - Graceful degradation — if branch detection fails (not in a git repo, detached HEAD), scoping is silently skipped
After merging a branch
Use migrate_branch_issues to transfer open issues from a merged feature branch to the target branch:
migrate_branch_issues(from_branch="feature/auth-rewrite")
The to_branch defaults to the current git branch, so after merging feature/auth-rewrite into main, just call this from main and the issues will be relabeled automatically.
Research Spikes
A research spike is a formal investigation item that signals to the agent picking it up: enter plan mode, do web research, and produce a written output before any implementation begins.
Creating a spike
create_spike(
title="Evaluate vector DB options for embedding search",
goal="Determine which vector database best fits our latency and cost requirements",
research_questions="- What are the top open-source options?\n- How do they compare on query latency at 1M vectors?\n- What are the operational costs?",
success_criteria="Output doc must include a comparison table and a recommendation with rationale",
priority="high"
)
The issue is created with both research and spike labels. The body includes a structured template (Goal, Background, Research Questions, Success Criteria, Output path).
Agent workflow for spikes
When an agent calls start_working_on on a spike, it receives explicit instructions to:
- Enter plan mode
- Call
check_researchto find any prior work on the topic - Use
WebSearch/WebFetchto answer the research questions - Call
save_research_outputwith the synthesized findings - Call
complete_backlog_itemto close the issue
Research output files
save_research_output writes findings to research/<issue-number>-<slug>.md in the current working repository (determined via git rev-parse --show-toplevel). It also:
- Creates the
research/directory if it doesn't exist - Adds
research/to.gitignoreautomatically so outputs are never accidentally committed - Posts a comment on the GitHub issue linking to the file
Checking prior research
check_research(topic="vector database")
Searches two sources:
- Local
research/*.mdfiles — keyword match against filename and first 500 chars - GitHub spike issues (open and closed) matching the topic
Use this before creating a new spike or before implementing something that may have been researched previously.
Metadata
Release files for gh-backlog-mcp 0.2.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | Actions |
|---|---|---|---|---|
| gh_backlog_mcp-0.2.0.tar.gz | 12.1 kB | With provenance | Details for gh_backlog_mcp-0.2.0.tar.gz |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Actions Reset |
|---|---|---|---|---|
| gh_backlog_mcp-0.2.0-py3-none-any.whl | Python 3 | none | any | Details for gh_backlog_mcp-0.2.0-py3-none-any.whl |
Total release size: 24.4 kB
Release files / gh_backlog_mcp-0.2.0.tar.gz
| Download URL | gh_backlog_mcp-0.2.0.tar.gz |
|---|---|
| Size | 12.1 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
5f024e7ee0969958139b02baf3a347583b43c081a7e5bcbdb8d1bd616eb398bc
|
|
BLAKE2b-256 checksum How to use checksums |
07ddb6ec40742b687708e2fb39bd92e061898bd09738afb4433c97e5430b9d8c
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/6.1.0 CPython/3.13.12
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on May 9, 2026.
Transparency logRelease files / gh_backlog_mcp-0.2.0-py3-none-any.whl
| Download URL | gh_backlog_mcp-0.2.0-py3-none-any.whl |
|---|---|
| Size | 12.4 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
0437b64017046418d933ad8b3dd0b005d9b92b02bb8230564f32226de414662f
|
|
BLAKE2b-256 checksum How to use checksums |
0c6810eb1a36dd8c77038ea029220d62538c2bf63bbc67c43047a80f61a82ad1
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/6.1.0 CPython/3.13.12
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on May 9, 2026.
Transparency logSecurity for gh-backlog-mcp 0.2.0
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
Full provenance
All 2 files in this release have been uploaded with provenance metadata.
Attestation for gh_backlog_mcp-0.2.0.tar.gz
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on May 9, 2026.
Transparency logA note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
To learn more about protecting yourself from malicious actors, visit our package security documentation.