What can you do with this server?

This server provides an MCP interface to interact with GitHub Enterprise API (also compatible with GitHub.com and GitHub Enterprise Cloud with some limitations) for AI tools like Cursor. Capabilities include: * Repository Management: Retrieve repository lists and details, list branches, get file/directory contents, create/update/delete repositories * Pull Requests & Issues: List, create, get details, merge PRs, manage issues, and retrieve/add comments * GitHub Actions: List workflows and workflow runs, trigger workflows * User Management: List, create, update, suspend/unsuspend users (Enterprise only) * Enterprise Features: Access license information and system statistics (requires site admin permissions)

Which integrations are available for this server?

Provides access to GitHub Enterprise and GitHub.com repositories, enabling repository management, branch listing, file content retrieval, and issue/PR handling through the GitHub API. Offers tools for listing, viewing, and triggering GitHub Actions workflows, with capabilities for managing workflow runs and filtering by branch or status.

How do I use GitHub Enterprise MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@GitHub Enterprise MCP Server list open pull requests in the backend repository" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

de en es ja ko ru zh

GitHub Enterprise MCP Server

by ddukbg

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Trust Score

GitHub Enterprise MCP Server

An MCP (Model Context Protocol) server for integration with GitHub Enterprise API. This server provides an MCP interface to easily access repository information, issues, PRs, and more from GitHub Enterprise in Cursor.

Compatibility

This project is primarily designed for GitHub Enterprise Server environments, but it also works with:

GitHub.com
GitHub Enterprise Cloud

Note: Some enterprise-specific features (like license information and enterprise statistics) will not work with GitHub.com or GitHub Enterprise Cloud.

Related MCP server: GitHub CLI MCP Server

Key Features

Retrieve repository list from GitHub Enterprise instances
Get detailed repository information
List repository branches
View file and directory contents
Manage issues and pull requests
Repository management (create, update, delete)
GitHub Actions workflows management
User management (list, create, update, delete, suspend/unsuspend users)
Access enterprise statistics
Enhanced error handling and user-friendly response formatting

Getting Started

Prerequisites

Node.js 18 or higher
Access to a GitHub Enterprise instance
Personal Access Token (PAT)

Docker Installation and Setup

Option 1: Running with Docker

Build the Docker image:
```
docker build -t github-enterprise-mcp .
```

Run the Docker container with environment variables:

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

Note: The Dockerfile is configured to run with --transport http by default. If you need to change this, you can override the command:

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: Using Docker Compose

Create a .env file in the project root with the required environment variables:

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

Start the container with Docker Compose:
```
docker-compose up -d
```
Check the logs:
```
docker-compose logs -f
```
Stop the container:
```
docker-compose down
```

Installation and Setup

Local Development (Using Concurrent Mode)

This method is recommended for active development with automatic recompilation and server restarts:

Clone the repository and install required packages:

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

Run the development server:
```
export GITHUB_TOKEN="your_github_token"
export GITHUB_ENTERPRISE_URL="https://github.your-company.com/api/v3"
npm run dev
```
This will:
- Compile TypeScript code automatically when files change
- Restart the server when compiled files are updated
- Run the server in HTTP mode for URL-based connections
Connect to Cursor using URL mode as described below

Installation and Setup for Production

Option 1: Using URL Mode (Recommended for Local Development)

This method is the most stable and recommended for local development or testing:

Clone the repository and install required packages:

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

Build the project:
```
npm run build
chmod +x dist/index.js
```

Run the server:

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

Connect to Cursor using URL mode:

Add the following to your Cursor's .cursor/mcp.json file:

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

Option 2: Install as a Global Command (npm link)

This method is useful for local development:

# 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: Using npx (When Package is Published)

If the package is published to the public npm registry:

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

Integration with AI Tools

Claude Desktop

Add the following to your 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"]
    }
  }
}

Replace YOUR_GITHUB_TOKEN and YOUR_GITHUB_ENTERPRISE_URL with your actual values.

Cursor

Recommended: URL Mode (Most Stable)

For the most reliable operation in Cursor, using URL mode is recommended:

Start the server in a separate terminal window:

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

Configure Cursor's MCP settings:
- Open Cursor and go to Settings
- Navigate to AI > MCP Servers
- Edit your .cursor/mcp.json file:
```
{
  "mcpServers": {
    "github-enterprise": {
      "url": "http://localhost:3000/sse"
    }
  }
}
```
Restart Cursor to apply the changes

Alternative: Command Mode

Alternatively, you can configure Cursor to use the command mode, although URL mode is more reliable:

Open Cursor and go to Settings
Navigate to AI > MCP Servers
Click Add MCP Server
Enter the following details:
- Name: GitHub Enterprise
- Command: npx
- Arguments: @ddukbg/github-enterprise-mcp
- Environment Variables:
  - GITHUB_ENTERPRISE_URL: Your GitHub Enterprise API URL
  - GITHUB_TOKEN: Your GitHub personal access token

Alternatively, you can manually edit your .cursor/mcp.json file to include:

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

Language Configuration

This MCP server supports both English and Korean languages. You can configure the language using:

Environment Variables

# Set language to Korean
export LANGUAGE=ko

# Or in .env file
LANGUAGE=ko

Command-line Arguments

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

The default language is English if not specified.

Additional Options in HTTP Mode

--debug: Enable debug logging
--github-enterprise-url <URL>: Set GitHub Enterprise API URL
--token <TOKEN>: Set GitHub Personal Access Token
--language <LANG>: Set language (en or ko, default: en)

Available MCP Tools

This MCP server provides the following tools:

Tool Name	Description	Parameters	Required PAT Permissions
`list-repositories`	Retrieve repository list for a user or organization	`owner`: Username/org name`isOrg`: Whether it's an organization`type`: Repository type`sort`: Sort criteria`page`: Page number`perPage`: Items per page	`repo`
`get-repository`	Get detailed repository information	`owner`: Repository owner`repo`: Repository name	`repo`
`list-branches`	List branches of a repository	`owner`: Repository owner`repo`: Repository name`protected_only`: Whether to show only protected branches`page`: Page number`perPage`: Items per page	`repo`
`get-content`	Retrieve file or directory contents	`owner`: Repository owner`repo`: Repository name`path`: File/directory path`ref`: Branch/commit (optional)	`repo`
`list-pull-requests`	List pull requests in a repository	`owner`: Repository owner`repo`: Repository name`state`: PR state filter`sort`: Sort criteria`direction`: Sort direction`page`: Page number`per_page`: Items per page	`repo`
`get-pull-request`	Get pull request details	`owner`: Repository owner`repo`: Repository name`pull_number`: Pull request number	`repo`
`create-pull-request`	Create a new pull request	`owner`: Repository owner`repo`: Repository name`title`: PR title`head`: Head branch`base`: Base branch`body`: PR description`draft`: Create as draft PR	`repo`
`merge-pull-request`	Merge a pull request	`owner`: Repository owner`repo`: Repository name`pull_number`: Pull request number`merge_method`: Merge method`commit_title`: Commit title`commit_message`: Commit message	`repo`
`list-issues`	List issues in a repository	`owner`: Repository owner`repo`: Repository name`state`: Issue state filter`sort`: Sort criteria`direction`: Sort direction`page`: Page number`per_page`: Items per page	`repo`
`get-issue`	Get issue details	`owner`: Repository owner`repo`: Repository name`issue_number`: Issue number	`repo`
`list-issue-comments`	List comments on an issue or pull request	`owner`: Repository owner`repo`: Repository name`issue_number`: Issue/PR number`page`: Page number`per_page`: Items per page	`repo`
`create-issue`	Create a new issue	`owner`: Repository owner`repo`: Repository name`title`: Issue title`body`: Issue body content`labels`: Array of label names`assignees`: Array of user logins`milestone`: Milestone ID	`repo`
`create-repository`	Create a new repository	`name`: Repository name`description`: Repository description`private`: Whether private`auto_init`: Initialize with README`gitignore_template`: Add .gitignore`license_template`: Add license`org`: Organization name	`repo`
`update-repository`	Update repository settings	`owner`: Repository owner`repo`: Repository name`description`: New description`private`: Change privacy`default_branch`: Change default branch`has_issues`: Enable/disable issues`has_projects`: Enable/disable projects`has_wiki`: Enable/disable wiki`archived`: Archive/unarchive	`repo`
`delete-repository`	Delete a repository	`owner`: Repository owner`repo`: Repository name`confirm`: Confirmation (must be true)	`delete_repo`
`list-workflows`	List GitHub Actions workflows	`owner`: Repository owner`repo`: Repository name`page`: Page number`perPage`: Items per page	`actions:read`
`list-workflow-runs`	List workflow runs	`owner`: Repository owner`repo`: Repository name`workflow_id`: Workflow ID/filename`branch`: Filter by branch`status`: Filter by status`page`: Page number`perPage`: Items per page	`actions:read`
`trigger-workflow`	Trigger a workflow	`owner`: Repository owner`repo`: Repository name`workflow_id`: Workflow ID/filename`ref`: Git reference`inputs`: Workflow inputs	`actions:write`
`get-license-info`	Get GitHub Enterprise license information	-	Requires site_admin (Administrator) account
`get-enterprise-stats`	Get GitHub Enterprise system statistics	-	Requires site_admin (Administrator) account

Note: For Enterprise-specific tools (get-license-info and get-enterprise-stats), a user with site administrator privileges is required. A Classic Personal Access Token is recommended, as Fine-grained tokens may not support these Enterprise-level permissions.

Using the Tools in Cursor

Once you have set up the MCP server and configured Cursor to connect to it, you can use the GitHub Enterprise tools directly in Cursor's AI chat. Here are some examples:

Listing Repositories

mcp_github_enterprise_list_repositories(owner="octocat")

Getting Repository Information

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

Listing Pull Requests

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

Managing Issues

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

Working with Repository Content

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

Repository Management

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

User Management (Enterprise Only)

These features are specifically designed for GitHub Enterprise Server environments and require administrative permissions:

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

Flexible API URL configuration (supports various environment variables and command-line arguments)
Enhanced error handling and timeout management
User-friendly response formatting and messages

Contributing

Contributions are welcome! Please feel free to submit a Pull Request.

License

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

Compatibility

Key Features

Getting Started

Prerequisites

Docker Installation and Setup

Option 1: Running with Docker

Option 2: Using Docker Compose

Installation and Setup

Local Development (Using Concurrent Mode)

Installation and Setup for Production

Option 1: Using URL Mode (Recommended for Local Development)

Option 2: Install as a Global Command (npm link)

Option 3: Using npx (When Package is Published)

Integration with AI Tools

Claude Desktop

Cursor

Recommended: URL Mode (Most Stable)

Alternative: Command Mode

Language Configuration

Environment Variables

Command-line Arguments

Additional Options in HTTP Mode

Available MCP Tools

Using the Tools in Cursor

Listing Repositories

Getting Repository Information

Listing Pull Requests

Managing Issues

Working with Repository Content

Repository Management

User Management (Enterprise Only)

API Improvements

Contributing

License

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