Provides tools for managing cPanel hosting accounts, including domains, DNS records, email accounts, MySQL databases, and file listing through the cPanel UAPI.
Allows management of MySQL databases and database users, including creating databases, creating users, and granting privileges, via cPanel's UAPI.
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., "@obambu-cpanel-mcp Show me the DNS records for example.com"
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 Model Context Protocol (MCP) server that lets an AI assistant (Claude, etc.) manage a cPanel hosting account through the cPanel UAPI.
It exposes tools for domains, DNS zones, email accounts, MySQL databases, and file listing, plus a generic escape hatch to call any other UAPI module/function.
Node.js 18+
A cPanel account with API token access (Security → Manage API Tokens in cPanel)
Related MCP server: cPanel MCP Server
The four env vars below can come from any cPanel host, but here's how to find them on Obambu:
CPANEL_HOST — your server hostname, e.g. cp4.obambu.com (or your own domain if cPanel is reachable at https://yourdomain.com:2083). Find it in your Obambu welcome email, or in your domain's DNS zone: look for an A record named cpanel (e.g. cpanel.yourdomain.com) — that same server also answers at its cpX.obambu.com hostname.
CPANEL_PORT — 00000 (cPanel's default HTTPS port). Leave it unless your host says otherwise.
CPANEL_USERNAME — your cPanel account username, shown top-right when logged into cPanel, or in the welcome email Obambu sent when the hosting account was created.
CPANEL_API_TOKEN — generate one yourself, it is not your cPanel password:
Log into cPanel at https://<CPANEL_HOST>:00000
Go to Security → Manage API Tokens
Click Create, give it a name (e.g. mcp-server), optionally restrict it to specific ACLs, then Create
Copy the token immediately — cPanel only shows it once
Published on npm as obambu-cpanel-mcp — no clone or build needed. Add it to your MCP client config (e.g. Claude Desktop / Claude Code):
{
"mcpServers": {
"obambu-cpanel": {
"command": "npx",
"args": ["-y", "obambu-cpanel-mcp"],
"env": {
"CPANEL_HOST": "your-server-hostname-or-ip",
"CPANEL_PORT": "00000",
"CPANEL_USERNAME": "your-cpanel-username",
"CPANEL_API_TOKEN": "your-api-token"
}
}
}
}git clone https://github.com/RodrigueDev13/obambu-cpanel-mcp.git
cd obambu-cpanel-mcp
npm install
cp .env.example .envEdit .env with your cPanel details, then:
npm run build
npm startFor local development without building first:
npm run devWhen running from source, point your MCP client at the built entrypoint instead of npx:
{
"mcpServers": {
"obambu-cpanel": {
"command": "node",
"args": ["/absolute/path/to/obambu-cpanel-mcp/dist/index.js"],
"env": {
"CPANEL_HOST": "your-server-hostname-or-ip",
"CPANEL_PORT": "00000",
"CPANEL_USERNAME": "your-cpanel-username",
"CPANEL_API_TOKEN": "your-api-token"
}
}
}
}Tool | Description |
| Disk/bandwidth quota usage and general stats |
| Domains, subdomains, addon domains and parked domains |
| Read a domain's DNS zone |
| Add a DNS record |
| Edit an existing DNS record |
| Remove a DNS record |
| List email accounts |
| Create an email account |
| Delete an email account |
| List files/directories under the account home directory |
| List MySQL databases |
| List MySQL database users |
| Create a MySQL database |
| Create a MySQL database user |
| Grant a user privileges on a database |
| Call any UAPI module/function directly for anything not covered above |
Once connected, just talk to your assistant in plain language — it picks the right tool:
"Test the connection to my cPanel account" → get_account_summary
"What domains and subdomains are on this hosting account?" → list_domains
"Show me the DNS records for example.com" → list_dns_records
"Add an A record for shop.example.com pointing to 1.2.3.4" → add_dns_record
"Create a mailbox contact@example.com" → create_email
"Create a MySQL database and user for my new app, then grant privileges" → create_database + create_database_user + grant_database_privileges
"List the files in public_html" → list_files
"Read config/filesystems.php and fix this path" → cpanel_uapi_call with module: "Fileman", function: "get_file_content" / save_file_content
Because tool calls map directly to UAPI modules, this is also useful for real migration/deployment workflows — e.g. moving a site to a new cPanel account, provisioning a database for a fresh app, or auditing DNS before a domain cutover.
FilemanOnly list_files (backed by Fileman::list_files) and, through the cpanel_uapi_call escape hatch, get_file_content / save_file_content are known to work reliably for reading and writing individual files. Bulk filesystem operations (extract_files, rename, mkdir, fileop, delete_files, ...) are not guaranteed to be available depending on your cPanel version/provider — test before relying on them, and prefer cPanel's File Manager UI for bulk moves, extraction, and deletion.
Never commit your .env file (it's git-ignored by default).
Scope your cPanel API token as narrowly as your provider allows.
The cpanel_uapi_call tool can call any UAPI function available to your account — treat it with the same care as direct API/token access.
MIT
Add a DNS record to a zone. Provide type-specific fields in fields (e.g. A record: {address: '1.2.3.4'}; CNAME: {cname: 'target.example.com'}; TXT: {txtdata: 'value'}; MX: {exchange: 'mail.example.com', preference: '10'}).
| Name | Required | Description | Default |
|---|---|---|---|
| ttl | No | TTL in seconds, defaults to 14400 | |
| name | Yes | Record name, e.g. sub.example.com or example.com | |
| type | Yes | Record type: A, AAAA, CNAME, MX, TXT, NS, SRV, CAA... | |
| zone | Yes | Domain name owning the zone, e.g. example.com | |
| fields | No | Type-specific value fields required by cPanel for this record type |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose side effects and permissions. It mentions type-specific fields but does not state whether adding an existing record fails or overwrites, what authentication is required, or any idempotency behavior. This is a significant gap for a write operation.
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?
Two sentences, front-loaded with the primary action, followed by compact examples. No redundant information.
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 mutating tool with a nested fields object and no output schema, the description covers essential field examples but lacks guidance on response format, error conditions, or duplicate handling. It is minimally viable but leaves important operational details to the schema or runtime.
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 schema describes all parameters, providing baseline coverage. The description adds concrete field examples (e.g. A record: {address: '1.2.3.4'}; CNAME: {cname: 'target.example.com'}; TXT: {txtdata: 'value'}; MX: {exchange: 'mail.example.com', preference: '10'}), giving meaning beyond the schema's vague 'type-specific value fields' explanation, particularly for the nested fields object.
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 uses a specific verb 'Add' with a resource 'DNS record' and scopes it to a zone. The name and sibling context (list/edit/remove) make it clear this creates new records, distinguishing it from editing or deleting.
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 explains what the tool does but never explicitly states when to choose this over edit_dns_record or remove_dns_record. The context implies creation, but no exclusions or alternative tool guidance are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Call any cPanel UAPI module/function directly. Use this for functionality not covered by the other tools. Refer to cPanel UAPI documentation for module/function names and parameters.
| Name | Required | Description | Default |
|---|---|---|---|
| module | Yes | UAPI module name, e.g. 'Email', 'DNS', 'Mysql', 'DomainInfo' | |
| params | No | Query parameters to pass to the function | |
| function | Yes | UAPI function name within the module |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says 'Call any cPanel UAPI module/function directly' without disclosing that some UAPI functions may be destructive, require specific permissions, or have side effects. It also does not describe the response format or error behavior, leaving the agent with no awareness of potential risks or outcomes.
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 two sentences, front-loaded with the core action ('Call any cPanel UAPI module/function directly'), and every sentence serves a purpose: what it does, when to use it, and where to find details. There is no unnecessary information.
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?
The tool is a generic catch-all with no output schema and no annotations. The description covers what, why, and how to get more info, but it lacks any mention of behavioral risks, authorization requirements, or expected return structure. For a tool that can invoke arbitrary UAPI functions, this is a notable gap, though the external documentation pointer mitigates some incompleteness.
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 provides descriptions for all three parameters (module, function, params) with examples for module. The description adds value by directing the agent to refer to cPanel UAPI documentation for actual names and parameter values, which is essential because the schema only gives generic placeholders. This external reference compensates for the lack of context and enriches parameter understanding.
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 calls any cPanel UAPI module/function directly, using the specific verb 'Call' and resource 'cPanel UAPI module/function'. It explicitly distinguishes itself from siblings by saying 'Use this for functionality not covered by the other tools,' making its role as a fallback 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?
Provides an explicit when-to-use condition: 'Use this for functionality not covered by the other tools.' This also implicitly tells the agent not to use it for operations already covered by sibling tools. Additionally, it directs the agent to consult cPanel UAPI documentation for names and parameters, which is helpful for correct invocation.
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 (without the cPanel account prefix) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states that a new database is created, offering no details about side effects, permissions required, reversibility, or what happens on success. It is not misleading but is extremely 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 concise sentence with no redundant words. It is appropriately sized for a simple tool and front-loads the core action.
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 mutation tool with no annotations and no output schema, the description is insufficiently complete. It does not explain the context of creation (e.g., under the cPanel account), the automatic prefixing mentioned in the schema, or expected return values. The sibling tools hint at a workflow, but the description alone leaves the agent without enough 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?
Schema coverage is 100% and the parameter 'name' has a clear description ('without the cPanel account prefix'). The tool description adds no additional parameter information, but the schema already documents the sole parameter adequately, so the baseline 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 'Create a new MySQL database' uses a specific verb and resource, clearly distinguishing it from sibling tools like grant_database_privileges, create_database_user, and list_databases. It states exactly what the tool does with no ambiguity.
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 provides no explicit guidance on when to use this tool versus alternatives. There is no mention of prerequisites, related tools (e.g., creating a user or granting privileges), or scenarios where another tool would be more appropriate. Usage is only implied by the tool's name and description.
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 user.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Username (without the cPanel account prefix) | |
| password | Yes | Password for the new user |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'Create' with no mention of side effects, requirements (e.g., cPanel prefix from the schema), error handling, or whether the operation is idempotent. This is insufficient for a mutation operation, leaving the agent unaware of potential failures or prerequisites.
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 zero waste. It conveys the core action in six words, matching the simplicity of the tool. There is no redundancy or extraneous information, making it highly scannable for an agent.
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?
Despite the low parameter count, the description lacks critical context. There is no guidance on when to use it relative to sibling tools, no behavior details, and no output description. With no annotations or output schema, the description alone is inadequate for an agent to fully understand the tool's behavior and integration into workflows.
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% for both parameters (name and password), so the baseline is 3. The description adds no parameter-level information beyond what the schema already provides. The schema's note about 'cPanel account prefix' is the only meaningful semantic detail, but it comes from the schema, not the description.
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 tool's function: 'Create a new MySQL database user.' It uses a specific verb ('create') and resource ('MySQL database user'), which distinguishes it from sibling tools like create_database (creates databases) and grant_database_privileges (grants privileges). This leaves no ambiguity about what the tool does.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention that this is a prerequisite for granting privileges, or that it should be used when setting up a new database user. Without exclusions or context, the agent must infer usage from the name alone.
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 | Local part of the address, e.g. 'contact' for contact@example.com | ||
| domain | Yes | Domain for the mailbox, e.g. example.com | |
| quotaMb | No | Mailbox quota in MB, 0 for unlimited | |
| password | Yes | Password for the new mailbox |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It only says 'Create a new email account' and gives no information about side effects, permissions, error handling, or whether the domain must already exist. This is insufficient for a mutation tool.
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 wasted words. It efficiently communicates the core purpose.
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?
The tool has no output schema or annotations, and the description does not explain return values, idempotency, or prerequisites such as domain existence. While the schema covers parameters, a create operation needs more contextual detail to be fully usable by an agent.
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%, so the schema already documents all parameters. The description adds no additional parameter semantics beyond what is in the schema, so the 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 action ('Create') and the resource ('email account'), distinguishing it from sibling tools like delete_email and create_database_user. It is specific and 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 is provided on when to use this tool versus alternatives. Sibling tools suggest related operations, but the description does not mention prerequisites, exclusions, or scenarios where another tool would be more appropriate.
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 | Local part of the address to delete | ||
| domain | Yes | Domain of the mailbox |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must convey behavioral risks. It only says 'delete' without disclosing that deletion is permanent, whether associated data is removed, or if special permissions are required. For a destructive operation, this is a significant transparency gap.
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, focused sentence with no filler or redundancy. It is concise and front-loaded, though it could add more detail without becoming verbose.
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 destructive tool with no annotations, the description is too thin. It does not mention return behavior, side effects, permanence, or any operational caveats. Given the simplicity of the tool, a bit more behavioral context would make it complete.
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 100% description coverage for both parameters (email and domain), so the schema does the heavy lifting. The description adds no additional meaning about parameter usage or format.
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 uses a clear verb+resource construction ('Delete an email account') that immediately distinguishes it from siblings like create_email and list_emails. It states exactly what the tool does.
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 usage context is implied: use this when you need to remove an email account. However, there is no explicit guidance about prerequisites, alternatives, 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.
Edit an existing DNS record. line is the record's line number as returned by list_dns_records.
| Name | Required | Description | Default |
|---|---|---|---|
| ttl | No | ||
| line | Yes | Line number of the record in the zone (from list_dns_records) | |
| type | Yes | Record type: A, AAAA, CNAME, MX, TXT, NS, SRV, CAA... | |
| zone | Yes | Domain name owning the zone | |
| fields | No | Type-specific value fields to update for this record type |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only states 'Edit an existing DNS record' without mentioning side effects, whether updates are partial or full, error behavior, or permission requirements. This is a significant gap for a mutation tool.
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 concise, consisting of one main sentence plus a brief clarification of the `line` parameter. Every word earns its place, and the most important usage hint is front-loaded.
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?
Despite having 5 parameters, a nested `fields` object, and no output schema, the description provides only minimal context. It does not explain how `fields` is structured, what TTL means, or the behavior of the edit operation. The helpful line-number hint is not enough to make this complete for a mutation tool with complex inputs.
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 80%, so baseline is 3. The description repeats the schema's explanation of `line` but does not add further meaning to other parameters. TTL has no schema description and is not covered in the tool description. Overall, the description adds no extra semantic value 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 clearly states the tool edits an existing DNS record, using the specific verb 'Edit' and resource 'DNS record'. It is distinguishable from sibling tools like add_dns_record and remove_dns_record, though it does not explicitly name them as alternatives.
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 implies when to use the tool (to edit an existing record) and provides a critical prerequisite by noting that `line` is the record line number from list_dns_records. However, it does not explicitly discuss when not to use it or how it compares to add/remove operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get an overview of the cPanel account: disk/bandwidth quota usage and general stats.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavioral traits. The verb 'Get' implies a read-only operation, and 'overview' suggests no side effects. However, the description does not explicitly state that it modifies nothing, nor does it mention permissions, rate limits, or other behavioral details. It gives a basic inference but lacks depth.
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, efficiently worded sentence that front-loads the action ('Get an overview') and resource ('cPanel account') before adding specific details. Every word contributes value, with no redundancy or filler. It is concise and well-structured.
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?
The tool has zero parameters and no output schema, so the description must explain what the tool returns. It mentions 'disk/bandwidth quota usage and general stats', which covers the key return elements but remains somewhat vague on 'general stats'. Given the simplicity of the tool and its distinct role among siblings, the description is adequate but lacks specific detail on the exact set of stats or response format.
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 input schema is trivially 100% covered. The description does not need to explain parameters. According to the rubric, 0 params corresponds to a baseline of 4, and the description adds no conflicting or missing parameter information, so the baseline 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 a specific verb and resource: 'Get an overview of the cPanel account'. It specifies the content (disk/bandwidth quota usage and general stats), which is distinct from sibling tools that focus on databases, domains, DNS, emails, or files. This is a unique account-level summary tool, so it distinguishes itself well.
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 implies usage by stating 'Get an overview of the cPanel account', making it clear this is for high-level account stats. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or when-not-to-use scenarios. The guidance is implied rather than explicit, so it does not reach the higher bars.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Grant a database user privileges on a database.
| Name | Required | Description | Default |
|---|---|---|---|
| user | Yes | Full database username (as returned by list_database_users) | |
| database | Yes | Full database name (as returned by list_databases) | |
| privileges | No | Comma-separated privileges, defaults to ALL PRIVILEGES | ALL PRIVILEGES |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states 'Grant... privileges' with no mention of side effects, whether existing privileges are replaced, permission requirements, or return behavior. This is inadequate for a mutation tool.
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 redundant words. It is appropriately sized 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?
The tool is simple and the schema covers parameter semantics, but the description omits important behavioral context such as whether privileges are additive or replacing, and does not mention output or failure modes. The tool is minimally complete but has clear 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?
The input schema provides 100% coverage with useful descriptions for all parameters, including the comma-separated format and default for privileges. The description adds no additional parameter semantics, but the schema does the heavy lifting, yielding the baseline score of 3.
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 uses the specific verb 'Grant' and identifies the resource ('privileges on a database'), making the action and target unambiguous. It is clearly distinct from sibling tools like create_database_user or create_database.
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 provides no guidance on when to use this tool versus alternatives, nor prerequisites or exclusions. The purpose implies a use case, but explicit usage context is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List MySQL databases on the account.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clearly indicates a read-only list operation, which is a behavioral trait. However, with no annotations provided, the description carries the full burden and does not disclose output format, permissions, or limitations beyond the basic action.
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, direct sentence with no unnecessary words. It front-loads the action and resource clearly.
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?
There is no output schema, so the return value is not described. However, for a simple list operation with no parameters, the description provides the minimum viable information for an agent to use it.
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 tool has zero parameters, so the description needs no parameter explanation. Per rubric, a baseline of 4 is appropriate when there are no parameters to describe.
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 uses the specific verb 'List' with the resource 'MySQL databases' and scope 'on the account'. This clearly distinguishes it from sibling tools like create_database or grant_database_privileges.
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 usage guidance is given. The intended use is implied by the action and sibling names, but there is no direct statement of when to use this tool versus alternatives or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List MySQL database users on the account.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of behavioral disclosure. It adds contextual details like 'on the account' and 'MySQL', indicating scope and database type, but it does not mention return format, permissions, pagination, or explicitly confirm a read-only operation, leaving some ambiguity.
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, front-loaded with the action 'List' and the resource. Every word adds value, making it highly concise and structured for quick understanding.
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 zero-parameter list tool, the description covers the essential information: what it does, the resource type, and the scope. No output schema is present, but the description's simplicity makes it complete enough for an agent to invoke correctly.
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 tool has zero parameters, and the schema coverage is 100% trivially. The description adds meaning by specifying the account scope, which is not captured in the schema. Baseline for 0 params is 4, and the description does not detract from 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 the tool lists MySQL database users on the account, using the specific verb 'List' and resource 'MySQL database users'. This distinguishes it from sibling tools like list_databases (which lists databases) and create_database_user (which creates users).
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 implies usage by naming the resource and scope, but does not explicitly state when to use this tool versus alternatives such as list_databases or grant_database_privileges. There is no exclusion or comparison provided, so the guidance remains implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List DNS zone records for a domain.
| Name | Required | Description | Default |
|---|---|---|---|
| zone | Yes | Domain name whose DNS zone to read, e.g. example.com |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the transparency burden. The verb 'List' implies a read-only operation, which is a useful behavioral signal, but the description does not disclose output format, pagination, error responses, or authentication requirements. It adds minimal context beyond the tool name.
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 or repetition. Every word adds value, making it highly 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 list tool with one well-documented parameter, the description is largely complete. It doesn't describe return format or error behavior, but the absence of an output schema and the tool's straightforward nature make this acceptable. The description adequately covers the tool's primary use case.
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 schema covers 100% of the parameter with a clear description ('Domain name whose DNS zone to read, e.g. example.com'). The tool description adds no additional parameter semantics, so the baseline score of 3 is appropriate given the 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 uses a specific verb 'List' with a clear resource 'DNS zone records' and scoping 'for a domain'. This unambiguously distinguishes it from sibling tools like add_dns_record, edit_dns_record, remove_dns_record, and list_domains.
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 implies usage for reading DNS records but does not explicitly state when to use it versus alternatives, nor does it mention when not to use it. The context is clear enough that an agent could infer its purpose, but no exclusionary or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all domains, subdomains, addon domains and parked domains on the account.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It indicates the scope (all domains) and context (account), but does not explicitly state that this is a read-only operation or describe the response format. The verb 'list' implies read-only, but more detail on behavior (e.g., no pagination, returns array) would be beneficial.
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 sentence, 15 words, listing all relevant domain types without redundancy. It is concise and front-loaded, with every word adding value.
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?
The description tells you what is returned (domains, subdomains, etc.) but not the response structure or any potential limitations (e.g., whether it includes the main domain). For a simple list tool, it is adequate but has gaps in return format and edge cases.
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 zero parameters, so the description does not need to explain any. It fully covers the operation's scope without needing parameter details, aligning with the baseline for no-parameter tools.
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 (domains of various types) with specific detail (subdomains, addon, parked). It distinguishes from sibling tools like list_databases or list_dns_records, as it is the only domain-focused list tool.
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 when-to-use or alternative tools are mentioned, but the purpose is self-evident for a list operation. The context that it lists all domains on the account is clear, yet there is no guidance on when not to use it or how it compares to other list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List email accounts, optionally filtered by domain.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | No | Limit results to this domain |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the listing action and optional filter, but does not mention permissions, side effects, pagination, or return format. The agent is left to infer that this is a read-only operation.
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, front-loaded with the verb and resource, and contains no redundant words. It is optimally concise while conveying the essential behavior.
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?
The tool is low in complexity with one optional parameter and no output schema. The description adequately states the purpose and filter capability, but does not describe the return format or any caveats. With no annotations or output schema, a bit more detail would be expected for full completeness, though the core function is covered.
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 includes a complete description of the single 'domain' parameter ('Limit results to this domain'), with 100% coverage. The description's mention of the optional filter adds minimal extra meaning, so it meets the baseline for schema-backed parameter documentation.
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 ('email accounts'), and notes the optional domain filter. This effectively distinguishes it from sibling tools like list_databases and list_domains, which target different resources.
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 provides clear context for when the tool is appropriate: any time you need to list email accounts. The optional domain filter adds a specific use case. However, it does not explicitly name alternatives or exclusions, but the purpose is unambiguous enough to guide selection.
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 at a path within the account's home directory.
| Name | Required | Description | Default |
|---|---|---|---|
| dir | No | Directory to list, relative to the home directory | / |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clarifies the path is relative to home, but does not mention whether the listing is recursive, whether hidden files are included, or what the return format is. This is a significant gap for a list operation with no output schema.
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, efficient sentence with no filler. It front-loads the action and resource, making it immediately scannable.
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?
The tool is simple with only one optional parameter, but there is no output schema and no annotations. The description does not specify what the response contains (e.g., file names, sizes, types) or whether the listing is recursive, leaving some ambiguity for an agent to resolve. Adequate but with clear 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?
The input schema already includes a description for the 'dir' parameter (relative to home directory), so schema coverage is 100%. The tool description only reinforces the home-directory scope without adding new parameter semantics, keeping this at baseline 3.
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 states a specific verb ('List') and resource ('files and directories') with a clear scope ('within the account's home directory'). This distinguishes it from sibling tools like list_databases or list_emails, which target different resource types.
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 implies usage for inspecting files, but it provides no explicit guidance on when to choose this tool over alternatives, nor any exclusions. The scope is clear, but there is no mention of when to use a different listing tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a DNS record from a zone. line is the record's line number as returned by list_dns_records.
| Name | Required | Description | Default |
|---|---|---|---|
| line | Yes | Line number of the record to remove | |
| zone | Yes | Domain name owning the zone |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It states the operation is 'Remove' but does not mention irreversibility, error handling, or side effects (e.g., propagation delays). The only added context is the origin of `line`, which is useful but insufficient for a destructive operation.
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 front-loads the core purpose and immediately follows with the key parameter clarification. Every word earns its place; no redundancy or fluff.
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 tool with two parameters, no output schema, and a clear sibling set (add/edit/list DNS records), the description covers the essential aspects: the operation, the target, and the parameter provenance. It could be richer with a warning about permanence, but overall it is adequate for this level of 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 coverage is 100% with both parameters already described. The description adds meaningful context by explaining that `line` is the line number returned by `list_dns_records`, clarifying its provenance and intended usage beyond the schema's simple type/description.
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 ('Remove') and the target resource ('a DNS record from a zone'), immediately distinguishing it from sibling tools like add_dns_record and edit_dns_record. The verb+resource combination is specific and 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?
It explicitly references `list_dns_records` as the source for the `line` parameter, which implies a prerequisite workflow. However, it does not explicitly state when NOT to use this tool or compare it against edit_dns_record as an alternative, leaving some room for ambiguity.
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.
v0.1.2add_dns_recordcpanel_uapi_callcreate_databasecreate_database_usercreate_emaildelete_emailedit_dns_recordget_account_summarygrant_database_privilegeslist_database_userslist_databaseslist_dns_recordslist_domainslist_emailslist_filesremove_dns_recordEach tool targets a distinct resource and action (database, DNS, email, files, account), and even the generic cpanel_uapi_call is clearly scoped as a fallback for uncovered functionality. There is little risk of selecting the wrong tool for a given task.
All tool names follow a consistent lowercase snake_case verb_noun pattern (e.g., list_domains, create_database, add_dns_record, delete_email). The action verbs vary appropriately by resource but the structure is uniform and predictable.
With 16 tools, the count slightly exceeds the typical 3-15 well-scoped range, but the server covers multiple cPanel domains (databases, DNS, email, files, account) and each tool serves a distinct function. The number is reasonable, if a touch heavy.
The surface covers common operations but has notable gaps: no delete_database, delete_database_user, update_email, or file management beyond listing. The generic cpanel_uapi_call can fill these gaps, but the specific tool set itself is incomplete for full lifecycle management.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Agent-first web hosting: deploy sites, apps, databases and domains over MCP.
MCP server for DNSimple — domains, DNS zone records, availability, pricing and contacts.
Personal assistant MCP server with search, execute, packages, jobs, secrets, and integrations.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/RodrigueDev13/obambu-cpanel-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
