de en es ja ko ru zh

GitHub Enterprise MCP Server

Name: GitHub Enterprise MCP Server
Author: ddukbg

by ddukbg

Overview Schema Related Servers Score Discussions

TypeScript

Remote

GitHub Enterprise MCP-сервер

Сервер MCP (Model Context Protocol) для интеграции с API GitHub Enterprise. Этот сервер предоставляет интерфейс MCP для легкого доступа к информации репозитория, проблемам, PR и многому другому из GitHub Enterprise в Cursor.

Совместимость

Этот проект в первую очередь предназначен для сред 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, как описано ниже.

Установка и настройка для производства

Вариант 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/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

Интеграция с инструментами ИИ

Клод Десктоп

Добавьте следующее в ваш 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 (наиболее стабильный)

Для наиболее надежной работы в Курсоре рекомендуется использовать режим 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

Настройте параметры MCP курсора:
- Откройте Курсор и перейдите в Настройки.
- Перейдите в раздел AI > MCP-серверы.
- Отредактируйте файл .cursor/mcp.json :
```
{
  "mcpServers": {
    "github-enterprise": {
      "url": "http://localhost:3000/sse"
    }
  }
}
```
Перезапустите курсор, чтобы применить изменения.

Альтернатива: командный режим

В качестве альтернативы вы можете настроить Cursor на использование командного режима, хотя режим URL более надежен:

Откройте Курсор и перейдите в Настройки.
Перейдите в раздел AI > MCP-серверы.
Нажмите Добавить сервер MCP.
Введите следующие данные:
- Имя : GitHub Enterprise
- Команда : npx
- Аргументы : @ddukbg/github-enterprise-mcp
- Переменные среды :
  - GITHUB_ENTERPRISE_URL : URL-адрес вашего API GitHub Enterprise
  - 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> : Установить URL-адрес API GitHub Enterprise
--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` : Фильтр состояния проблемы `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` : Идентификатор вехи	`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` : Включить/отключить вики `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` : Идентификатор рабочего процесса/имя файла `branch` : Фильтр по `status` ветви : Фильтр по статусу `page` : Номер страницы `perPage` : Элементы на странице	`actions:read`
`trigger-workflow`	Запустить рабочий процесс	`owner` : Владелец репозитория `repo` : Имя репозитория `workflow_id` : Идентификатор/имя файла рабочего процесса `ref` : Ссылка Git `inputs` : Входные данные рабочего процесса	`actions:write`
`get-license-info`	Получить информацию о лицензии GitHub Enterprise	-	Требуется учетная запись site_admin (Администратор)
`get-enterprise-stats`	Получить статистику системы GitHub Enterprise	-	Требуется учетная запись site_admin (Администратор)

Примечание : Для Enterprise-специфичных инструментов ( get-license-info и get-enterprise-stats ) требуется пользователь с правами администратора сайта . Рекомендуется Classic Personal Access Token, поскольку Fine-grained Tokens могут не поддерживать эти разрешения Enterprise-level.

Использование инструментов в курсоре

После настройки сервера MCP и настройки Cursor для подключения к нему вы можете использовать инструменты GitHub Enterprise непосредственно в чате ИИ Cursor. Вот несколько примеров:

Список репозиториев

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
)

Управление пользователями (только Enterprise)

Эти функции специально разработаны для сред 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

Гибкая конфигурация URL API (поддерживает различные переменные среды и аргументы командной строки)
Улучшенная обработка ошибок и управление тайм-аутами
Удобное форматирование ответов и сообщений

Внося вклад

Вклады приветствуются! Пожалуйста, не стесняйтесь отправлять запрос на включение.

Лицензия

МСК

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. Dates show when Glama detected each change.

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

Install Server

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

TDQS

C2.1/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose targeting specific GitHub resources and actions. There is no overlap between tools like get-repository vs list-repositories or get-issue vs list-issues, making it easy for an agent to select the correct tool.

Naming Consistency5/5

All 18 tools follow a consistent verb-noun naming pattern with hyphens (e.g., create-pull-request, list-repositories, get-content). The naming convention is uniform throughout the entire set with no deviations or mixed styles.

Tool Count4/5

With 18 tools, this is slightly on the higher side but reasonable for a GitHub Enterprise server covering repositories, issues, pull requests, workflows, and enterprise features. The count feels comprehensive rather than excessive, though it borders on being heavy.

Completeness4/5

The tool set provides strong coverage for core GitHub operations including CRUD for repositories and pull requests, listing and getting issues, and workflow management. Minor gaps exist, such as no update/delete for issues or pull request reviews, but agents can work around these with the available tools.

Maintenance

ActivityInactive

ResponsivenessUnresponsive

Resources

Need Help?

Reddit Discussion

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

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
5361
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
Cortex C
io.cortex.mcp
The Cortex MCP server provides read-only access to real-time engineering context from the Cortex developer portal, allowing AI coding assistants to answer natural language questions about your organization's catalog (microservices, libraries, domains, teams, infrastructure), scorecards (engineering standards and best practices), initiatives (goals and deadlines), and Engineering Intelligence metrics. It includes tools for querying documentation, tracking personal entities, and accessing AI-assisted insights across the entire Cortex ecosystem.
Developer Tools Monitoring Observability
312

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 3 days ago (2026-09-03 01:42 UTC)
117,296
90,042
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 9 months ago (2025-12-09 18:17 UTC)
10
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 8 months ago (2025-12-29 16:27 UTC)
39
13
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 7 months ago (2026-02-12 04:44 UTC)
15
14
MIT

Appeared in Searches

Latest Blog Posts

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

MCP directory API

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

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

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

GitHub Enterprise MCP-сервер

Совместимость

Основные характеристики

Начиная

Предпосылки

Установка и настройка Docker

Вариант 1: запуск с Docker

Вариант 2: Использование Docker Compose

Установка и настройка

Локальная разработка (с использованием параллельного режима)

Установка и настройка для производства

Вариант 1: использование режима URL (рекомендуется для локальной разработки)

Вариант 2: Установка как глобальной команды (ссылка npm)

Вариант 3: Использование npx (когда пакет опубликован)

Интеграция с инструментами ИИ

Клод Десктоп

Курсор

Рекомендуется: режим URL (наиболее стабильный)

Альтернатива: командный режим

Конфигурация языка

Переменные среды

Аргументы командной строки

Дополнительные параметры в режиме HTTP

Доступные инструменты MCP

Использование инструментов в курсоре

Список репозиториев

Получение информации о репозитории

Листинг запросов на вытягивание

Управление проблемами

Работа с содержимым репозитория

Управление репозиторием

Управление пользователями (только Enterprise)

Улучшения API

Внося вклад

Лицензия

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

GitHub MCP Serverofficial

Appeared in Searches

Latest Blog Posts

MCP directory API