GitHub PR Issue Analyser
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| GITHUB_TOKEN | Yes | GitHub Personal Access Token with 'repo' scope |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| github_add_inline_pr_commentA | Adds an inline review comment to a line, or to a range of lines, in a file within a PR. The line must fall inside the PR's diff hunks: GitHub rejects a comment on an unchanged line outside any hunk, and on a path not in the diff. A deleted line exists only on side LEFT. Workflow and conventions: github_get_skill('pr-review'). |
| github_add_pr_commentsC | Adds a comment to a specific pull request. Workflow and conventions: github_get_skill('pr-review'). |
| github_add_to_projectA | Puts an issue or pull request on a project board. One the board already holds comes back with the card it already has, so a retry adds nothing and overwrites nothing. Workflow and conventions: github_get_skill('project-boards'). |
| github_create_issueA | Creates a new issue. The update tools replace the label set as given and never re-add 'mcp'; only the create tools append it, and only when mcp_label is left enabled. Workflow and conventions: github_get_skill('issue-management'). |
| github_create_milestoneA | Opens a milestone. A title the repository already uses fails, since titles are unique per repository. Edit the existing one with github_update_milestone. Workflow and conventions: github_get_skill('issue-management'). |
| github_create_prB | Creates a new pull request. Labels are applied in a second call, since the create endpoint takes none, and they come back under labels so a set the token could not write is visible. Workflow and conventions: github_get_skill('pr-management'). |
| github_create_releaseB | Publishes a release for a tag. A tag that already carries one fails, since overwriting published notes cannot be undone. Pass if_exists='update' to replace them deliberately, and read updated on the reply to tell which happened. See #401. The update path sends the title, notes, draft and prerelease only, so make_latest and generate_release_notes are dropped and the generated changelog from the first publish is replaced by body alone. Workflow and conventions: github_get_skill('release-management'). |
| github_create_tagA | Creates a new tag. With a message it is an annotated tag, which stores the message; without one it is a lightweight ref. Workflow and conventions: github_get_skill('release-management'). |
| github_delete_releaseA | Deletes a release. The tag it was published from survives unless delete_tag asks for it, since the commit history usually should not move. delete_tag=True removes the ref that the delete_tag tool refuses to touch while a release names it. No force flag is asked for here because the release goes first, so the dangling release that guard protects against cannot be what is left behind. See #404. Workflow and conventions: github_get_skill('release-management'). |
| github_delete_tagA | Deletes a tag. A tag a release points at is refused unless force is set, because removing it leaves the release without the code it names. Workflow and conventions: github_get_skill('release-management'). |
| github_get_issueA | Fetches a single issue by number, with its body, labels, assignees and milestone. Reads straight from the issue rather than the search index, so it sees a write immediately. See #358. Workflow and conventions: github_get_skill('issue-management'). |
| github_get_latest_shaA | Fetches the SHA of the newest commit on ref, or on the default branch when ref is omitted. Returns None if the repository has no commits. The answer is a reading rather than a pin, so a push landing afterwards moves it. Workflow and conventions: github_get_skill('release-management'). |
| github_get_pr_contentB | Fetches the content/details of a specific pull request. Workflow and conventions: github_get_skill('pr-analysis'). |
| github_get_pr_diffB | Fetches the diff/patch of a specific pull request, capped at max_bytes. bytes_total is the whole patch either way, so a truncated reply says what was left behind. See #314. Workflow and conventions: github_get_skill('pr-analysis'). |
| github_get_pr_linked_issuesB | Return the issues that will be auto-closed when a pull request is merged. Workflow and conventions: github_get_skill('pr-analysis'). |
| github_get_pr_status_checksA | Return the CI check runs and commit status for a pull request's HEAD commit. Pages through up to MAX_STATUS_CHECKS_SUITE_PAGES of check suites (50 per page). For any suite whose first 100 runs are not the full set, drains up to MAX_STATUS_CHECKS_RUN_PAGES_PER_SUITE additional pages via the supplemental query. If either cap is hit before the connection is exhausted, the result is flagged truncated=True and overall is downgraded from 'passing' to 'unknown' so the caller does not act on a partial view. Workflow and conventions: github_get_skill('pr-analysis'). |
| github_get_project_fieldsA | Lists a project's fields and the options each single-select one accepts, which is what github_set_project_field expects to be named. Workflow and conventions: github_get_skill('project-boards'). |
| github_get_releaseA | Fetches one release, by tag or the latest published one. Workflow and conventions: github_get_skill('release-management'). |
| github_get_repo_stars_sinceA | Return the repos owned by username that received the most new stars since a given date. since accepts YYYY-MM-DD or ISO 8601, defaulting to 30 days ago. Answers prompts like 'which repos gained the most stars in the last 30 days'. Counts come from the weekly star history, so they resolve to whole UTC days rather than to exact star timestamps. Cost is one request for each page of the repo listing, then roughly one request per repo for every 30 weeks of the window, which makes a 30-day window a single request per repo however popular that repo is. truncated is True when the account has more public repos than the listing could read, or when a repo's history ran longer than the walk could read, so the answer may miss some. Workflow and conventions: github_get_skill('user-activity'). |
| github_get_repository_fileA | Reads one file from a repository at ref, windowed to limit bytes from offset. bytes_total is the whole file either way and next_offset says where to carry on, so a partial read never passes for the lot. A directory belongs to github_list_repository_tree. See #409. Workflow and conventions: github_get_skill('pr-analysis'). |
| github_get_skillA | Reads one skill in full. The same content is served as a skill:// resource, so a client that reads resources needs neither tool. |
| github_get_user_activitiesA | Get user activities with optional filtering by org, repo, and date range using GraphQL API. since/until accept YYYY-MM-DD or full ISO 8601 (YYYY-MM-DDTHH:MM:SSZ). Note: repo_stars is each repository's current cumulative star count, not stars gained within the requested period. Use github_get_repo_stars_since for per-period deltas. Workflow and conventions: github_get_skill('user-activity'). |
| github_list_milestonesA | Lists a repository's milestones with the count of issues in each. Workflow and conventions: github_get_skill('issue-management'). |
| github_list_open_issues_prsA | Lists open pull requests or issues. The search is fixed to is:open, so closed and merged items are out of reach here. Call github_search_issues_prs for those, and for any qualifier this tool does not expose. Workflow and conventions: github_get_skill('issue-management'). |
| github_list_pr_commentsA | Lists the comments on a pull request. Inline comments carry the file and line they sit on, so a second review can tell what it already said. Workflow and conventions: github_get_skill('pr-review'). |
| github_list_pr_reviewsA | Lists the reviews submitted on a pull request, oldest first, each with its author and verdict. A review is not a comment: github_list_pr_comments returns what was said on lines and in the thread, not whether anyone approved. Read requested_reviewers from github_get_pr_content to tell nobody has reviewed from nobody having been asked. See #408. Workflow and conventions: github_get_skill('pr-review'). |
| github_list_project_itemsA | Lists what is on a project board with each card's field values, so a backlog can be read by Status rather than one issue at a time. A board is a GraphQL connection, which pages by cursor rather than page number, so pass next_cursor back as after until has_more comes back false. Workflow and conventions: github_get_skill('project-boards'). |
| github_list_projectsA | Lists the Projects (v2) boards a user or organisation owns, with the number each other board tool takes, so a board can be found without reading its URL. The account type is resolved by GitHub, so one login serves for a person and an organisation alike. Pages by cursor: pass next_cursor back as after until has_more comes back false. See #465. Workflow and conventions: github_get_skill('project-boards'). |
| github_list_releasesB | Lists a repository's releases, newest first. Workflow and conventions: github_get_skill('release-management'). |
| github_list_repo_labelsB | Lists the labels defined in a repository. Workflow and conventions: github_get_skill('issue-management'). |
| github_list_reposA | Lists repositories for a user, an organisation, or the caller. The owner's account type picks the endpoint, since /orgs 404s on a person and /users hides an organisation's private repositories. See #354. Workflow and conventions: github_get_skill('user-activity'). |
| github_list_repository_treeA | Lists a repository's tree at ref, one level deep unless recursive. Each entry carries path, mode, type, size and sha. truncated is True where the tree exceeded GitHub's cap, which no amount of paging widens. See #409. Workflow and conventions: github_get_skill('pr-analysis'). |
| github_list_skillsA | Lists the workflow guidance bundled with this server, each with the name github_get_skill takes and the skill:// URI the same content is served under. Read the one covering the task before starting it. See #414. |
| github_list_tagsA | Lists a repository's tags and the commit each points at. Workflow and conventions: github_get_skill('release-management'). |
| github_merge_prB | Merges a specific pull request. Workflow and conventions: github_get_skill('pr-management'). |
| github_remove_from_projectA | Takes an issue or pull request off a project board. The issue itself is untouched and stays open, but the field values its card held go with it. Workflow and conventions: github_get_skill('project-boards'). |
| github_reply_to_review_commentA | Replies on an existing review thread rather than starting a new one. Workflow and conventions: github_get_skill('pr-review'). |
| github_search_issues_prsA | Searches issues and pull requests by text and qualifiers. Unlike github_list_open_issues_prs the query is the caller's, so closed and merged items are reachable and any qualifier GitHub search accepts works. Workflow and conventions: github_get_skill('issue-management'). |
| github_search_userB | Search for a GitHub user by username using GraphQL API. Workflow and conventions: github_get_skill('user-activity'). |
| github_set_issue_milestoneA | Files an issue under a milestone, or takes it off one. Takes the title rather than the number GitHub wants, and looks it up, which is the work github_update_issue is kept clear of. Omit the title to clear the milestone. Workflow and conventions: github_get_skill('issue-management'). |
| github_set_pr_draftA | Moves a pull request between draft and ready for review. REST accepts draft only when the pull request is created, so this goes through GraphQL. Workflow and conventions: github_get_skill('pr-management'). |
| github_set_project_fieldA | Sets a single-select field on an issue's card, naming the field and the option rather than their node ids. An issue not yet on the board is added first, since a field value has nowhere to live otherwise. Workflow and conventions: github_get_skill('project-boards'). |
| github_set_assigneesC | Updates the assignees for a specific issue or pull request. Workflow and conventions: github_get_skill('pr-management'). |
| github_update_issueA | Updates an existing issue. Only the fields supplied are sent, the rest keep their current values. Workflow and conventions: github_get_skill('issue-management'). |
| github_update_milestoneA | Changes a milestone in place. Only the fields supplied are sent, so closing one leaves its title and due date alone. Workflow and conventions: github_get_skill('issue-management'). |
| github_update_prA | Updates an existing pull request. Only the fields supplied are sent, the rest keep their current values, so a title can change without restating the body. Labels take a second call, since the pull request payload carries none. Workflow and conventions: github_get_skill('pr-management'). |
| github_update_pr_branchA | Updates the pull request branch with the latest upstream changes. Read head_sha from github_get_pr_content and pass it as expected_head_sha to be refused rather than to overwrite a push that landed since. Workflow and conventions: github_get_skill('pr-management'). |
| github_update_pr_commentA | Rewrites a comment already posted. Conversation and review comments have separate id spaces, so the kind has to match where the id came from. Workflow and conventions: github_get_skill('pr-review'). |
| github_update_releaseA | Changes a published release in place. Only the fields supplied are sent, so correcting a title does not wipe the notes. make_latest is settable on github_create_release alone, and only on the call that first publishes the tag, since publishing again falls through to here and this tool does not send it. Move the latest badge by deleting the release and publishing it again, or in the GitHub UI. Workflow and conventions: github_get_skill('release-management'). |
| github_submit_reviewB | Submits a review for a specific pull request. Workflow and conventions: github_get_skill('pr-review'). |
| chooseA | Present the user with a set of options to choose from. Call this tool when you need the user to make a decision between discrete alternatives. Use it proactively — don't ask the user to type their choice in chat when you can present clean, clickable options instead. The user will see a card with one button per option. When they click one, their choice appears as a message in the conversation (as if the user typed it), like: IMPORTANT: After calling this tool, you MUST stop and wait for the user's response. Do not continue or take any other actions until you see the "I selected:" message. Workflow and conventions: github_get_skill('interactive-ui'). |
| github_pr_issue_analyser_uiA | Execute Prefab Python code in a sandbox and render the result. The code runs in a Pyodide WASM sandbox with full Python support.
Import everything you use. Use the Always use PrefabApp as the outermost context manager — this enables streaming so the UI renders progressively as code is written: For interactive UIs, pass initial state as a dict and use
Available pipes: upper, lower, currency, length, json, round(n), default(val), truncate(n). Charts live in Values passed via Layout patterns:
Args: code: Python code that builds a Prefab component tree. data: Values injected as variables in the sandbox namespace. sandbox: A Sandbox instance. If not provided, a new one is created on each call. Workflow and conventions: github_get_skill('interactive-ui'). |
| github_search_prefab_componentsA | Search the Prefab component library. Use this tool to look up exact argument names, accepted values, and usage examples before writing component code. The skill covers patterns and layout; this tool has the API details. The query matches component names and descriptions.
Space-separated terms match independently, so
When a query matches a small number of components, full details
(docstrings, args, examples) are shown automatically. For broad
searches, a compact listing is returned instead. Use Args: query: Filter by component name or description. Space-separated terms are OR-matched. detail: Show full docstrings and args. Defaults to automatic (detailed for ≤5 matches, compact otherwise). limit: Max components to return in detail mode (default 8). No limit in compact mode. Workflow and conventions: github_get_skill('interactive-ui'). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| Prefab Generative Renderer | |
| project-boards/SKILL.md | Find the GitHub project boards an owner has, put issues and pull requests on one, set their fields, read what is on a board, and take items off it |
| project-boards/_manifest | File listing for project-boards |
| user-activity/SKILL.md | Find a user's or organisation's repositories, and look up a profile, contribution history, and which repos gained stars recently |
| user-activity/_manifest | File listing for user-activity |
| pr-analysis/SKILL.md | Analyse a GitHub pull request by fetching its metadata, diff, linked issues and CI status |
| pr-analysis/_manifest | File listing for pr-analysis |
| issue-management/SKILL.md | Create, update, list and search GitHub issues and PRs, list a repository's labels, run milestones, and check for duplicates |
| issue-management/_manifest | File listing for issue-management |
| interactive-ui/SKILL.md | Ask the user to pick an option, or render GitHub data as an interactive UI panel |
| interactive-ui/_manifest | File listing for interactive-ui |
| pr-management/SKILL.md | Manage the lifecycle of a GitHub PR - create, update the description, assign, refresh the branch and merge |
| pr-management/_manifest | File listing for pr-management |
| pr-review/SKILL.md | Review a GitHub pull request by posting inline code comments and submitting a review decision |
| pr-review/_manifest | File listing for pr-review |
| error-handling/SKILL.md | Read the error codes these tools raise and decide whether to retry, fix the call, or stop |
| error-handling/_manifest | File listing for error-handling |
| release-management/SKILL.md | Tag a commit, publish a GitHub release, and read, correct or withdraw the tags and releases already there |
| release-management/_manifest | File listing for release-management |
| Prefab Renderer (choose) |
TDQS
Scored across 53 tools
Most tools have clearly distinct resource+action targets, and descriptions explicitly disambiguate close pairs like github_list_open_issues_prs vs github_search_issues_prs and github_add_pr_comments vs github_add_inline_pr_comment. A few comment-related and PR-content getters are close enough that an agent could pick the wrong one without reading carefully, so it is not a perfect 5.
The overwhelming majority follow a github_<verb>_<noun> pattern with consistent verbs like list, get, create, update, delete, set, add, and search. The pattern is broken by generic 'choose' and the oddly-named 'github_pr_issue_analyser_ui', and there is minor PR/pull_request abbreviation variance, so it is not a perfect 5.
53 tools is far above the heavy threshold, and the set spans many unrelated domains including releases, tags, project boards, UI rendering, and skills, going well beyond the PR/issue analysis implied by the server name. Each domain is internally well-covered, but the server would be easier to navigate if split into focused servers or substantially trimmed.
The core issue and PR workflows are strongly covered: create/get/update/search issues, PR content/diff/status/linked issues/merge/update, plus comments and reviews. The main gap is issue comments, since only PR comments are supported, and the release/tag/project-board tooling is tangential to the stated analyser purpose, but the primary workflows have no dead ends.