The modular grouping is what makes this worth choosing over a general GitHub server: you can hand an agent issue management and nothing else, which is a far smaller blast radius than a token that can also push code. Read the project's own note about failing tests before you rely on it inside an automated loop.
A Python server built on PyGithub. The issue surface is complete: creating and updating issues, reading and listing them, and managing their comments and labels. Other domains ship as tool groups that are off by default.
- Issues created and updated with title, body, assignees, labels, milestone and state — `create_issue`, `update_issue`
- One issue fetched by number, and a repository's issues listed with pagination — `get_issue`, `list_issues`
- Comments added, listed, updated and deleted — `add_issue_comment`, `list_issue_comments`, `update_issue_comment`, `delete_issue_comment`
- Labels added to and removed from an issue — `add_issue_labels`, `remove_issue_label`
- Optional parameters handled properly: only what you pass is sent to GitHub, and primitives are converted to GitHub objects, such as a milestone number becoming a Milestone
A GitHub personal access token in `GITHUB_PERSONAL_ACCESS_TOKEN`. Create the environment with `uv venv` and install with `uv pip install -e .`, then point the client at the venv's Python running the `pygithub_mcp_server` module. Only the `issues` tool group is enabled by default — turn others on through a JSON file named by `PYGITHUB_MCP_CONFIG`, or with `PYGITHUB_ENABLE_ISSUES`, `PYGITHUB_ENABLE_REPOSITORIES` and `PYGITHUB_ENABLE_PULL_REQUESTS`. The project notes that many of its tests are currently failing and under investigation.