GitHub Assistant MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| GITHUB_TOKEN | No | GitHub Personal Access Token for higher API rate limits (5,000 req/hr vs 60 without) |
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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| search_reposA | Search GitHub repositories by keyword or topic. Use this when the user wants to discover repositories — e.g. "find Python HTTP libraries", "search for machine learning repos", or "what are popular React starter templates?". Args: query: GitHub search query. Supports qualifiers like: - "language:python" to filter by language - "stars:>1000" to filter by star count - "topic:machine-learning" to filter by topic Examples: "fastapi", "react hooks language:typescript stars:>500" sort: Sort results by: "stars" (default), "forks", "updated", or "best-match" limit: Number of results to return (1-30, default 10) |
| get_repoA | Get detailed information about a specific GitHub repository. Use this when the user asks about a known repository — e.g. "tell me about the django/django repo", "how many stars does torvalds/linux have?", or "what language is facebook/react written in?". Args: owner: The repository owner — a GitHub username or organisation name. Examples: "microsoft", "torvalds", "psf" repo: The repository name (not the full URL, just the name). Examples: "vscode", "linux", "cpython" |
| list_issuesA | List issues for a GitHub repository. Use this when the user wants to see what bugs, feature requests, or tasks are open in a project — e.g. "what issues are open in pallets/flask?", "show me recently updated closed issues in django/django". Args: owner: Repository owner (GitHub username or organisation). repo: Repository name. state: Filter by issue state: "open" (default), "closed", or "all". limit: Max number of issues to return (1-50, default 20). |
| get_issueA | Get the full details and description of a specific GitHub issue. Use this when the user wants to read the body/description of an issue — e.g. "what does issue #42 in pallets/flask say?", "show me the details of issue 1500 in django/django". Args: owner: Repository owner (GitHub username or organisation). repo: Repository name. issue_number: The issue number shown in the GitHub URL after /issues/ |
| list_pull_requestsA | List pull requests for a GitHub repository. Use this when the user wants to see what code changes are proposed or recently merged — e.g. "what PRs are open in fastapi/fastapi?", "show me recent merged PRs in torvalds/linux". Args: owner: Repository owner (GitHub username or organisation). repo: Repository name. state: Filter by PR state: "open" (default), "closed", or "all". limit: Max number of PRs to return (1-50, default 20). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 5 tools
Each tool targets a distinct operation: search vs. specific repo lookup, list vs. issue detail, and PR listing. There is no meaningful overlap or ambiguity between them.
All tool names follow a clear snake_case verb_noun pattern, with search_ for discovery, get_ for single-item fetch, and list_ for collections. The convention is predictable and consistent.
Five tools is well-scoped for a read-only GitHub exploration assistant. Each tool covers a distinct core operation without unnecessary redundancy.
Repository search/detail and issue browsing are covered, but the PR surface is incomplete: there is list_pull_requests but no get_pull_request for viewing PR details. There are also no write or update operations, so lifecycle coverage is notably incomplete.