GitHub Chat MCP
GitHub 채팅 MCP
GitHub Chat API를 사용하여 GitHub 저장소를 분석하고 쿼리하기 위한 모델 컨텍스트 프로토콜(MCP)입니다. 공식 사이트: https://github-chat.com
설치
지엑스피1
클로드와 함께 사용해 보세요!
예시 프롬프트:
"github-chat-mcp를 사용하여 React 저장소를 분석하세요"
"github-chat-mcp로 TypeScript 저장소를 인덱싱하고 아키텍처에 대해 문의하세요"
GitHub Chat MCP 서버
Related MCP server: MCP GitHub Reader
설치 지침
무엇보다 먼저 GitHub Chat API 키가 있는지 확인하세요. 서비스를 사용하려면 필수입니다.
먼저 uv를 설치하세요.
MacOS/리눅스:
curl -LsSf https://astral.sh/uv/install.sh | sh윈도우:
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"커서를 사용한 설정(권장)
mcp.json에서:
{
"mcpServers": {
"github-chat": {
"command": "uvx",
"args": [
"github-chat-mcp"
]
}
}
}위의 내용은 프리미엄 릴리스이므로 envs가 필요하지 않습니다.
Claude Desktop으로 설정
# claude_desktop_config.json
# Can find location through:
# Hamburger Menu -> File -> Settings -> Developer -> Edit Config
# Must perform: brew install uv
{
"mcpServers": {
"github-chat": {
"command": "uvx",
"args": ["github-chat-mcp"],
"env": {
}
}
}
}Smithery를 통해 설치
Smithery를 통해 Claude Desktop용 GitHub Chat을 자동으로 설치할 수 있습니다.
npx -y @smithery/cli install github-chat-mcp --client claudeClaude와 함께 GitHub Chat 사용하기
먼저 GitHub 저장소를 인덱싱하세요: " https://github.com/username/repo 에서 GitHub 저장소를 인덱싱하세요"
그런 다음 저장소에 대해 다음과 같이 질문해 보세요. "이 저장소에 사용된 핵심 기술 스택은 무엇입니까?"
디버깅
달리다:
npx @modelcontextprotocol/inspector uvx github-chat-mcp로컬/개발자 설정 지침
복제 저장소
git clone https://github.com/yourusername/github-chat-mcp.git
종속성 설치
먼저 uv를 설치하세요.
MacOS/리눅스:
curl -LsSf https://astral.sh/uv/install.sh | sh윈도우:
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"그런 다음 MCP 서버 종속성을 설치합니다.
cd github-chat-mcp
# Create virtual environment and activate it
uv venv
source .venv/bin/activate # MacOS/Linux
# OR
.venv/Scripts/activate # Windows
# Install dependencies
uv syncClaude Desktop으로 설정
MCP CLI SDK 사용
# `pip install mcp[cli]` if you haven't
mcp install /ABSOLUTE/PATH/TO/PARENT/FOLDER/github-chat-mcp/src/github_chat_mcp/server.py -v "GITHUB_API_KEY=API_KEY_HERE"수동으로
# claude_desktop_config.json
# Can find location through:
# Hamburger Menu -> File -> Settings -> Developer -> Edit Config
{
"mcpServers": {
"github-chat": {
"command": "uv",
"args": [
"--directory",
"/ABSOLUTE/PATH/TO/PARENT/FOLDER/github-chat-mcp",
"run",
"github-chat-mcp"
],
"env": {
}
}
}
}Claude와 함께 GitHub Chat 사용하기
먼저 GitHub 저장소를 인덱싱하세요: " https://github.com/username/repo 에서 GitHub 저장소를 인덱싱하세요"
그런 다음 저장소에 대해 다음과 같이 질문해 보세요. "이 저장소에 사용된 핵심 기술 스택은 무엇입니까?"
디버깅
달리다:
# If mcp cli installed (`pip install mcp[cli]`)
mcp dev /ABSOLUTE/PATH/TO/PARENT/FOLDER/github-chat-mcp/src/github_chat_mcp/server.py
# If not
npx @modelcontextprotocol/inspector \
uv \
--directory /ABSOLUTE/PATH/TO/PARENT/FOLDER/github-chat-mcp \
run \
github-chat-mcp그런 다음 http://localhost:5173 에서 MCP Inspector에 접속하세요. Inspector의 환경 변수 GITHUB_API_KEY 에 GitHub API 키를 추가해야 할 수도 있습니다.
노트
로깅 수준은
FASTMCP_LOG_LEVEL환경 변수(예:FASTMCP_LOG_LEVEL="ERROR")를 통해 조정 가능합니다.이 MCP 서버는 두 가지 주요 도구를 제공합니다.
저장소 인덱싱 - GitHub 저장소 인덱싱 및 분석
저장소 쿼리 - 인덱스된 저장소에 대한 질문하기
Available Tools
2 toolsindex_repositoryA
Index a GitHub repository to analyze its codebase. This must be done before asking questions about the repository.
| Name | Required | Description | Default |
|---|---|---|---|
| repo_url | Yes | The GitHub repository URL to index (format: https://github.com/username/repo). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that indexing is required before querying (a behavioral constraint) but doesn't mention other traits like whether indexing is idempotent, how long it takes, error conditions, or what 'analyze its codebase' entails operationally. The description adds some context but leaves significant behavioral aspects unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste: the first states the purpose, the second provides crucial usage guidance. Every word earns its place, and the most important information (the prerequisite nature) is front-loaded in the second sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation operation with no annotations and no output schema), the description is reasonably complete for its core purpose and workflow context. It explains why indexing is needed and how it relates to querying, though it could better address behavioral aspects like what 'indexing' actually does or what happens on repeated calls.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the single parameter 'repo_url' is fully documented in the schema with format details). The description doesn't add any parameter-specific information beyond what the schema provides, so it meets the baseline of 3 for high schema coverage without compensating value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('index') and resource ('GitHub repository') with the purpose 'to analyze its codebase'. It distinguishes from the sibling tool 'query_repository' by explaining this is a prerequisite step before querying.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool ('before asking questions about the repository') and implies an alternative workflow with the sibling tool 'query_repository'. Provides clear context about the prerequisite nature of indexing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
query_repositoryB
Ask questions about a GitHub repository and receive detailed AI responses. The repository must be indexed first.
| Name | Required | Description | Default |
|---|---|---|---|
| repo_url | Yes | The GitHub repository URL to query (format: https://github.com/username/repo). | |
| question | Yes | The question to ask about the repository. | |
| conversation_history | No | Previous conversation history for multi-turn conversations. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the indexing prerequisite but doesn't describe other important behaviors: what types of questions are supported, whether there are rate limits, authentication requirements, response format, or error conditions. For a tool with AI responses and conversation history, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two sentences that directly state the tool's purpose and key prerequisite. Every word earns its place, and the information is front-loaded with no unnecessary elaboration or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that queries repositories with AI responses and supports conversation history, the description is incomplete. With no annotations and no output schema, the description doesn't explain what the AI responses contain, how conversation history should be structured, error handling, or limitations. The indexing prerequisite is mentioned, but other critical context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds minimal value beyond the schema - it mentions 'questions about a GitHub repository' which aligns with the parameters but doesn't provide additional semantic context about how parameters interact or special considerations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Ask questions about a GitHub repository and receive detailed AI responses.' It specifies the verb ('ask questions'), resource ('GitHub repository'), and outcome ('detailed AI responses'). However, it doesn't explicitly differentiate from its sibling tool 'index_repository' beyond mentioning indexing as a prerequisite.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context by stating 'The repository must be indexed first,' which implies a prerequisite relationship with 'index_repository.' However, it doesn't explicitly state when to use this tool versus alternatives or provide clear exclusions. The guidance is implied rather than explicit.
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.
2 tool updates
- First observed
index_repository - First observed
query_repository
TDQS
The two tools have clearly distinct purposes: index_repository is for preparing the repository for analysis, while query_repository is for asking questions about the indexed repository. There is no overlap or ambiguity between them.
Both tools follow a consistent verb_noun pattern (index_repository and query_repository), using the same naming convention and structure throughout the set.
With only 2 tools, the server feels too thin for its apparent purpose of GitHub repository analysis. It lacks essential operations like listing repositories, managing indexes, or handling errors, which limits functionality and could cause agent failures.
The tool surface is severely incomplete for GitHub repository analysis. It covers only indexing and querying, missing core operations such as repository discovery, index management, or error handling, leading to significant gaps in workflow coverage.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
An MCP server that gives your AI access to the source code and docs of all public github repos
Create, deploy, and operate MCP servers directly from your GitHub repositories.
Driflyte MCP server which lets AI assistants query topic-specific knowledge from web and GitHub.
A MCP server built for developers enabling Git based project management with project and personal…
Related MCP Servers
- AlicenseCqualityDmaintenanceAn MCP server that analyzes local or remote GitHub repositories, providing intelligent code context and structure to AI coding assistants.1013MIT
- AlicenseDqualityDmaintenanceA lightweight MCP server for bringing GitHub repositories into context for large language models, enabling repository analysis, file access, and search without local cloning.4196Apache 2.0
- AlicenseNot gradedqualityDmaintenanceAn MCP server that provides tools for interacting with the GitHub API, enabling AI assistants to query repositories, pull requests, issues, commits, users, and more.467ISC
- AlicenseNot gradedqualityBmaintenanceAn MCP server that enables GitHub API operations such as managing repositories, issues, and pull requests through natural language.467ISC
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/AsyncFuncAI/github-chat-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server