obambu-cpanel-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.2
Disambiguation5/5
Each 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.
Naming Consistency5/5
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.
Tool Count4/5
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.
Completeness3/5
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.
Average 3.6/5 across 14 of 16 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 8 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior1/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![obambu-cpanel-mcp MCP server](https://glama.ai/mcp/servers/RodrigueDev13/obambu-cpanel-mcp/badges/card.svg)](https://glama.ai/mcp/servers/RodrigueDev13/obambu-cpanel-mcp)

Score Badge

Copy to your README.md:

[![obambu-cpanel-mcp MCP server](https://glama.ai/mcp/servers/RodrigueDev13/obambu-cpanel-mcp/badges/score.svg)](https://glama.ai/mcp/servers/RodrigueDev13/obambu-cpanel-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/RodrigueDev13/obambu-cpanel-mcp'

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