Skip to main content
Glama
Ryan0204

github-repo-mcp

by Ryan0204

GitHub 仓库 MCP

铁匠徽章

目录

Related MCP server: UIThub MCP Server

✨ 主要特点

  • 💻 兼容 Cursor、Windsurf、Claude Desktop 和其他支持stdio协议的 MCP 客户端

  • 🔎 浏览任何公共 GitHub 存储库的内容

  • 📂 浏览存储库目录和子目录

  • 📝 查看代码和文本文件的内容

  • 📦通过包管理器轻松安装

入门

先决条件

安装服务器需要您的系统具备以下条件:

  • Node.js 18+

  • npm 或 yarn

步骤1.安装

您可以使用 Smithery、NPX 或 IDE 的 mcp.json 中的设置来安装和运行 GitHub Repo MCP:

MacOS

npx github-repo-mcp

Windows NPX

cmd /c npx -y github-repo-mcp

通过 .cursor/mcp.json 实现 Windows NPX

{
  "mcpServers": {
    "github-repo-mcp": {
      "command": "wsl",
      "args": [
        "bash",
        "-c",
        "cmd /c npx -y github-repo-mcp"
      ],
      "enabled": true
    }
  }
}

通过 .cursor/mcp.json 的 Windows NPX(如果未设置路径)

# Find the full path to npx first
which npx
{
  "mcpServers": {
    "github-repo-mcp": {
      "command": "wsl",
      "args": [
        "bash",
        "-c",
        "'/home/[username]/.nvm/versions/node/v20.18.0/bin/npx github-repo-mcp'"
      ],
      "enabled": true
    }
  }
}

通过 Smithery 安装

要通过Smithery自动为 Claude Desktop 安装 GitHub Repo MCP:

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

如果未注册,请等待几秒钟或点击刷新按钮几次。如果仍然无法注册,请确保您输入了正确的命令。

步骤2.配置

GitHub Repo MCP 服务器在访问 GitHub API 时可以使用 GitHub 令牌来获得更高的速率限制。

环境变量

多变的

必需的

默认

描述

GITHUB_TOKEN

不

没有任何

您的 GitHub 个人访问令牌,用于更高的速率限制

设置 GitHub 令牌(可选)

虽然服务器无需身份验证即可运行,但 GitHub API 对未经身份验证的请求的速率限制要低得多。要提高速率限制:

  1. 在https://github.com/settings/tokens创建个人访问令牌

  2. 在 mcp.json 中将令牌设置为环境变量:

{
  "mcpServers": {
    "github-repo-mcp": {
      "command": "...",
      "args": [
        ...
      ],
      "env": {
        "GITHUB_TOKEN": "Your_Github_Token"
      }
      "enabled": true,
    }
  }
}

功能概述

存储库浏览工具

该服务器提供了三个与 GitHub 存储库交互的主要工具:

1. getRepoAllDirectories

列出 GitHub 存储库根目录下的所有文件和目录。

2. getRepoDirectories

列出 GitHub 存储库中特定目录的内容。

  • 参数:

    • repoUrl :GitHub 存储库的 URL

    • path :要获取的目录路径(例如“src”)

3. getRepoFile

从 GitHub 存储库检索并显示特定文件的内容。

  • 参数:

    • repoUrl :GitHub 存储库的 URL

    • path :要获取的文件路径(例如“src/index.js”)

使用示例

以下是如何将这些工具与 AI 助手一起使用的一些示例:

  1. 浏览存储库根目录:要求您的 AI 助手“向我显示https://github.com/Ryan0204/github-repo-mcp存储库的内容”

  2. 探索特定目录:询问“ https://github.com/Ryan0204/github-repo-mcp的 src 目录中有哪些文件?”

  3. 查看文件:询问“显示https://github.com/Ryan0204/github-repo-mcp中的 README.md 文件”

限制

  • 速率限制:如果没有身份验证,GitHub API 有严格的速率限制(每小时 60 个请求)

  • 私有存储库:除非提供具有适当权限的令牌,否则只能访问公共存储库

  • 二进制文件:服务器检测常见的二进制文件扩展名,但不会显示其内容

  • 大文件:GitHub API 对可检索文件的大小有限制

故障排除

以下是一些常见问题及其解决方案:

  • 超出速率限制:按照配置部分中的说明设置 GitHub 令牌

  • 未找到命令:确保包已全局安装

  • 连接错误:检查您的互联网连接和 GitHub API 状态

如果您遇到任何问题,请检查输出中的错误消息或在 GitHub 存储库中创建问题。


尽情享受吧!☺️

Available Tools

3 tools
getRepoAllDirectoriesD
ParametersJSON Schema
NameRequiredDescriptionDefault
repoUrlYesThe URL of the Github repo

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

getRepoDirectoriesD
ParametersJSON Schema
NameRequiredDescriptionDefault
pathYesThe directory path to fetch
repoUrlYesThe URL of the Github repo

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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

getRepoFileD
ParametersJSON Schema
NameRequiredDescriptionDefault
pathYesThe file path to fetch
repoUrlYesThe URL of the Github repo

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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.

  1. 3 tool updatesv1.0.0
    • First observedgetRepoAllDirectories
    • First observedgetRepoDirectories
    • First observedgetRepoFile

TDQS

D1.4/5.0

Scored across 3 tools

Disambiguation2/5

The tools have overlapping purposes with unclear boundaries: getRepoAllDirectories and getRepoDirectories appear to serve similar directory-related functions without descriptions to clarify their differences, while getRepoFile is distinct but the directory tools are ambiguous. This overlap will likely cause misselection between the two directory tools.

Naming Consistency4/5

The naming follows a consistent camelCase pattern (getRepoAllDirectories, getRepoDirectories, getRepoFile) with a clear verb_noun structure, though the lack of descriptions makes it harder to assess intent. There are no deviations in style, but the similarity in names for the directory tools slightly reduces clarity.

Tool Count2/5

With only 3 tools, this server feels thin for a GitHub repository domain, as it lacks essential operations like create, update, delete, or search. The limited scope suggests incomplete coverage, making it difficult for agents to perform comprehensive repository management tasks.

Completeness1/5

The tool surface is severely incomplete for a GitHub repository server: it only includes retrieval tools for directories and files, missing core CRUD operations (e.g., create repo, update files, delete items), search functionality, and lifecycle management. This will cause significant agent failures in handling typical repository workflows.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers