de en es ja ko ru zh

GitHub Enterprise MCP Server

Name: GitHub Enterprise MCP Server
Author: ddukbg

by ddukbg

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

GitHub Enterprise MCP 服务器

用于与 GitHub Enterprise API 集成的 MCP（模型上下文协议）服务器。该服务器提供 MCP 接口，方便用户在 Cursor 中轻松访问 GitHub Enterprise 的仓库信息、问题、PR 等。

兼容性

该项目主要针对 GitHub Enterprise Server 环境设计，但也适用于：

GitHub.com
GitHub 企业云

注意：某些企业特定功能（如许可证信息和企业统计信息）不适用于 GitHub.com 或 GitHub Enterprise Cloud。

Related MCP server: GitHub CLI MCP Server

主要特点

从 GitHub Enterprise 实例检索存储库列表
获取详细的存储库信息
列出存储库分支
查看文件和目录内容
管理问题和拉取请求
存储库管理（创建、更新、删除）
GitHub Actions 工作流管理
用户管理（列出、创建、更新、删除、暂停/取消暂停用户）
访问企业统计数据
增强的错误处理和用户友好的响应格式

入门

先决条件

Node.js 18 或更高版本
访问 GitHub Enterprise 实例
个人访问令牌（PAT）

Docker 安装和设置

选项 1：使用 Docker 运行

构建 Docker 镜像：
```
docker build -t github-enterprise-mcp .
```

使用环境变量运行 Docker 容器：

docker run -p 3000:3000 \
  -e GITHUB_TOKEN="your_github_token" \
  -e GITHUB_ENTERPRISE_URL="https://github.your-company.com/api/v3" \
  -e DEBUG=true \
  github-enterprise-mcp

注意：Dockerfile 默认配置为使用--transport http运行。如果需要更改此设置，可以覆盖以下命令：

docker run -p 3000:3000 \
  -e GITHUB_TOKEN="your_github_token" \
  -e GITHUB_ENTERPRISE_URL="https://github.your-company.com/api/v3" \
  -e DEBUG=true \
  github-enterprise-mcp node dist/index.js --transport http --debug

选项 2：使用 Docker Compose

在项目根目录中创建一个包含所需环境变量的.env文件：

GITHUB_ENTERPRISE_URL=https://github.your-company.com/api/v3
GITHUB_TOKEN=your_github_token
DEBUG=true

使用 Docker Compose 启动容器：
```
docker-compose up -d
```
检查日志：
```
docker-compose logs -f
```
停止容器：
```
docker-compose down
```

安装和设置

本地开发（使用并发模式）

对于具有自动重新编译和服务器重启功能的主动开发，建议使用此方法：

克隆存储库并安装所需的包：

git clone https://github.com/ddukbg/github-enterprise-mcp.git
cd github-enterprise-mcp
npm install

运行开发服务器：
```
export GITHUB_TOKEN="your_github_token"
export GITHUB_ENTERPRISE_URL="https://github.your-company.com/api/v3"
npm run dev
```
这将：
- 文件更改时自动编译 TypeScript 代码
- 编译文件更新后重新启动服务器
- 以 HTTP 模式运行服务器以进行基于 URL 的连接
使用 URL 模式连接到 Cursor，如下所述

生产的安装和设置

选项 1：使用 URL 模式（推荐用于本地开发）

此方法最稳定，推荐用于本地开发或测试：

克隆存储库并安装所需的包：

git clone https://github.com/ddukbg/github-enterprise-mcp.git
cd github-enterprise-mcp
npm install

构建项目：
```
npm run build
chmod +x dist/index.js
```

运行服务器：

export GITHUB_TOKEN="your_github_token"
export GITHUB_ENTERPRISE_URL="https://github.your-company.com/api/v3"
node dist/index.js --transport http --debug

使用URL方式连接Cursor：

将以下内容添加到 Cursor 的.cursor/mcp.json文件中：

{
  "mcpServers": {
    "github-enterprise": {
      "url": "http://localhost:3000/sse"
    }
  }
}

选项 2：作为全局命令安装（npm 链接）

此方法对于本地开发很有用：

# After cloning the repository
git clone https://github.com/ddukbg/github-enterprise-mcp.git
cd github-enterprise-mcp

# Install required packages
npm install

# Build
npm run build
chmod +x dist/index.js

# Link globally
npm link

# Run as a global command
export GITHUB_TOKEN="your_github_token"
export GITHUB_ENTERPRISE_URL="https://github.your-company.com/api/v3"
github-enterprise-mcp --transport=http --debug

选项 3：使用 npx（包发布时）

如果该包已发布到公共 npm 注册表：

npx @ddukbg/github-enterprise-mcp --token=your_github_token --github-enterprise-url=https://github.your-company.com/api/v3

与AI工具集成

克劳德桌面

将以下内容添加到您的claude_desktop_config.json中：

{
  "mcpServers": {
    "github-enterprise": {
      "command": "npx",
      "args": ["-y", "@ddukbg/github-enterprise-mcp", "--token=YOUR_GITHUB_TOKEN", "--github-enterprise-url=YOUR_GITHUB_ENTERPRISE_URL"]
    }
  }
}

用您的实际值替换YOUR_GITHUB_TOKEN和YOUR_GITHUB_ENTERPRISE_URL 。

光标

推荐：URL模式（最稳定）

为了在 Cursor 中最可靠的操作，建议使用 URL 模式：

在单独的终端窗口中启动服务器：

cd /path/to/github-enterprise-mcp
GITHUB_ENTERPRISE_URL="https://github.your-company.com/api/v3" GITHUB_TOKEN="your_github_token" node dist/index.js --transport http

配置 Cursor 的 MCP 设置：
- 打开 Cursor 并转到**“设置”**
- 导航至AI > MCP 服务器
- 编辑你的.cursor/mcp.json文件：
```
{
  "mcpServers": {
    "github-enterprise": {
      "url": "http://localhost:3000/sse"
    }
  }
}
```
重新启动 Cursor 以应用更改

替代方案：命令模式

或者，您可以将 Cursor 配置为使用命令模式，尽管 URL 模式更可靠：

打开 Cursor 并转到**“设置”**
导航至AI > MCP 服务器
点击**“添加 MCP 服务器”**
输入以下详细信息：
- 名称：GitHub Enterprise
- 命令： npx
- 参数： @ddukbg/github-enterprise-mcp
- 环境变量：
  - GITHUB_ENTERPRISE_URL ：您的 GitHub Enterprise API URL
  - GITHUB_TOKEN ：您的 GitHub 个人访问令牌

或者，您可以手动编辑.cursor/mcp.json文件以包含：

{
  "mcpServers": {
    "github-enterprise": {
      "command": "npx",
      "args": [
        "@ddukbg/github-enterprise-mcp"
      ],
      "env": {
        "GITHUB_ENTERPRISE_URL": "https://github.your-company.com/api/v3",
        "GITHUB_TOKEN": "your_github_token"
      }
    }
  }
}

语言配置

此 MCP 服务器支持英语和韩语。您可以使用以下方式配置语言：

环境变量

# Set language to Korean
export LANGUAGE=ko

# Or in .env file
LANGUAGE=ko

命令行参数

# Set language to Korean
node dist/index.js --language ko

如果未指定，默认语言为英语。

HTTP 模式中的附加选项

--debug ：启用调试日志记录
--github-enterprise-url <URL> ：设置 GitHub Enterprise API URL
--token <TOKEN> ：设置 GitHub 个人访问令牌
--language <LANG> ：设置语言（en 或 ko，默认值：en）

可用的 MCP 工具

该 MCP 服务器提供以下工具：

工具名称	描述	参数	所需的 PAT 权限
`list-repositories`	检索用户或组织的存储库列表	`owner` ：用户名/组织名称`isOrg` ：是否为组织`type` ：存储库类型`sort` ：排序条件`page` ：页码`perPage` ：每页项目数	`repo`
`get-repository`	获取详细的存储库信息	`owner` ：存储库所有者`repo` ：存储库名称	`repo`
`list-branches`	列出存储库的分支	`owner` ：仓库所有者`repo` ：仓库名称`protected_only` ：是否仅显示受保护的分支`page` ：页码`perPage` ：每页项目数	`repo`
`get-content`	检索文件或目录内容	`owner` ：存储库所有者`repo` ：存储库名称`path` ：文件/目录路径`ref` ：分支/提交（可选）	`repo`
`list-pull-requests`	列出存储库中的拉取请求	`owner` ：仓库所有者`repo` ：仓库名称`state` ：PR 状态 filter `sort` ：排序标准`direction` ：排序方向`page` ：页码`per_page` ：每页项目数	`repo`
`get-pull-request`	获取拉取请求详细信息	`owner` ：仓库所有者`repo` ：仓库名称`pull_number` ：拉取请求编号	`repo`
`create-pull-request`	创建新的拉取请求	`owner` ：仓库所有者`repo` ：仓库名称`title` ：PR 标题`head` ：头部分支`base` ：基础分支`body` ：PR 描述`draft` ：创建为草稿 PR	`repo`
`merge-pull-request`	合并拉取请求	`owner` ：仓库所有者`repo` ：仓库名称`pull_number` ：拉取请求编号`merge_method` ：合并方法`commit_title` ：提交标题`commit_message` ：提交消息	`repo`
`list-issues`	列出存储库中的问题	`owner` ：仓库所有者`repo` ：仓库名称`state` ：问题状态 filter `sort` ：排序标准`direction` ：排序方向`page` ：页码`per_page` ：每页项目数	`repo`
`get-issue`	获取问题详细信息	`owner` ：存储库所有者`repo` ：存储库名称`issue_number` ：发行编号	`repo`
`list-issue-comments`	列出对问题或拉取请求的评论	`owner` ：存储库所有者`repo` ：存储库名称`issue_number` ：问题/PR 编号`page` ：页码`per_page` ：每页项目数	`repo`
`create-issue`	创建新问题	`owner` ：存储库所有者`repo` ：存储库名称`title` ：问题标题`body` ：问题正文内容`labels` ：标签名称数组`assignees` ：用户登录数组`milestone` ：里程碑 ID	`repo`
`create-repository`	创建新的存储库	`name` ：仓库名称`description` ：仓库描述`private` ：是否私有`auto_init` ：使用 README 初始化`gitignore_template` ：添加 .gitignore `license_template` ：添加许可证`org` ：组织名称	`repo`
`update-repository`	更新存储库设置	`owner` ：存储库所有者`repo` ：存储库名称`description` ：新描述`private` ：更改隐私`default_branch` ：更改默认分支`has_issues` ：启用/禁用问题`has_projects` ：启用/禁用项目`has_wiki` ：启用/禁用 wiki `archived` ：存档/取消存档	`repo`
`delete-repository`	删除存储库	`owner` ：仓库所有者`repo` ：仓库名称`confirm` ：确认（必须为真）	`delete_repo`
`list-workflows`	列出 GitHub Actions 工作流程	`owner` ：存储库所有者`repo` ：存储库名称`page` ：页码`perPage` ：每页项目数	`actions:read`
`list-workflow-runs`	列出工作流程运行	`owner` ：存储库所有者`repo` ：存储库名称`workflow_id` ：工作流 ID/文件名`branch` ：按分支过滤`status` ：按状态过滤`page` ：页码`perPage` ：每页项目数	`actions:read`
`trigger-workflow`	触发工作流	`owner` ：存储库所有者`repo` ：存储库名称`workflow_id` ：工作流 ID/文件名`ref` ：Git 参考`inputs` ：工作流输入	`actions:write`
`get-license-info`	获取 GitHub Enterprise 许可证信息	-	需要 site_admin（管理员）帐户
`get-enterprise-stats`	获取 GitHub Enterprise 系统统计信息	-	需要 site_admin（管理员）帐户

注意：对于企业专用工具（ get-license-info和get-enterprise-stats ），需要具有站点管理员权限的用户。建议使用经典个人访问令牌 (Classic Personal Access Token)，因为细粒度令牌可能不支持这些企业级权限。

使用 Cursor 中的工具

设置好 MCP 服务器并配置 Cursor 连接到该服务器后，您就可以直接在 Cursor 的 AI 聊天中使用 GitHub Enterprise 工具。以下是一些示例：

列出存储库

mcp_github_enterprise_list_repositories(owner="octocat")

获取存储库信息

mcp_github_enterprise_get_repository(owner="octocat", repo="hello-world")

列出拉取请求

mcp_github_enterprise_list_pull_requests(owner="octocat", repo="hello-world", state="open")

管理问题

# List issues
mcp_github_enterprise_list_issues(owner="octocat", repo="hello-world", state="all")
# Get issue details
mcp_github_enterprise_get_issue(owner="octocat", repo="hello-world", issue_number=1)

# Get issue/PR comments
mcp_github_enterprise_list_issue_comments(owner="octocat", repo="hello-world", issue_number=1)


# Create a new issue
mcp_github_enterprise_create_issue(
  owner="octocat", 
  repo="hello-world",
  title="Found a bug",
  body="Here is a description of the bug",
  labels=["bug", "important"]
)

使用存储库内容

mcp_github_enterprise_get_content(owner="octocat", repo="hello-world", path="README.md")

存储库管理

# Create a new repository
mcp_github_enterprise_create_repository(
  name="new-project",
  description="This is a new project",
  private=true,
  auto_init=true
)

# Update repository settings
mcp_github_enterprise_update_repository(
  owner="octocat",
  repo="hello-world",
  description="Updated description",
  has_issues=true
)

用户管理（仅限企业）

这些功能专为 GitHub Enterprise Server 环境设计，需要管理权限：

# List all users in the GitHub Enterprise instance
mcp_github_enterprise_list_users(filter="active", per_page=100)

# Get a specific user's details
mcp_github_enterprise_get_user(username="octocat")

# Create a new user (Enterprise only)
mcp_github_enterprise_create_user(
  login="newuser",
  email="newuser@example.com",
  name="New User",
  company="ACME Inc."
)

# Update a user's information (Enterprise only)
mcp_github_enterprise_update_user(
  username="octocat",
  email="updated-email@example.com",
  location="San Francisco"
)

# Suspend a user (Enterprise only)
mcp_github_enterprise_suspend_user(
  username="octocat",
  reason="Violation of terms of service"
)

# Unsuspend a user (Enterprise only)
mcp_github_enterprise_unsuspend_user(username="octocat")

# List organizations a user belongs to
mcp_github_enterprise_list_user_orgs(username="octocat")

API 改进

灵活的 API URL 配置（支持各种环境变量和命令行参数）
增强错误处理和超时管理
用户友好的响应格式和消息

贡献

欢迎贡献代码！欢迎提交 Pull 请求。

执照

国际学习中心

Available Tools

28 tools

create-issueD

ParametersJSON Schema

Name	Required	Description
`body`	No	Issue content
`repo`	Yes	Repository name
`owner`	Yes	Repository owner (user or organization)
`title`	Yes	Issue title
`labels`	No	Label list
`assignees`	No	Assignee list
`milestone`	No	Milestone ID

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.

create-pull-requestD

ParametersJSON Schema

Name	Required	Description
`owner`	Yes	Repository owner (user or organization)
`repo`	Yes	Repository name
`title`	Yes	Pull request title
`head`	Yes	Head branch (e.g., 'username:feature' or just 'feature' for same repo)
`base`	Yes	Base branch (e.g., 'main')
`body`	No	Pull request description
`draft`	No	Create as draft PR

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.

create-repositoryD

ParametersJSON Schema

Name	Required	Description
`name`	Yes	Repository name
`description`	No	Repository description
`private`	No	Whether the repository is private
`auto_init`	No	Initialize with README
`gitignore_template`	No	Add .gitignore template
`license_template`	No	Add a license template
`org`	No	Organization name (if creating in an organization)

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.

create-userD

ParametersJSON Schema

Name	Required	Description
`bio`	No	Biography for the user
`blog`	No	URL of the user's blog or website
`name`	No	Full name for the user
`email`	Yes	The email address for the user
`login`	Yes	The username for the user
`company`	No	Company for the user
`location`	No	Location for the user
`twitter_username`	No	Twitter username for the user

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.

delete-repositoryD

ParametersJSON Schema

Name	Required	Description
`owner`	Yes	Repository owner
`repo`	Yes	Repository name
`confirm`	Yes	Confirmation for deletion (must be true)

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.

delete-userD

ParametersJSON Schema

Name	Required	Description	Default
`username`	Yes	Username of the user to delete

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.

get-contentD

ParametersJSON Schema

Name	Required	Description
`owner`	Yes	User or organization name
`repo`	Yes	Repository name
`path`	Yes	File or directory path
`ref`	No	Branch or commit hash (default: default branch)

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.

get-enterprise-statsD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

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.

get-issueD

ParametersJSON Schema

Name	Required	Description
`owner`	Yes	Repository owner (user or organization)
`repo`	Yes	Repository name
`issue_number`	Yes	Issue number

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.

get-license-infoD

ParametersJSON Schema

Name	Required	Description	Default
No parameters

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.

get-pull-requestD

ParametersJSON Schema

Name	Required	Description
`owner`	Yes	Repository owner (user or organization)
`repo`	Yes	Repository name
`pull_number`	Yes	Pull request number

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.

get-repositoryD

ParametersJSON Schema

Name	Required	Description	Default
`owner`	Yes	User or organization name
`repo`	Yes	Repository name

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.

get-userD

ParametersJSON Schema

Name	Required	Description	Default
`username`	Yes	Username of the user to retrieve

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.

list-branchesD

ParametersJSON Schema

Name	Required	Description
`owner`	Yes	User or organization name
`repo`	Yes	Repository name
`protected_only`	No	Whether to show only protected branches
`page`	No	Page number
`perPage`	No	Items per page

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.

list-issue-commentsD

ParametersJSON Schema

Name	Required	Description
`page`	No	Page number
`repo`	Yes	Repository name
`owner`	Yes	Repository owner (user or organization)
`per_page`	No	Items per page
`issue_number`	Yes	Issue number

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.

list-issuesD

ParametersJSON Schema

Name	Required	Description	Default
`owner`	Yes	Repository owner (user or organization)
`repo`	Yes	Repository name
`state`	No	Issue state filter	open
`sort`	No	Sort criteria	created
`direction`	No	Sort direction	desc
`page`	No	Page number
`per_page`	No	Items per page

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.

list-pull-requestsD

ParametersJSON Schema

Name	Required	Description	Default
`owner`	Yes	Repository owner (user or organization)
`repo`	Yes	Repository name
`state`	No	PR state filter	open
`sort`	No	Sort criteria	created
`direction`	No	Sort direction	desc
`page`	No	Page number
`per_page`	No	Items per page

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.

list-repositoriesD

ParametersJSON Schema

Name	Required	Description	Default
`owner`	Yes	User or organization name
`isOrg`	No	Whether it's an organization (true: organization, false: user)
`type`	No	Repository type filter	all
`sort`	No	Sort criteria	full_name
`page`	No	Page number
`perPage`	No	Items per page

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.

list-user-orgsD

ParametersJSON Schema

Name	Required	Description
`page`	No	Page number for pagination
`per_page`	No	Number of results per page (max 100)
`username`	Yes	Username of the user whose organizations to list

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.

list-usersD

ParametersJSON Schema

Name	Required	Description
`page`	No	Page number for pagination
`filter`	No	Filter users by status
`search`	No	Search query to filter users by username or email
`per_page`	No	Number of results per page (max 100)

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.

list-workflow-runsD

ParametersJSON Schema

Name	Required	Description
`owner`	Yes	Repository owner
`repo`	Yes	Repository name
`workflow_id`	No	Workflow ID or file name
`branch`	No	Filter by branch name
`status`	No	Filter by run status
`page`	No	Page number
`perPage`	No	Items per page

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.

list-workflowsD

ParametersJSON Schema

Name	Required	Description
`owner`	Yes	Repository owner
`repo`	Yes	Repository name
`page`	No	Page number
`perPage`	No	Items per page

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.

merge-pull-requestD

ParametersJSON Schema

Name	Required	Description	Default
`owner`	Yes	Repository owner (user or organization)
`repo`	Yes	Repository name
`pull_number`	Yes	Pull request number
`commit_title`	No	Title for the automatic commit message
`commit_message`	No	Extra detail to append to automatic commit message
`merge_method`	No	Merge method to use	merge

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.

suspend-userD

ParametersJSON Schema

Name	Required	Description	Default
`reason`	No	Reason for the suspension
`username`	Yes	Username of the user to suspend

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.

trigger-workflowD

ParametersJSON Schema

Name	Required	Description
`owner`	Yes	Repository owner
`repo`	Yes	Repository name
`workflow_id`	Yes	Workflow ID or file name
`ref`	Yes	Git reference (branch, tag, SHA)
`inputs`	No	Workflow inputs

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.

unsuspend-userD

ParametersJSON Schema

Name	Required	Description	Default
`username`	Yes	Username of the user to unsuspend

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.

update-repositoryD

ParametersJSON Schema

Name	Required	Description
`owner`	Yes	Repository owner
`repo`	Yes	Repository name
`description`	No	New description
`private`	No	Change privacy setting
`default_branch`	No	Change default branch
`has_issues`	No	Enable/disable issues
`has_projects`	No	Enable/disable projects
`has_wiki`	No	Enable/disable wiki
`archived`	No	Archive/unarchive repository

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.

update-userD

ParametersJSON Schema

Name	Required	Description
`bio`	No	Biography for the user
`blog`	No	URL of the user's blog or website
`name`	No	Full name for the user
`email`	No	The email address for the user
`company`	No	Company for the user
`location`	No	Location for the user
`username`	Yes	Username of the user to update
`twitter_username`	No	Twitter username for the user

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.

2 tool updatesv1.0.0Jan 2, 2026
- Changedget-enterprise-stats1 field changed
  - removedInput schema / additionalProperties
```
Removed value: -false
```
- Changedget-license-info1 field changed
  - removedInput schema / additionalProperties
```
Removed value: -false
```
28 tool updatesAug 18, 2025
- First observedcreate-issue
- First observedcreate-pull-request
- First observedcreate-repository
- First observedcreate-user
- First observeddelete-repository
- First observeddelete-user
- First observedget-content
- First observedget-enterprise-stats
- First observedget-issue
- First observedget-license-info
- First observedget-pull-request
- First observedget-repository
- First observedget-user
- First observedlist-branches
- First observedlist-issue-comments
- First observedlist-issues
- First observedlist-pull-requests
- First observedlist-repositories
- First observedlist-user-orgs
- First observedlist-users
- First observedlist-workflow-runs
- First observedlist-workflows
- First observedmerge-pull-request
- First observedsuspend-user
- First observedtrigger-workflow
- First observedunsuspend-user
- First observedupdate-repository
- First observedupdate-user

Deploy Server

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

C2/5.0

Scored 2026-09-10 02:38 across 28 tools

Disambiguation5/5

Each tool targets a distinct resource-action combination, such as list-repositories vs get-repository vs create-repository. Even within the same resource, tools like get-issue, create-issue, and list-issues are clearly separated. No two tools appear to do the same thing.

Naming Consistency5/5

All tool names follow a consistent kebab-case verb-noun pattern (e.g., list-issues, create-repository, suspend-user). The verbs are uniform and predictable, making the naming convention highly consistent across the entire set.

Tool Count4/5

With 28 tools, the count is on the heavier side, but it covers a broad enterprise domain including repositories, issues, pull requests, workflows, users, and enterprise stats. Each tool seems justified for the scope, so the count is appropriate, though slightly above the typical well-scoped range.

Completeness3/5

The tool surface covers core CRUD for repositories and users, plus workflows and pull requests, but has notable gaps: no update-issue or delete-issue, no update/delete for pull requests, and no search capabilities. These missing operations will require agents to work around limitations in common workflows.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Reddit Discussion

Related Servers

Related MCP Connectors

ArletOAuth
dev.arlet
Create, deploy, and operate MCP servers directly from your GitHub repositories.
Developer Tools CI/CD & DevOps
2
gread A
io.github.NitroRCr
An MCP server that gives your AI access to the source code and docs of all public github repos
Version Control Code Analysis Documentation Access
5365
neverinfamous-memory-journal-mcp
ai.smithery
A MCP server built for developers enabling Git based project management with project and personal…
Version Control Developer Tools Project Management
320
mcp-openaiOAuth
io.github.AceDataCloud
MCP server for OpenAI API (chat completions, image generation, embeddings) via AceDataCloud
AI & Machine Learning Image & Video Processing
11

Related MCP Servers

GitHub MCP Serverofficial
Version Control Developer Tools File Systems
modelcontextprotocol
-
license
Not graded
quality
A
maintenance
MCP Server for the GitHub API, enabling file operations, repository management, search functionality, and more.
Updated a day ago (2026-10-12 05:33 UTC)
137,300 npm
91,120
MIT
GitHub CLI MCP Server
Version Control Developer Tools CI/CD & DevOps
munch-group
A
license
Not graded
quality
D
maintenance
An MCP server that wraps the GitHub CLI to provide comprehensive access to repository management, pull requests, issues, and workflows. It enables users to perform complex GitHub operations and interact with the GitHub API through a standardized interface.
Updated 10 months ago (2025-12-09 18:17 UTC)
355 npm
1
ISC
mcp-github-server
Version Control Project Management
pblarismendi
A
license
B
quality
D
maintenance
An MCP server that enables managing GitHub repositories, pull requests, issues, and more through natural language in Cursor or Claude Desktop.
Updated 9 months ago (2025-12-29 16:27 UTC)
39
3 npm
4
MIT
@cloud9-labs/mcp-github
Version Control Developer Tools
cloud9-labs
A
license
B
quality
D
maintenance
MCP (Model Context Protocol) server for GitHub API integration. This server provides comprehensive tools for interacting with GitHub repositories, issues, pull requests, branches, and code search through a unified interface.
Updated 8 months ago (2026-02-12 04:44 UTC)
15
8 npm
MIT

GitHub Enterprise MCP 服务器

兼容性

主要特点

入门

先决条件

Docker 安装和设置

选项 1：使用 Docker 运行

选项 2：使用 Docker Compose

安装和设置

本地开发（使用并发模式）

生产的安装和设置

选项 1：使用 URL 模式（推荐用于本地开发）

选项 2：作为全局命令安装（npm 链接）

选项 3：使用 npx（包发布时）

与AI工具集成

克劳德桌面

光标

推荐：URL模式（最稳定）

替代方案：命令模式

语言配置

环境变量

命令行参数

HTTP 模式中的附加选项

可用的 MCP 工具

使用 Cursor 中的工具

列出存储库

获取存储库信息

列出拉取请求

管理问题

使用存储库内容

存储库管理

用户管理（仅限企业）

API 改进

贡献

执照

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

GitHub MCP Serverofficial

Appeared in Searches