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 Server

Bild

Ein MCP-Server (Model Context Protocol) zur Integration mit der GitHub Enterprise API. Dieser Server bietet eine MCP-Schnittstelle für den einfachen Zugriff auf Repository-Informationen, Probleme, PRs und mehr von GitHub Enterprise in Cursor.

Kompatibilität

Dieses Projekt ist in erster Linie für GitHub Enterprise Server-Umgebungen konzipiert, funktioniert aber auch mit:

GitHub.com
GitHub Enterprise Cloud

Hinweis : Einige unternehmensspezifische Funktionen (wie Lizenzinformationen und Unternehmensstatistiken) funktionieren nicht mit GitHub.com oder GitHub Enterprise Cloud.

Related MCP server: GitHub CLI MCP Server

Hauptmerkmale

Abrufen der Repository-Liste von GitHub Enterprise-Instanzen
Erhalten Sie detaillierte Repository-Informationen
Repository-Zweige auflisten
Datei- und Verzeichnisinhalte anzeigen
Probleme und Pull Requests verwalten
Repository-Verwaltung (Erstellen, Aktualisieren, Löschen)
Verwaltung von GitHub Actions-Workflows
Benutzerverwaltung (Benutzer auflisten, erstellen, aktualisieren, löschen, sperren/entsperren)
Zugriff auf Unternehmensstatistiken
Verbesserte Fehlerbehandlung und benutzerfreundliche Antwortformatierung

Erste Schritte

Voraussetzungen

Node.js 18 oder höher
Zugriff auf eine GitHub Enterprise-Instanz
Persönlicher Zugriffstoken (PAT)

Docker-Installation und -Einrichtung

Option 1: Ausführen mit Docker

Erstellen Sie das Docker-Image:
```
docker build -t github-enterprise-mcp .
```

Führen Sie den Docker-Container mit Umgebungsvariablen aus:

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

Hinweis : Das Dockerfile ist standardmäßig für die Ausführung mit --transport http konfiguriert. Falls Sie dies ändern möchten, können Sie den folgenden Befehl überschreiben:

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

Option 2: Verwenden von Docker Compose

Erstellen Sie im Projektstammverzeichnis eine .env Datei mit den erforderlichen Umgebungsvariablen:

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

Starten Sie den Container mit Docker Compose:
```
docker-compose up -d
```
Überprüfen Sie die Protokolle:
```
docker-compose logs -f
```
Stoppen Sie den Container:
```
docker-compose down
```

Installation und Einrichtung

Lokale Entwicklung (unter Verwendung des Parallelmodus)

Diese Methode wird für die aktive Entwicklung mit automatischer Neukompilierung und Serverneustarts empfohlen:

Klonen Sie das Repository und installieren Sie die erforderlichen Pakete:

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

Führen Sie den Entwicklungsserver aus:
```
export GITHUB_TOKEN="your_github_token"
export GITHUB_ENTERPRISE_URL="https://github.your-company.com/api/v3"
npm run dev
```
Dies wird:
- TypeScript-Code automatisch kompilieren, wenn sich Dateien ändern
- Starten Sie den Server neu, wenn kompilierte Dateien aktualisiert werden
- Führen Sie den Server im HTTP-Modus für URL-basierte Verbindungen aus
Stellen Sie im URL-Modus eine Verbindung zum Cursor her, wie unten beschrieben

Installation und Einrichtung für die Produktion

Option 1: Verwenden des URL-Modus (empfohlen für die lokale Entwicklung)

Diese Methode ist die stabilste und wird für die lokale Entwicklung oder Tests empfohlen:

Klonen Sie das Repository und installieren Sie die erforderlichen Pakete:

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

Erstellen Sie das Projekt:
```
npm run build
chmod +x dist/index.js
```

Führen Sie den Server aus:

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

Stellen Sie im URL-Modus eine Verbindung zum Cursor her:
- Fügen Sie der Datei .cursor/mcp.json Ihres Cursors Folgendes hinzu:
```
{
  "mcpServers": {
    "github-enterprise": {
      "url": "http://localhost:3000/sse"
    }
  }
}
```

Option 2: Als globalen Befehl installieren (npm-Link)

Diese Methode ist für die lokale Entwicklung nützlich:

# 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

Option 3: Verwenden von npx (wenn das Paket veröffentlicht ist)

Wenn das Paket im öffentlichen npm-Register veröffentlicht wird:

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

Integration mit KI-Tools

Claude Desktop

Fügen Sie Ihrer claude_desktop_config.json Folgendes hinzu:

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

Ersetzen Sie YOUR_GITHUB_TOKEN und YOUR_GITHUB_ENTERPRISE_URL durch Ihre tatsächlichen Werte.

Cursor

Empfohlen: URL-Modus (am stabilsten)

Für den zuverlässigsten Betrieb im Cursor wird die Verwendung des URL-Modus empfohlen:

Starten Sie den Server in einem separaten Terminalfenster:

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

Konfigurieren Sie die MCP-Einstellungen des Cursors:
- Öffnen Sie Cursor und gehen Sie zu Einstellungen
- Navigieren Sie zu AI > MCP-Server
- Bearbeiten Sie Ihre .cursor/mcp.json -Datei:
```
{
  "mcpServers": {
    "github-enterprise": {
      "url": "http://localhost:3000/sse"
    }
  }
}
```
Starten Sie den Cursor neu, um die Änderungen zu übernehmen

Alternative: Befehlsmodus

Alternativ können Sie Cursor für die Verwendung des Befehlsmodus konfigurieren, obwohl der URL-Modus zuverlässiger ist:

Öffnen Sie Cursor und gehen Sie zu Einstellungen
Navigieren Sie zu AI > MCP-Server
Klicken Sie auf MCP-Server hinzufügen
Geben Sie die folgenden Details ein:
- Name : GitHub Enterprise
- Befehl : npx
- Argumente : @ddukbg/github-enterprise-mcp
- Umgebungsvariablen :
  - GITHUB_ENTERPRISE_URL : Ihre GitHub Enterprise API-URL
  - GITHUB_TOKEN : Ihr persönlicher GitHub-Zugriffstoken

Alternativ können Sie Ihre .cursor/mcp.json Datei manuell bearbeiten, um Folgendes einzuschließen:

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

Sprachkonfiguration

Dieser MCP-Server unterstützt sowohl Englisch als auch Koreanisch. Sie können die Sprache wie folgt konfigurieren:

Umgebungsvariablen

# Set language to Korean
export LANGUAGE=ko

# Or in .env file
LANGUAGE=ko

Befehlszeilenargumente

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

Die Standardsprache ist Englisch, wenn nicht anders angegeben.

Zusätzliche Optionen im HTTP-Modus

--debug : Debug-Protokollierung aktivieren
--github-enterprise-url <URL> : URL der GitHub Enterprise API festlegen
--token <TOKEN> : Persönliches GitHub-Zugriffstoken festlegen
--language <LANG> : Sprache festlegen (en oder ko, Standard: en)

Verfügbare MCP-Tools

Dieser MCP-Server bietet die folgenden Tools:

Werkzeugname	Beschreibung	Parameter	Erforderliche PAT-Berechtigungen
`list-repositories`	Abrufen der Repository-Liste für einen Benutzer oder eine Organisation	`owner` : Benutzername/Organisationsname. `isOrg` : Ob es sich um eine Organisation handelt. `type` : Repository-Typ. `sort` : Sortierkriterien. `page` : Seitenzahl. `perPage` : Elemente pro Seite.	`repo`
`get-repository`	Erhalten Sie detaillierte Repository-Informationen	`owner` : Repository-Besitzer `repo` : Repository-Name	`repo`
`list-branches`	Auflisten von Zweigen eines Repositorys	`owner` : Repository-Eigentümer `repo` : Repository-Name `protected_only` : Ob nur geschützte Zweige angezeigt werden sollen `page` : Seitenzahl `perPage` : Elemente pro Seite	`repo`
`get-content`	Abrufen von Datei- oder Verzeichnisinhalten	`owner` : Repository-Besitzer `repo` : Repository-Name `path` : Datei-/Verzeichnispfad `ref` : Branch/Commit (optional)	`repo`
`list-pull-requests`	Auflisten von Pull Requests in einem Repository	`owner` : Repository-Besitzer `repo` : Repository-Name `state` : PR-Status Filter `sort` : Sortierkriterien `direction` : Sortierrichtung `page` : `per_page` pro Seite: Elemente pro Seite	`repo`
`get-pull-request`	Abrufen von Pull-Request-Details	`owner` : Repository-Besitzer `repo` : Repository-Name `pull_number` : Pull-Request-Nummer	`repo`
`create-pull-request`	Erstellen einer neuen Pull-Anfrage	`owner` : Repository-Besitzer `repo` : Repository-Name `title` : PR-Titel `head` : Kopfzweig `base` : Basiszweig `body` : PR-Beschreibung `draft` : Als PR-Entwurf erstellen	`repo`
`merge-pull-request`	Zusammenführen einer Pull-Anfrage	`owner` : Repository-Eigentümer `repo` : Repository-Name `pull_number` : Pull-Request-Nummer `merge_method` : Merge-Methode `commit_title` : Commit-Titel `commit_message` : Commit-Nachricht	`repo`
`list-issues`	Auflisten von Problemen in einem Repository	`owner` : Repository-Besitzer `repo` : Repository-Name `state` : Problemstatus Filter `sort` : Sortierkriterien `direction` : Sortierrichtung `page` : `per_page` pro Seite: Elemente pro Seite	`repo`
`get-issue`	Abrufen von Problemdetails	`owner` : Repository-Besitzer `repo` : Repository-Name `issue_number` : Problemnummer	`repo`
`list-issue-comments`	Auflisten von Kommentaren zu einem Problem oder Pull Request	`owner` : Repository-Eigentümer `repo` : Repository-Name `issue_number` : Ausgabe-/PR-Nummer `page` : Seitenzahl `per_page` : Elemente pro Seite	`repo`
`create-issue`	Neues Problem erstellen	`owner` : Repository-Besitzer `repo` : Repository-Name `title` : Problemtitel `body` : Inhalt des Problemtexts `labels` : Array von Beschriftungsnamen `assignees` : Array von Benutzeranmeldungen `milestone` : Meilenstein-ID	`repo`
`create-repository`	Erstellen eines neuen Repositorys	`name` : Repository-Name `description` : Repository-Beschreibung `private` : Ob privat `auto_init` : Mit README initialisieren `gitignore_template` : .gitignore hinzufügen `license_template` : Lizenz hinzufügen `org` : Name der Organisation	`repo`
`update-repository`	Aktualisieren der Repository-Einstellungen	`owner` : Repository-Eigentümer `repo` : Repository-Name `description` : Neue Beschreibung `private` : Datenschutz ändern `default_branch` : Standardzweig ändern `has_issues` : Probleme aktivieren/deaktivieren `has_projects` : Projekte aktivieren/deaktivieren `has_wiki` : Wiki aktivieren/deaktivieren `archived` : Archivieren/Dearchivieren	`repo`
`delete-repository`	Löschen eines Repositorys	`owner` : Repository-Besitzer `repo` : Repository-Name `confirm` : Bestätigung (muss wahr sein)	`delete_repo`
`list-workflows`	GitHub Actions-Workflows auflisten	`owner` : Repository-Besitzer `repo` : Repository-Name `page` : Seitenzahl `perPage` : Elemente pro Seite	`actions:read`
`list-workflow-runs`	Auflisten von Workflow-Ausführungen	`owner` : Repository-Besitzer `repo` : Repository-Name `workflow_id` -ID: Workflow-ID/Dateiname `branch` : Nach Zweig filtern `status` : Nach Status filtern `page` : Seitenzahl pro `perPage` : Elemente pro Seite	`actions:read`
`trigger-workflow`	Auslösen eines Workflows	`owner` : Repository-Eigentümer `repo` : Repository-Name `workflow_id` : Workflow-ID/Dateiname `ref` : Git-Referenz `inputs` : Workflow-Eingaben	`actions:write`
`get-license-info`	Informationen zur GitHub Enterprise-Lizenz erhalten	-	Erfordert ein Site_Admin-Konto (Administrator)
`get-enterprise-stats`	Holen Sie sich GitHub Enterprise-Systemstatistiken	-	Erfordert ein Site_Admin-Konto (Administrator)

Hinweis : Für unternehmensspezifische Tools ( get-license-info und get-enterprise-stats ) ist ein Benutzer mit Site-Administratorrechten erforderlich. Ein klassischer persönlicher Zugriffstoken wird empfohlen, da feinkörnige Token diese Berechtigungen auf Unternehmensebene möglicherweise nicht unterstützen.

Verwenden der Werkzeuge im Cursor

Sobald Sie den MCP-Server eingerichtet und Cursor für die Verbindung konfiguriert haben, können Sie die GitHub Enterprise-Tools direkt im KI-Chat von Cursor verwenden. Hier sind einige Beispiele:

Auflisten von Repositories

mcp_github_enterprise_list_repositories(owner="octocat")

Abrufen von Repository-Informationen

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

Auflisten von Pull Requests

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

Probleme verwalten

# 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"]
)

Arbeiten mit Repository-Inhalten

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

Repository-Verwaltung

# 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
)

Benutzerverwaltung (nur Enterprise)

Diese Funktionen sind speziell für GitHub Enterprise Server-Umgebungen konzipiert und erfordern Administratorberechtigungen:

# 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-Verbesserungen

Flexible API-URL-Konfiguration (unterstützt verschiedene Umgebungsvariablen und Befehlszeilenargumente)
Verbesserte Fehlerbehandlung und Timeout-Verwaltung
Benutzerfreundliche Antwortformatierung und Nachrichten

Beitragen

Beiträge sind willkommen! Senden Sie gerne einen Pull Request.

Lizenz

ISC

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 Server

Kompatibilität

Hauptmerkmale

Erste Schritte

Voraussetzungen

Docker-Installation und -Einrichtung

Option 1: Ausführen mit Docker

Option 2: Verwenden von Docker Compose

Installation und Einrichtung

Lokale Entwicklung (unter Verwendung des Parallelmodus)

Installation und Einrichtung für die Produktion

Option 1: Verwenden des URL-Modus (empfohlen für die lokale Entwicklung)

Option 2: Als globalen Befehl installieren (npm-Link)

Option 3: Verwenden von npx (wenn das Paket veröffentlicht ist)

Integration mit KI-Tools

Claude Desktop

Cursor

Empfohlen: URL-Modus (am stabilsten)

Alternative: Befehlsmodus

Sprachkonfiguration

Umgebungsvariablen

Befehlszeilenargumente

Zusätzliche Optionen im HTTP-Modus

Verfügbare MCP-Tools

Verwenden der Werkzeuge im Cursor

Auflisten von Repositories

Abrufen von Repository-Informationen

Auflisten von Pull Requests

Probleme verwalten

Arbeiten mit Repository-Inhalten

Repository-Verwaltung

Benutzerverwaltung (nur Enterprise)

API-Verbesserungen

Beitragen

Lizenz

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

GitHub MCP Serverofficial

Appeared in Searches