Which integrations are available for this server?

Provides tools to search and retrieve GitHub repository data, issues, pull requests, and README content via the GitHub REST API.

How do I use GitHub Assistant MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@GitHub Assistant MCP Server show me the latest issues in fastapi/fastapi" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

GitHub Assistant MCP Server

by Kamalesh-Kavin

Overview Schema Related Servers Score Discussions

Python

Remote

GitHub Assistant MCP Server

A Model Context Protocol (MCP) server that connects Claude Desktop to the GitHub API. Ask Claude natural-language questions about any public GitHub repository — issues, pull requests, repo metadata, READMEs — without leaving your conversation.

What is MCP?

MCP (Model Context Protocol) is an open standard that lets AI applications connect to external tools and data sources through a uniform interface. Think of it as a USB-C port for AI — any MCP-compatible client (Claude Desktop, Cursor, VS Code Copilot, etc.) can plug into any MCP server.

Claude Desktop (MCP Host)
       |
       |  stdio — JSON-RPC 2.0
       v
GitHub Assistant MCP Server   <-- this project
       |
       |  HTTPS
       v
  GitHub REST API v3

When you ask Claude "what are the open issues in microsoft/vscode?", Claude calls this server's list_issues tool, the server fetches data from GitHub, and returns the answer — all transparently within the conversation.

Related MCP server: GitHub MCP Server

Tools

Tool	Description
`search_repos`	Search GitHub repos by keyword. Supports qualifiers like `language:python`, `stars:>1000`
`get_repo`	Get metadata for a specific repo: stars, forks, language, license, topics
`list_issues`	List open/closed issues for a repo (excludes PRs)
`get_issue`	Get the full body and details of a specific issue by number
`list_pull_requests`	List open/closed PRs including draft status and branch info

Resources

URI Pattern	Description
`repo://{owner}/{repo}/readme`	The raw README markdown for any repository

Example Conversations

"Search for the most starred Python web frameworks on GitHub"

"Tell me about the microsoft/vscode repository"

"What are the 10 most recently updated open issues in microsoft/vscode?"

"Show me the details of issue #301645 in microsoft/vscode"

"What open pull requests are there in fastapi/fastapi?"

Setup

Prerequisites

Python 3.13+
uv package manager
Claude Desktop
A GitHub Personal Access Token (for 5,000 req/hr vs 60 without)

Install

git clone https://github.com/yourusername/github-mcp
cd github-mcp

# Install dependencies
uv sync

# Copy and fill in your token
cp .env.example .env
# Edit .env and set GITHUB_TOKEN=ghp_your_token_here

Connect to Claude Desktop

Add the following to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):

{
  "mcpServers": {
    "github-assistant": {
      "command": "/path/to/uv",
      "args": [
        "--directory", "/absolute/path/to/github-mcp",
        "run", "python", "-m", "github_mcp.server"
      ],
      "env": {
        "GITHUB_TOKEN": "ghp_your_token_here"
      }
    }
  }
}

Restart Claude Desktop. You should see a hammer icon in the chat input — that's your MCP tools.

Project Structure

github-mcp/
├── src/
│   └── github_mcp/
│       ├── __init__.py
│       ├── github_client.py   # GitHub REST API wrapper (pure async httpx)
│       └── server.py          # MCP server — tool & resource definitions
├── .env                       # Your GITHUB_TOKEN (never commit this)
├── .gitignore
├── pyproject.toml
└── README.md

Architecture

github_client.py is a thin async wrapper around the GitHub REST API v3. It has no knowledge of MCP — just Python functions that return dicts. This separation makes it easy to test independently.

server.py is the MCP layer. It creates a FastMCP instance and decorates functions with @mcp.tool() and @mcp.resource(). FastMCP auto-generates the JSON Schema for each tool from Python type hints and docstrings — the same docstring you write for humans is what Claude reads to decide when to call your tool.

Transport: stdio (stdin/stdout). Claude Desktop launches this server as a subprocess and sends JSON-RPC 2.0 messages through stdin. The server writes responses to stdout. This is why we log to stderr — stdout is reserved for the protocol.

Key Concepts Learned

MCP primitives: Tools (callable functions), Resources (readable data), Prompts (templates)
JSON-RPC 2.0: The wire protocol — request/response with id, notification without
Tool descriptions matter: The LLM reads your docstring to decide when to call a tool
stdio transport: No HTTP server needed for local tools — just a process with pipes
Async Python: httpx.AsyncClient for non-blocking GitHub API calls
Auth patterns: Token injection via environment variables — never hardcoded

License

MIT

Available Tools

5 tools

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/

ParametersJSON Schema

Name	Required	Description	Default
`repo`	Yes
`owner`	Yes
`issue_number`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior3/5

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

No annotations are provided, so the description must carry the behavioral burden. The verb 'Get' signals a read-only operation, and the description says it returns details. However, it does not disclose potential edge cases such as 404s, private-repo authentication requirements, or rate limits. This is acceptable for a simple read tool but not richly transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Each sentence earns its place: a front-loaded definition, two concrete trigger examples, and a compact argument list. There is no fluff or redundant restating of the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple three-parameter read operation with an output schema present, the description covers what the tool acts on, when to use it, and what each argument means. A minor gap is not naming list_issues as the alternative for browsing multiple issues, but this does not impede correct invocation.

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?

The input schema provides no parameter descriptions, so the description must compensate. It defines all three required parameters: owner, repo, and issue_number, including the helpful hint that issue_number appears in the GitHub URL after /issues/. This is sufficient for an agent to supply correctly formed arguments.

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?

The first sentence names a specific verb ('Get'), a resource ('a specific GitHub issue'), and the scope ('full details and description'). The focus on a single issue clearly distinguishes it from listing tools like list_issues. The examples reinforce the intended object without ambiguity.

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?

The description explicitly states when to use the tool: when the user wants to read the body/description of an issue. It provides two concrete example queries. It does not explicitly contrast with list_issues, but the single-issue framing is clear enough for correct selection.

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

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"

ParametersJSON Schema

Name	Required	Description	Default
`repo`	Yes
`owner`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

No annotations are present, so the description carries the burden of disclosing behavior. 'Get' and 'detailed information' convey a read-only lookup, and the examples (stars, language) imply what fields the response contains. It does not mention auth, rate limits, or error behavior, but the output schema covers return details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose, followed by a brief usage rule with examples and a compact Args section. Every sentence adds value, and the examples are well-chosen rather than redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter read-only tool, the description covers purpose, usage, and parameter meaning. The presence of an output schema means return values need not be spelled out. It lacks explicit error-handling or authentication notes, but these are minor for a public GitHub lookup.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, so the Args section must compensate, and it does. It defines 'owner' as a GitHub username or organization, and 'repo' as the repository name (not the full URL), with several examples for each.

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?

The opening sentence, 'Get detailed information about a specific GitHub repository,' names a clear verb, object, and scope. The three example queries reinforce that the tool targets a single, known repository, distinguishing it from sibling tools like search_repos or list_issues.

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?

The description explicitly says 'Use this when the user asks about a known repository' and gives concrete query examples. It does not list alternative tools or state when not to use it, so it stops short of full when/when-not guidance.

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

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).

ParametersJSON Schema

Name	Required	Default
`repo`	Yes
`limit`	No
`owner`	Yes
`state`	No	open

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior3/5

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

There are no annotations, so the description carries the full burden, but it only states the list behavior and parameter defaults. It does not mention authentication, ordering, whether pull requests are included in issue results, or other non-obvious API behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded: one sentence says what it does, another says when to use it with two examples, then a clear Args block follows. There is no filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple list endpoint with an output schema, the description covers the core invocation requirements. It could be more complete by noting GitHub API quirks like the issues endpoint also returning pull requests, but that is an edge case.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema descriptions are absent (0% coverage), and the Args section fully compensates: owner is defined as a GitHub username/organisation, state lists its allowed values and default, and limit gets its numeric range and default. This provides exactly the meaning an agent needs beyond bare schema types.

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?

The description opens with 'List issues for a GitHub repository,' a specific verb and resource that clearly separates it from siblings like get_issue and list_pull_requests. The examples ('bugs, feature requests, or tasks') reinforce that this targets issue lists rather than repositories or PRs.

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?

'Use this when the user wants to see what bugs, feature requests, or tasks are open' gives explicit triggering scenarios with concrete examples. It does not name alternatives or state when not to use it, so it stops short of a 5.

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

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).

ParametersJSON Schema

Name	Required	Default
`repo`	Yes
`limit`	No
`owner`	Yes
`state`	No	open

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior3/5

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

With no annotations, the description must carry behavioral disclosure, and it does convey that this is a read-only listing action with state and limit controls. However, it does not mention authentication, rate limits, pagination, or ordering behavior. There is no contradiction, but the behavioral profile is only minimally fleshed out.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact, front-loads the core purpose, and uses a short example block plus an Args list. Every sentence earns its place, with no redundant restatement of the tool name.

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?

Given the tool's low conceptual complexity, the presence of an output schema, and full parameter documentation in the description, nothing essential is missing for an agent to select and call the tool. It covers what the tool does, when to use it, and how to fill each argument.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, yet the description explains all four parameters in plain language: owner, repo, state ('open', 'closed', or 'all'), and limit (1–50, default 20). This fully compensates for the bare schema, adding value beyond the field names and types.

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?

The description names a specific verb and resource — 'List pull requests for a GitHub repository' — and adds a distinguishing use case: showing proposed or recently merged code changes. Example queries like 'what PRs are open in fastapi/fastapi?' make it easy for an agent to separate this from sibling tools such as list_issues.

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?

It explicitly says 'Use this when the user wants to see...' and gives realistic example queries. It does not state when-not-to-use or name an alternative tool, but the context is clear enough for list-related PR requests.

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

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)

ParametersJSON Schema

Name	Required	Default
`sort`	No	stars
`limit`	No
`query`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior3/5

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

No annotations are provided, so the description carries the behavioral burden. It explains query qualifiers, sort options, and limit behavior, and the search wording implies a read-only operation. However, it does not mention rate limits, authentication needs, result truncation, or error behavior, which would add useful transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-organized and efficient: an opening purpose statement, a clear usage trigger, and a compact Args section. Every sentence adds value, and the most important information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description does not need to explain return values. It sufficiently covers all three parameters, how to construct queries, valid sort values, and limits. Minor omissions like rate limits and pagination are not critical for a simple search tool, but would make it fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, so the description must fully explain the parameters. It does: query includes qualifiers and examples, sort lists all valid values with the default, and limit specifies range and default. This is strong compensation for the bare schema.

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?

The description opens with a specific verb and resource — 'Search GitHub repositories' — and immediately distinguishes this tool from siblings like get_repo, list_issues, and get_issue. The example user phrasings further clarify the exact discovery use case.

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?

It explicitly states when to use the tool: 'Use this when the user wants to discover repositories' and gives concrete example queries. It does not explicitly say when not to use it or name alternative tools, but the stated context is clear enough for an agent to select it correctly.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

5 tool updatesv0.1.0Aug 30, 2026
- First observedget_issue
- First observedget_repo
- First observedlist_issues
- First observedlist_pull_requests
- First observedsearch_repos

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0

Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count5/5

Five tools is well-scoped for a read-only GitHub exploration assistant. Each tool covers a distinct core operation without unnecessary redundancy.

Completeness3/5

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.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

ForumsOAuth
io.github.basehub-ai
Ask any GitHub repository a question. Get source-backed answers.
Search Version Control Developer Tools
336
smithery-ai-github
ai.smithery
Access the GitHub API, enabling file operations, repository management, search functionality, and…
Version Control Developer Tools CI/CD & DevOps
295
searchcode A
com.searchcode
Code intelligence for LLMs. Analyze, search, and retrieve code from any public git repository.
Search Code Analysis Version Control
62
GitHubOAuth
io.github.github
Connect AI assistants to GitHub - manage repos, issues, PRs, and workflows through natural language.
Version Control Developer Tools CI/CD & DevOps
1232,723

Related MCP Servers

GitBridge
Version Control Search Documentation Access
saksham-jain177
A
license
Not graded
quality
D
maintenance
Enables AI assistants to analyze GitHub repositories, including fetching repository details, searching, and retrieving README content.
Updated a year ago (2025-05-16 07:09 UTC)
467
2
ISC
GitHub MCP Server
Version Control Developer Tools
Evin009
F
license
Not graded
quality
D
maintenance
Enables users to interact with GitHub via natural language requests, executing API calls and returning structured responses.
Updated 3 months ago (2026-06-13 04:50 UTC)
-
GitHub Trending MCP
Version Control Search Developer Tools
curlygirltech
F
license
Not graded
quality
D
maintenance
Enables natural language queries to search GitHub for trending repositories by topic, summarize project READMEs, and compare multiple repos to uncover ecosystem patterns.
Updated 6 months ago (2026-03-04 16:17 UTC)
2
-
GitHub MCP Server
Version Control Developer Tools
decuma02
A
license
Not graded
quality
C
maintenance
Enables LLM agents to search, read, and create GitHub issues and pull requests via natural language, using the GitHub API.
Updated 2 months ago (2026-07-07 11:52 UTC)
1
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Kamalesh-Kavin/github-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server