Provides tools for managing cPanel hosting accounts, including file management, databases, email accounts, subdomains, disk usage, backups, and SSL certificates.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@cPanel MCP Server Create a new database called my_app_db"
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.
A complete Model Context Protocol (MCP) server for managing cPanel hosting through AI assistants like Claude Code
This is a production-ready MCP server that enables natural language management of cPanel hosting accounts through AI assistants. Built from scratch with TypeScript, it provides 16 tools for comprehensive hosting management.
Why This Exists: The original cPanel MCP repository contained only documentation with no source code. This is a complete, working implementation that you can use today.
Related MCP server: cPanel MCP Server
List Files - Browse directories and view contents
Read Files - View file contents
Write Files - Create or update files
Delete Files - Remove files and directories
List Databases - View all MySQL databases
Create Database - Create new databases
Delete Database - Remove databases
List Email Accounts - View all email accounts
Create Email - Add new email accounts with quotas
Delete Email - Remove email accounts
List Subdomains - View all subdomains
Create Subdomain - Add new subdomains
Delete Subdomain - Remove subdomains
Disk Usage - Check storage statistics and quotas
Full Backup - Initiate account backups
Install SSL - Set up SSL certificates
Node.js 18 or higher
cPanel account with API token access
AI assistant that supports MCP (like Claude Code)
Clone the Repository
git clone https://github.com/aandersen2323/cpanel-mcp-server.git
cd cpanel-mcp-serverInstall Dependencies
npm installBuild the Server
npm run buildConfigure Credentials
cp .env.example .env
# Edit .env with your cPanel credentialsAdd to Your MCP Configuration
For Claude Code (VS Code), add to .vscode/settings.json:
{
"mcp.servers": {
"cpanel": {
"command": "node",
"args": ["/absolute/path/to/cpanel-mcp-server/build/index.js"],
"env": {
"CPANEL_USERNAME": "your_username@your_domain.com",
"CPANEL_API_TOKEN": "your_api_token",
"CPANEL_SERVER_URL": "https://your-domain.com:2083"
}
}
}
}Restart Your AI Assistant The MCP server will auto-start and be ready to use!
Once configured, you can use natural language to manage your hosting:
File Operations:
"List files in public_html directory"
"Read the contents of wp-config.php"
"Create a new file called test.html with Hello World"
"Delete the old-backup.tar.gz file"Database Operations:
"Show me all databases"
"Create a new database called my_app_db"
"Delete the test_database database"Email Management:
"List all email accounts"
"Create email account support@example.com with password SecurePass123"
"Delete email account old@example.com"Subdomain Management:
"List all subdomains"
"Create subdomain 'blog' under example.com"
"Delete subdomain test.example.com"System Information:
"Check disk usage"
"How much storage am I using?"
"Start a full account backup"You can also call tools directly:
// List files
mcp__cpanel__list_files({ dir: "/public_html" })
// Read file
mcp__cpanel__read_file({ file: "/public_html/index.php" })
// Create database
mcp__cpanel__create_database({ name: "myapp" })
// Check disk usage
mcp__cpanel__disk_usage()Tool | Description | Parameters |
| List directory contents |
|
| Read file contents |
|
| Write/create file |
|
| Delete file/directory |
|
| Get disk usage stats | None |
| List all databases | None |
| Create database |
|
| Delete database |
|
| List email accounts |
|
| Create email account |
|
| Delete email account |
|
| List subdomains | None |
| Create subdomain |
|
| Delete subdomain |
|
| Full account backup | None |
| Install SSL cert |
|
Log into your cPanel account
Go to Security → Manage API Tokens
Click Create to generate a new token
Copy the token and save it securely
Add it to your .env file
✅ Never commit .env file - Contains sensitive credentials
✅ Use API tokens, not passwords - More secure and can be revoked
✅ Rotate tokens regularly - Update every 90 days
✅ Use least privilege - Only grant necessary permissions
✅ Monitor access logs - Check cPanel logs regularly
Environment-based credential storage
HTTPS/SSL encrypted API communication
Basic authentication with API tokens
No credentials in source code or logs
Comprehensive .gitignore for sensitive files
cpanel-mcp-server/
├── src/
│ └── index.ts # MCP server implementation
├── build/
│ ├── index.js # Compiled JavaScript
│ └── *.map # Source maps
├── .env.example # Credential template
├── .gitignore # Security rules
├── package.json # Dependencies
├── tsconfig.json # TypeScript config
├── LICENSE # MIT License
└── README.md # This fileTypeScript - Type-safe development
@modelcontextprotocol/sdk - MCP protocol implementation
node-fetch - HTTP client for cPanel API
cPanel UAPI - Modern cPanel API interface
https://your-domain.com:2083/execute/{Module}/{Function}Authorization: Basic base64(username:api_token)Fileman - File operations
Quota - Disk usage
Mysql - Database management
Email - Email accounts
SubDomain - Subdomain management
Backup - Backup operations
SSL - Certificate management
# Check Node.js version
node --version # Should be 18+
# Build the server
npm run build
# Verify build output
ls build/index.js # Should existAfter configuring in your AI assistant:
"Check my disk usage"
"List all subdomains"
"Show me all databases"Problem: MCP server fails to start
Solutions:
Verify Node.js is installed: node --version
Check build output exists: ls build/index.js
Rebuild: npm run build
Check logs for error messages
Problem: "401 Unauthorized" or "403 Forbidden"
Solutions:
Verify API token is correct in .env
Check username format: user@domain.com
Confirm cPanel URL includes port :2083
Test credentials directly in cPanel
Generate new API token if expired
Problem: File operations fail
Solutions:
Use absolute paths starting with /
Check file permissions in cPanel
Verify directory exists
Test with cPanel File Manager first
# Install dependencies
npm install
# Build TypeScript
npm run build
# Development mode (rebuild on changes)
npm run dev
# Start server directly
npm startsrc/index.ts - Main server implementation
build/ - Compiled JavaScript output
.env - Your credentials (not committed)
.env.example - Template for credentials
Contributions are welcome! Here's how you can help:
Fork the repository
Create a feature branch (git checkout -b feature/amazing-feature)
Commit your changes (git commit -m 'Add amazing feature')
Push to the branch (git push origin feature/amazing-feature)
Open a Pull Request
git clone https://github.com/aandersen2323/cpanel-mcp-server.git
cd cpanel-mcp-server
npm install
npm run buildInitial Release
✅ Complete MCP server implementation
✅ 16 cPanel management tools
✅ TypeScript with full type safety
✅ File operations (list, read, write, delete)
✅ Database management (list, create, delete)
✅ Email management (list, create, delete)
✅ Subdomain management (list, create, delete)
✅ System monitoring (disk usage)
✅ Backup and SSL support
✅ Comprehensive documentation
✅ Security best practices
✅ Error handling
cPanel API Documentation: https://api.docs.cpanel.net/
MCP Protocol: https://modelcontextprotocol.io/
Issues: https://github.com/aandersen2323/cpanel-mcp-server/issues
"Module not found" - Run npm install and npm run build
"Authentication failed" - Verify credentials in .env
"Cannot connect" - Check cPanel URL and port (usually 2083)
"Permission denied" - Verify API token has required permissions
This project is licensed under the MIT License - see the LICENSE file for details.
Built for use with Claude Code
Implements the Model Context Protocol
Uses cPanel UAPI
If this MCP server helps you manage your cPanel hosting more easily, please give it a star! ⭐
Built with ❤️ by Claude Code
Status: Production Ready ✅ Version: 1.0.0 Last Updated: October 9, 2025
Initiate a full account backup
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description does not disclose behavioral traits such as destructive potential, duration, storage implications, or whether it overwrites previous backups.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no waste. However, it is underspecified for a potentially impactful operation; could be more informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks important context: what does 'full account backup' include? Return value or storage location not described. No output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so schema coverage is 100%. Baseline 4 applies as description adds no param info, but none needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action (Initiate) and resource (full account backup). Distinct from sibling tools which are about creating, deleting, listing, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. No mention of prerequisites or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new MySQL database
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Database name (will be prefixed with account name) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Create' implies mutation, but no details are given about potential side effects (e.g., name conflicts, permission requirements, or error behavior). The description lacks necessary behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundancy. It is front-loaded and efficient, though additional context could be added without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single required parameter, no output schema, and no annotations, the description is minimally viable. It states the action and implies the parameter's purpose, but lacks completeness regarding success/failure responses or operational constraints. Adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the parameter description in the schema already explains the 'name' field effectively. The tool description adds no additional meaning beyond confirming the operation, so it meets the baseline for adequacy but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new MySQL database', which is a specific verb and resource. It distinguishes from sibling tools like cpanel_list_databases and cpanel_delete_database, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., cpanel_list_databases for checking existing databases, or cpanel_delete_database for removal). No prerequisites, limitations, or contextual cues are provided, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new email account
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Email address (e.g., user@domain.com) | ||
| password | Yes | Password for the email account | |
| quota | No | Mailbox quota in MB (0 = unlimited) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description fails to disclose behavioral traits like conflict handling (if email exists), password policies, or quota enforcement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence with no wasted words, though slightly more detail could be included without hurting conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Missing critical context such as return behavior, error handling, and quota constraints, especially given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for each parameter, so the description adds no additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new email account' clearly states the action and resource, distinguishing it from sibling tools like cpanel_delete_email or cpanel_list_email_accounts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, nor prerequisites or limitations (e.g., domain existence, quota restrictions).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new subdomain
| Name | Required | Description | Default |
|---|---|---|---|
| subdomain | Yes | Subdomain name (e.g., 'blog' for blog.domain.com) | |
| domain | Yes | Parent domain name | |
| rootdomain | No | Root directory for the subdomain (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose behavioral traits such as whether existing subdomains are overwritten, required permissions, or side effects like DNS changes. For a creation tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no extraneous text, making it quick to read. However, it could be slightly longer to include essential context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and moderate parameter count (3), the description fails to mention return values, error handling, or post-creation behavior. It is minimally adequate but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (all three parameters have descriptions), so the baseline is 3. The description adds no additional context beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new subdomain' clearly identifies the action (create) and resource (subdomain), distinguishing it from siblings like cpanel_delete_subdomain and cpanel_list_subdomains. However, it lacks details on scope or constraints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., creating a subdomain via cPanel's API or other tools). There is no mention of prerequisites like domain existence or quota limits.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a MySQL database
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Full database name to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It fails to mention that deletion is irreversible, may affect dependent applications, or requires specific permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation, the description is minimally adequate but lacks details on return values, error handling, and consequences, which are important for a destructive action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter 'name', which already says 'Full database name to delete'. The tool description adds no extra value, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a MySQL database' clearly states the action (delete) and the resource (MySQL database). It distinguishes from sibling tools like cpanel_create_database and cpanel_list_databases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool, prerequisites, or alternatives. The description lacks any context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete an email account
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Email address to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description fails to disclose behavioral traits such as permanence of deletion, required permissions, or whether the email account must exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but not tautological; however, it could be more informative without adding much length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (1 parameter, no output schema), the description is minimal but still lacks details on return behavior or side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description of the parameter 'email' (Email address to delete) adds no extra meaning beyond the schema itself. Baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it deletes an email account, which is a specific verb+resource pair. It distinguishes from sibling tools like cpanel_create_email or cpanel_list_email_accounts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like cpanel_delete_database or cpanel_delete_file. No prerequisites or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a file or directory
| Name | Required | Description | Default |
|---|---|---|---|
| file | Yes | Full path to the file or directory to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides no behavioral details beyond the action itself. Critical traits like recursive deletion, permission requirements, or error handling are omitted. Since no annotations exist, the description fails to inform the agent about important side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, but it is too brief for a destructive tool. While efficient, it sacrifices necessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature and the presence of sibling delete tools, the description should explain differences and outcomes. The lack of output schema and behavior details leaves the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the parameter 'file' with 'Full path to the file or directory to delete', achieving 100% coverage. The description adds no extra meaning, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Delete' and the resource 'a file or directory', making the tool's purpose immediately understandable. However, it does not differentiate from sibling delete tools for other entity types, which could be clearer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any prerequisites or exclusions. For a destructive operation, such guidance is essential.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a subdomain
| Name | Required | Description | Default |
|---|---|---|---|
| subdomain | Yes | Full subdomain name (e.g., 'blog.domain.com') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description should disclose behavioral traits. It only states 'Delete a subdomain' without mentioning irreversibility, permissions needed, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It is appropriately concise for a simple tool, though it could benefit from additional context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description is minimally adequate but lacks information about return values, success indicators, or error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter is well-described with an example. The description adds no additional meaning beyond what the schema provides, so baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete) and the resource (subdomain). It is a specific verb+resource combo, but it does not distinguish from sibling tools like cpanel_create_subdomain or cpanel_list_subdomains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor are there any exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get disk usage statistics for the account
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is minimal and does not disclose any behavioral traits beyond being a read operation. Given no annotations, it could briefly mention that it is safe and non-destructive, but for a simple read the lack is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no extraneous words, perfectly concise for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema, and a straightforward purpose, the description is complete enough for an agent to understand what it does. A mention of the return format could push it to 5, but 4 is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the description has no burden to explain parameter meaning. Schema coverage is 100%. Baseline score of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'disk usage statistics for the account', which distinguishes it from sibling tools that handle backups, databases, or file operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternative tools like cpanel_list_files or cpanel_backup, nor are there any prerequisites or context for its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Install SSL certificate for a domain
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain name to install SSL for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose side effects (e.g., overwriting existing SSL, required certificate format, impact on services). For an install operation, more transparency is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence without fluff, though it could benefit from slightly more detail without losing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and only one parameter, the description lacks critical context about prerequisites, return values, and potential side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description of the 'domain' parameter. The tool description does not add new meaning beyond the schema, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Install' and the resource 'SSL certificate for a domain', which is distinct from sibling tools that handle backups, databases, emails, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, nor any prerequisites (e.g., domain must exist, private key needed) or conditions where use is inappropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all MySQL databases
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It only states the action and resource without detailing return format, limits, or side effects, which is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no extraneous information. Every word is relevant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless list operation, the description is adequate. It could mention that it returns all databases without filtering, but it is sufficiently complete given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters (schema coverage 100% vacuously). The description does not need to add parameter information; baseline for zero parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all MySQL databases' uses a specific verb ('List') and resource ('MySQL databases'), clearly distinguishing it from sibling tools that create, delete, or modify databases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives (e.g., when to list vs. create/delete databases). The context is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all email accounts for the domain
| Name | Required | Description | Default |
|---|---|---|---|
| domain | No | Domain name (optional, lists all if not specified) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. However, it only states the operation and does not mention any behavioral traits such as authentication requirements, rate limits, or whether it is read-only. This is insufficient for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the core action. It wastes no words, though it could include additional context without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with one parameter and no output schema, the description is adequate but lacks completeness regarding the output format or any special behavior. It does not leverage the sibling tools to provide context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is one optional parameter ('domain') with 100% schema description coverage. The description does not add any semantic value beyond the schema, so it meets the baseline score of 3 as per guidelines.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all email accounts for the domain' clearly specifies a listing operation on email accounts, scoped to a domain. It effectively distinguishes from sibling tools like 'cpanel_create_email' or 'cpanel_delete_email', which are mutation operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates usage for listing email accounts, but provides no explicit guidance on when to use this tool versus alternatives, nor when not to use it. Given the context of sibling tools, the usage is implied but not clarified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List files and directories in a specified path
| Name | Required | Description | Default |
|---|---|---|---|
| dir | No | Directory path to list (default: home directory) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description bears full responsibility for behavioral context, but it only states the basic purpose. It omits details like whether hidden files are listed, whether recursion is possible, or any permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence that is front-loaded and free of unnecessary words. It conveys the essential purpose efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema), the description is mostly adequate. It could mention if file metadata (size, permissions) is returned, but the core functionality is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear parameter description for 'dir'. The tool description adds no additional value beyond what the schema already provides, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('files and directories') with a scope ('in a specified path'). It is distinct from sibling tools that list other resources like databases or email accounts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, it doesn't clarify that this is for directory browsing, not for reading file contents (which would use cpanel_read_file).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all subdomains
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description alone must disclose behavioral traits. It states 'List' implying a read-only operation, but lacks details on what exactly is listed (e.g., full subdomain names, records), authentication requirements, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. However, it could be slightly more informative without losing conciseness, such as adding what information is returned.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a simple listing task, the description is minimal. It does not clarify whether results include metadata like creation date or SSL status, which might be expected for subdomain management.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so coverage is 100%. The description adds no parameter-level detail, but given zero parameters, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all subdomains' uses a specific verb and resource, making the tool's purpose immediately clear. It effectively distinguishes itself from sibling tools that perform different actions on subdomains (e.g., create, delete) by focusing solely on listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as filtering or searching. There is no mention of prerequisites, scope, or behavior differences from other list tools (e.g., cpanel_list_databases).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read contents of a file
| Name | Required | Description | Default |
|---|---|---|---|
| file | Yes | Full path to the file to read |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only states basic function without disclosing behavior like read-only nature, permissions, size limits, or encoding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise and front-loaded, though lacks structure like bullet points or example usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks information about return value format (e.g., raw content, encoding), error handling, or file type support, despite low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with clear description; tool description adds no extra meaning beyond 'Full path to the file to read'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool reads file contents, distinguishing it from siblings like cpanel_write_file and cpanel_delete_file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like cpanel_list_files for directory listing, or prerequisites like file existence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write content to a file (creates or overwrites)
| Name | Required | Description | Default |
|---|---|---|---|
| file | Yes | Full path to the file | |
| content | Yes | Content to write to the file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states 'creates or overwrites' which implies the core behavior, but lacks details on permissions, size limits, encoding, error handling, or side effects. Adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence with no filler. Every word earns its place. It is front-loaded and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple write tool with full schema coverage and no output schema, the description is adequate but incomplete: it doesn't specify overwrite behavior (truncation vs appending), file permissions, or supported content types. Sibling differentiation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both parameters (file path and content). The description adds no extra meaning beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool writes content to a file, with the parenthetical 'creates or overwrites' specifying the behavior. It uses a specific verb and resource, and implicitly distinguishes from siblings like cpanel_read_file and cpanel_delete_file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description provides no guidance on when to use this tool versus alternatives (e.g., cpanel_read_file, cpanel_delete_file). There is no mention of prerequisites, context, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0cpanel_backupcpanel_create_databasecpanel_create_emailcpanel_create_subdomaincpanel_delete_databasecpanel_delete_emailcpanel_delete_filecpanel_delete_subdomaincpanel_disk_usagecpanel_install_sslcpanel_list_databasescpanel_list_email_accountscpanel_list_filescpanel_list_subdomainscpanel_read_filecpanel_write_fileEach tool targets a distinct resource and action (e.g., backup, database CRUD, email CRUD, subdomain CRUD, file operations, disk usage, SSL), with no overlapping purposes. Clear boundaries between all operations.
All tools follow a consistent 'cpanel_verb_noun' pattern in snake_case, making them predictable and easy to understand. No deviations or mixed conventions.
16 tools cover the essential cPanel hosting administration tasks without unnecessary bloat. The count is appropriate for the domain, providing sufficient functionality without overwhelming the agent.
Core operations for databases, emails, subdomains, files, backup, SSL, and disk usage are present. Minor gaps like missing update operations for databases/emails or a backup restore function are acceptable for typical cPanel management.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Hosted MCP server connecting AI assistants to 9,000+ apps and 40,000+ actions via Zapier.
Personal assistant MCP server with search, execute, packages, jobs, secrets, and integrations.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/aandersen2323/cpanel-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
