Restarts MariaDB database service on a GridPane server.
Restarts MySQL (or MariaDB/Percona) database service on a GridPane server.
Restarts Nginx web server on a GridPane server.
Restarts PHP-FPM for a specific PHP version and changes the PHP version for a WordPress site.
Manages WordPress sites hosted on GridPane, including listing, toggling SSL and caching, purging caches, toggling debug mode, changing PHP version, generating SSO links, and triggering backups.
Click on "Deploy 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., "@gridpane-mcp List all my GridPane servers"
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 for the GridPane hosting platform API. Manage your WordPress servers and sites through Claude, Cursor, or any MCP-compatible client.
list_servers — List all servers with IPs, status, and site counts
get_server — Get detailed server info by ID
search_server — Find servers by name (partial match)
restart_nginx — Restart Nginx on a server
restart_php — Restart PHP-FPM for a specific PHP version
restart_mysql — Restart MySQL/MariaDB/Percona
list_sites — List all WordPress sites across all servers
get_site — Get detailed site info by ID
search_site — Find sites by domain name (partial match)
toggle_ssl — Toggle SSL on/off
toggle_site_cache — Toggle Nginx caching
purge_site_cache — Purge all server-level caches
toggle_debug — Toggle WordPress debug mode
change_php_version — Change PHP version (7.4, 8.0, 8.1, 8.2, 8.3)
get_sso_link — Get a Single Sign-On link to wp-admin
trigger_backup — Trigger a manual backup
Related MCP server: easypanel-mcp-server
A GridPane account (Developer plan or above)
A GridPane API token (Settings > GridPane API > Create New Token)
pip install gridpane-mcpOr with uv:
uv pip install gridpane-mcpSet your GridPane API token as an environment variable:
export GRIDPANE_API_TOKEN="your_token_here"claude mcp add gridpane -e GRIDPANE_API_TOKEN=your_token_here -- gridpane-mcpAdd to your claude_desktop_config.json:
{
"mcpServers": {
"gridpane": {
"command": "gridpane-mcp",
"env": {
"GRIDPANE_API_TOKEN": "your_token_here"
}
}
}
}Add to your Cursor MCP settings:
{
"mcpServers": {
"gridpane": {
"command": "gridpane-mcp",
"env": {
"GRIDPANE_API_TOKEN": "your_token_here"
}
}
}
}Once connected, you can ask your AI assistant things like:
"List all my GridPane servers"
"Find sites with 'supple' in the domain"
"Purge cache for site ID 661035"
"Restart Nginx on the accesshealth server"
"What PHP version is accesshealth.com.au running?"
"Toggle debug mode on site 661035"
Variable | Default | Description |
| (required) | Your GridPane API personal access token |
|
| GridPane API base URL |
MIT
Change PHP version for a site. Common versions: 7.4, 8.0, 8.1, 8.2, 8.3
| Name | Required | Description | Default |
|---|---|---|---|
| site_id | Yes | ||
| php_version | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only says 'Change PHP version' without disclosing any behavioral traits such as whether it causes downtime, requires authentication, or has side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using a single sentence plus a list of examples. No unnecessary words.
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 a simple interface with two required parameters and an output schema (not shown). The description is adequate but lacks details on return values or error conditions, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the parameters site_id or php_version beyond listing common version strings. It fails to add meaningful semantics 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 changes the PHP version for a site, using a specific verb and resource. It distinguishes from siblings like restart_php by focusing on version change.
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 only lists common versions but provides no guidance on when to use this tool versus alternatives like restart_php or toggle_debug. No prerequisites or contextual advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed info for a specific server by its ID.
| Name | Required | Description | Default |
|---|---|---|---|
| server_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description implies a read-only operation ('get detailed info'), which is sufficient for a simple retrieval tool. Lacks disclosure of potential rate limits, auth requirements, or other behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence of 10 words, no filler, front-loaded with action and resource. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required parameter, output schema exists), the description is largely complete. It could add what 'detailed info' includes, but not necessary since output schema covers that.
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 0% (no description for server_id). Description mentions 'by its ID' but adds no meaning beyond the schema's property name. For a required integer ID, this is minimal compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Get', resource 'detailed info for a specific server', and qualifier 'by its ID'. This distinguishes it from sibling tools like list_servers (list all) and search_server (search by criteria).
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?
Implied that you use this when you have a server ID, but no explicit guidance on when not to use it or alternatives. No contrast with sibling tools like list_servers or search_server.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed info for a specific site by its ID.
| Name | Required | Description | Default |
|---|---|---|---|
| site_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states 'get detailed info' without specifying what information is returned, any prerequisites, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is clear, front-loaded, and contains no unnecessary words. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 required param, no nested objects) and the presence of an output schema, the description is mostly complete. However, it could mention that the site_id should come from a previous list/serach call, but this is implied.
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?
With 0% schema description coverage, the description adds minimal meaning beyond the type. It mentions 'by its ID' but does not clarify what the site_id represents or how to obtain a valid ID.
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 is to 'get detailed info for a specific site by its ID', which is a specific verb+resource combination. This distinguishes it from sibling tools like list_sites and search_site.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like search_site or list_sites. The description only notes identification by ID but does not provide context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a Single Sign-On link to access wp-admin for a site.
| Name | Required | Description | Default |
|---|---|---|---|
| site_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 fails to disclose behavioral traits such as whether the link is time-limited, requires specific permissions, or has side effects. Minimal info beyond the 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, clear sentence with no wasted words. However, it could be slightly expanded to improve completeness 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 simple tool with one parameter and an output schema (not shown), the description is somewhat adequate but misses details like link properties (expiry, usage limits). It does not fully compensate for the lack of annotations or schema descriptions.
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 0%, but the description does not add meaning to the single parameter 'site_id' (e.g., what constitutes a valid ID or how to obtain it). The parameter name is self-explanatory but lacks context.
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 ('Get'), resource ('Single Sign-On link'), and purpose ('to access wp-admin for a site'), clearly distinguishing it from sibling tools like 'get_server' or 'get_site' which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives, nor any when-not-to-use conditions. The description merely states the action without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all GridPane servers with their IPs, status, and site counts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It mentions output fields but does not state it is read-only, nor does it cover pagination or any potential limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no redundancy, efficiently conveying tool 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?
Given no parameters and existence of an output schema, the description is mostly complete but lacks mention of potential pagination or result limits.
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, and schema coverage is 100%. The description adds value by listing output fields, which informs the agent of expected return data.
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' and identifies the resource 'servers' along with included fields (IPs, status, site counts). It clearly distinguishes from sibling tools like list_sites.
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 like search_server or get_server. It only implies usage for listing all servers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all WordPress sites across all servers.
| Name | Required | Description | Default |
|---|---|---|---|
| per_page | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility. It fails to disclose potential pagination (despite per_page parameter), rate limits, or the scope of 'all servers', which could be misleading.
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 waste, but is under-specified for a tool with zero schema coverage. It could be expanded moderately without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (1 param, output schema exists), the description is adequate but lacks behavioral context like pagination, which is important for a listing tool.
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 0%, and the description adds no detail about the per_page parameter. The agent receives no guidance on its meaning or default behavior beyond the schema's default value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all WordPress sites across all servers' uses a specific verb ('List') and resource ('WordPress sites'), and clearly distinguishes from sibling tools like list_servers and get_site.
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 like search_site for filtered listing. The description lacks context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Purge all server-level caches for a site.
| Name | Required | Description | Default |
|---|---|---|---|
| site_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a destructive action (purging caches) but does not explain reversibility, side effects, or impact on site performance. No annotations exist to compensate.
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, well-formed sentence with no unnecessary words. Perfectly concise.
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 an output schema, the description omits crucial context for a destructive action: when to purge, what is invalidated, and expected side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description adds no meaning to the only parameter 'site_id'. Does not explain its source 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 clearly states the action ('Purge'), the resource ('all server-level caches'), and the scope ('for a site'). It effectively distinguishes from siblings like toggle_site_cache by specifying 'purge' vs 'toggle'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like toggle_site_cache. No prerequisites or context about site status provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Restart MySQL/MariaDB/Percona on a server.
| Name | Required | Description | Default |
|---|---|---|---|
| server_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry the full burden. It does not disclose key behaviors such as downtime, confirmation prompts, timeouts, or impact on existing connections. This is insufficient for a potentially 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 very short (one line) and to the point. It could include more useful information without being overly long, but it is not 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 simple restart tool with one required parameter and an output schema, the description is partially complete. However, it lacks behavioral details and parameter explanation, which are critical for correct usage.
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 0%, and the description does not explain the 'server_id' parameter beyond its type. The agent has no guidance on what value to provide or where to find 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 action (restart) and the resource (MySQL/MariaDB/Percona on a server). It distinguishes from sibling tools like restart_nginx, restart_php, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any prerequisites or exclusions. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Restart Nginx on a server.
| Name | Required | Description | Default |
|---|---|---|---|
| server_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the action. It does not disclose behavior such as graceful restart, impact on connections, or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but lacks essential context for effective use. It is concise in word count but does not earn its space by providing value beyond the name.
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 an output schema, the description fails to explain return values, side effects, or required preconditions. It is incomplete for a tool with no annotations.
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 0%. The description adds no meaning to the 'server_id' parameter—does not specify format, source, or how to obtain 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 action (restart) and the resource (Nginx on a server). It distinguishes itself from sibling tools like restart_mysql and restart_php by specifying the service.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as stop/start or other restart operations. The description does not mention prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Restart PHP-FPM on a server for a specific PHP version.
| Name | Required | Description | Default |
|---|---|---|---|
| server_id | Yes | ||
| php_version | No | 8.1 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only states the action without disclosing side effects like service interruption, permissions needed, or revert capability.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, efficient and to the point. However, lacks detail that could be added 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 restart operation with an output schema, description is too minimal. No info on expected outcomes, duration, or conditions for success.
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 has 0% description coverage and description adds no parameter details. server_id and php_version are not explained beyond their names and default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (restart), resource (PHP-FPM on a server), and specificity (for a specific PHP version). Distinguishes from siblings like restart_mysql and restart_nginx.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like change_php_version. No exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for a server by name (partial match). Returns matching servers with their sites.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions partial match and returns with sites, but lacks details on limitations, pagination, or performance. Adequate but 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?
Extremely concise, one sentence, front-loaded with action. No wasted words.
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?
Output schema exists (though not detailed), and the description covers the basic behavior. Lacks error cases or rate limits, but sufficient for a simple search tool.
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 has 0% description coverage. Description says 'by name' which adds minimal meaning but does not explain format, matching rules, or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action 'Search for a server by name' with partial match behavior, and specifies the return value 'matching servers with their sites'. Distinguishes from siblings like 'list_servers' and 'get_server'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Siblings like 'list_servers' and 'get_server' exist but are not mentioned. Missing explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for a site by domain name (partial match).
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 mentions 'partial match' but does not disclose other behaviors such as whether multiple results are returned, pagination, or performance implications.
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?
Extremely concise with one sentence that front-loads the key information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one parameter and an output schema, the description is minimally adequate. However, it lacks details about search behavior (e.g., case sensitivity, wildcards) and does not leverage the output schema 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?
The schema coverage is 0%, but the description adds meaning by specifying the parameter 'domain' is for a partial match. However, it does not provide additional details like format or constraints beyond what the schema indicates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'search', the resource 'site', and the constraint 'by domain name (partial match)'. It effectively distinguishes from siblings like 'list_sites' and 'search_server'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description implies usage for partial domain name searches but does not specify when to prefer this over 'list_sites' or other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Toggle WordPress debug mode for a site.
| Name | Required | Description | Default |
|---|---|---|---|
| site_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states the basic action without mentioning side effects, permission requirements, or whether toggling is reversible. Fails to add meaningful context.
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 at 6 words, but sacrifices completeness. While no words are wasted, it misses critical details that could fit in a few more sentences. Needs more content to be useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (1 param, simple action) and presence of output schema, the description is at the lower bound of adequacy. It lacks context about what debug mode entails and what the toggle does (enable vs disable).
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 0%, and the description does not explain the required parameter 'site_id'. The parameter name is self-explanatory, but the description adds no additional value beyond what the schema minimally provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Toggle' and resource 'WordPress debug mode' with scope 'for a site'. It is specific and distinct from siblings, all of which involve 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 implies usage when toggling debug mode on a WordPress site, but provides no guidance on when to use this tool vs alternatives (e.g., toggling cache or SSL). No explicit when-not or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Toggle Nginx caching for a site.
| Name | Required | Description | Default |
|---|---|---|---|
| site_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior, but it only says 'Toggle Nginx caching' without explaining what toggling entails (enable/disable? side effects? reversibility?).
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 unnecessary words, making it concise. However, it is so brief that it sacrifices informative content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter and an output schema, the description lacks essential details such as what toggling means, expected states, or any behavioral context beyond the name. The sibling context isn't leveraged.
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 0%, and the one required parameter 'site_id' is not described in the description. The schema already provides minimal info, but the description adds no value beyond the name.
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 'Toggle' and the resource 'Nginx caching for a site', which is specific and distinct from sibling tools like 'purge_site_cache' (purge vs toggle).
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 like 'purge_site_cache' or 'toggle_debug'. There are no conditions, exclusions, or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Toggle SSL on/off for a site.
| Name | Required | Description | Default |
|---|---|---|---|
| site_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It reveals the tool mutates SSL state but omits side effects (e.g., downtime, certificate validation) or pre/post conditions.
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 sentence with no wasted words. However, it lacks necessary structure like parameter explanation or usage notes, making it slightly too brief.
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 an output schema, the description is minimally functional but lacks usage guidelines and parameter details. It does not sufficiently support an AI in selecting this tool among siblings.
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 0% for the sole parameter 'site_id'. The description does not explain what site_id represents or how to obtain it, failing to compensate for missing schema descriptions.
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 ('Toggle SSL on/off') and the target ('a site'). It distinguishes from siblings like toggle_debug and toggle_site_cache by specifying the SSL resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., toggle_debug, toggle_site_cache). No prerequisites or context for toggling SSL provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Trigger a manual backup for a site.
| Name | Required | Description | Default |
|---|---|---|---|
| site_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description should disclose behavioral traits. It only states 'trigger' without explaining consequences (e.g., overwriting existing backups, required permissions, or error conditions). This lacks essential transparency.
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, which is short, but it is under-specified. It sacrifices necessary detail for brevity, earning a '2' per calibration (under-specification).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema description, the description is incomplete. It does not explain return values, side effects, or conditions for successful execution.
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 description adds no meaning beyond the schema's parameter name 'site_id'. With 0% schema description coverage, the description should explain the parameter's purpose or constraints, but it does not.
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 'trigger a manual backup' and the target resource 'for a site'. It is specific and distinguishes from sibling tools that focus on cache or server management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, such as other backup methods or scheduling. No prerequisites or context provided.
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.
v0.1.0change_php_versionget_serverget_siteget_sso_linklist_serverslist_sitespurge_site_cacherestart_mysqlrestart_nginxrestart_phpsearch_serversearch_sitetoggle_debugtoggle_site_cachetoggle_ssltrigger_backupScored across 16 tools
Most tools have clearly distinct purposes, but there is slight overlap between list_servers/search_server and list_sites/search_site. However, descriptions clarify the difference (full list vs partial match), so overall ambiguity is low.
All tools follow a consistent verb_noun pattern with lowercase and underscores, e.g., change_php_version, list_servers, toggle_ssl. No mixed conventions or irregularities.
16 tools cover a wide range of server and site management operations without being excessive. Each tool serves a distinct purpose and the count is well-scoped for the domain.
The tool set covers essential operations like server/site info, cache, SSL, PHP, backups, and service restarts. Missing are lifecycle operations (create/delete) and backup status, but the set is sufficient for typical admin tasks.
Build, deploy and manage MaShop e-commerce projects from Claude, Cursor or any MCP client.
Security-first WordPress MCP server. 129 tools for Claude, ChatGPT, Gemini. Free on wp.org.
Secure MCP Server for WordPress connects AI assistants and agents to WordPress with secure, controlled access. It lets AI interact with WordPress through MCP while helping organizations manage access, enforce policies, protect non-human identities (NHI), and require human approval for sensitive actions. Use it to securely connect tools such as ChatGPT, Claude, and Cursor with WordPress. Marketplace Link: https://wordpress.org/plugins/miniorange-secure-mcp-server/ Official website: https://plugins.miniorange.com/mcp-server-ai-policy-enforcement-wordpress
Use AI models for chat, image, and video generation from Claude Code and other MCP hosts.
