Skip to main content
Glama
enesjakozh
AsyncFuncAI

GitHub Chat MCP

by AsyncFuncAI
OverviewSchemaRelated ServersScoreDiscussions
Python
Remote

Chat de GitHub MCP

Un Protocolo de Contexto de Modelo (MCP) para analizar y consultar repositorios de GitHub mediante la API de GitHub Chat. Sitio oficial: https://github-chat.com

Instalación

# Install with pip
pip install github-chat-mcp

# Or install with the newer uv package manager
uv install github-chat-mcp

  1. ¡Empieza a usarlo con Claude!

Ejemplos de indicaciones:

  • Utiliza github-chat-mcp para analizar el repositorio de React.

  • Indexa el repositorio de TypeScript con github-chat-mcp y pregunta sobre su arquitectura.

Servidor MCP de GitHub Chat

insignia de herrería

Related MCP server: MCP GitHub Reader

Instrucciones de configuración

Antes de nada, asegúrate de tener una clave API de GitHub Chat. Es necesaria para usar el servicio.

Primero instale uv.

MacOS/Linux:

curl -LsSf https://astral.sh/uv/install.sh | sh

Ventanas:

powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"

Configuración con cursor (recomendado)

En mcp.json:

{
  "mcpServers": {
    "github-chat": {
      "command": "uvx",
      "args": [
        "github-chat-mcp"
      ]
    }
  }
}

Con lo anterior, no se requieren entornos ya que es una versión freemium.

Configuración con 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": {
      }
    }
  }
}

Instalación mediante herrería

Puedes instalar GitHub Chat para Claude Desktop automáticamente a través de Smithery:

npx -y @smithery/cli install github-chat-mcp --client claude

Usando GitHub Chat con Claude

  1. Primero indexe un repositorio de GitHub: "Indexar el repositorio de GitHub en https://github.com/username/repo "

  2. Luego haga preguntas sobre el repositorio: "¿Cuál es la pila tecnológica principal utilizada en este repositorio?"

Depuración

Correr:

npx @modelcontextprotocol/inspector uvx github-chat-mcp

Instrucciones de configuración local/de desarrollo

Clonar repositorio

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

Instalar dependencias

Primero instale uv.

MacOS/Linux:

curl -LsSf https://astral.sh/uv/install.sh | sh

Ventanas:

powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"

A continuación, instale las dependencias del servidor 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 sync

Configuración con Claude Desktop

Uso del SDK CLI de MCP

# `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"

A mano

# 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": {
      }
    }
  }
}

Usando GitHub Chat con Claude

  1. Primero indexe un repositorio de GitHub: "Indexar el repositorio de GitHub en https://github.com/username/repo "

  2. Luego haga preguntas sobre el repositorio: "¿Cuál es la pila tecnológica principal utilizada en este repositorio?"

Depuración

Correr:

# 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

Luego, accede al Inspector de MCP en http://localhost:5173 . Es posible que debas agregar tu clave de API de GitHub en las variables de entorno del inspector, bajo GITHUB_API_KEY .

Notas

  • El nivel de registro se puede ajustar a través de la variable de entorno FASTMCP_LOG_LEVEL (por ejemplo, FASTMCP_LOG_LEVEL="ERROR" )

  • Este servidor MCP proporciona dos herramientas principales:

    1. Indexación de repositorios: indexar y analizar un repositorio de GitHub

    2. Consulta de repositorio: haga preguntas sobre el repositorio indexado

Available Tools

2 tools
index_repositoryA

Index a GitHub repository to analyze its codebase. This must be done before asking questions about the repository.

ParametersJSON Schema
NameRequiredDescriptionDefault
repo_urlYesThe GitHub repository URL to index (format: https://github.com/username/repo).

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

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
repo_urlYesThe GitHub repository URL to query (format: https://github.com/username/repo).
questionYesThe question to ask about the repository.
conversation_historyNoPrevious conversation history for multi-turn conversations.

TDQS

B3.2/5.0
Behavior2/5

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.

Conciseness5/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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.

  1. 2 tool updates
    • First observedindex_repository
    • First observedquery_repository
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0
Disambiguation5/5

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.

Naming Consistency5/5

Both tools follow a consistent verb_noun pattern (index_repository and query_repository), using the same naming convention and structure throughout the set.

Tool Count2/5

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.

Completeness2/5

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

ActivityInactive
ResponsivenessNo issues

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

Related MCP Servers

Appeared in Searches

Latest Blog Posts

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