The Civo MCP Server provides comprehensive management of Civo cloud resources through MCP clients:
Instance Management: Create, list, reboot, shutdown, start, resize, and delete cloud instances with customizable hostname, size, disk image, count, and region.
Disk Images: List available disk images/templates and get detailed information about specific images, filtered by region.
Network Management: List, create, rename, and delete private networks with custom labels.
Kubernetes Management: Create, list, and delete Kubernetes clusters with specified configurations (name, region, network, node count, node size, version), plus list available Kubernetes versions.
Resource Information: List all available instance sizes and regions for resource deployment.
The server includes flexible configuration options with built-in rate limiting and pagination support.
Integrates with the Civo cloud platform API, providing tools for managing cloud instances, networks, disk images, and Kubernetes clusters. Capabilities include creating/managing/resizing instances, network operations, and Kubernetes cluster management.
Enables management of Kubernetes clusters on the Civo platform, including listing available versions, creating new clusters with customizable parameters, and deleting existing clusters.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Civo MCP Server list all my instances in the LON1 region"
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.
An MCP server implementation that integrates with the Civo cloud platform API, providing capabilities to manage cloud instances, networks, and Kubernetes clusters.
Or you can also view the details of each step through this public Amp thread.
Related MCP server: poly-cloud-mcp
Node.js 20 or newer
Claude Desktop, VS Code, Cursor, or any other MCP client
A Civo account with API key
First, install the Civo MCP server with your client. A typical configuration looks like this:
{
"mcpServers": {
"civo": {
"command": "npx",
"args": ["civo-mcp"],
"env": {
"CIVO_API_KEY": "YOUR_API_KEY_HERE"
}
}
}
}You can install the Civo MCP server using the VS Code CLI:
# For VS Code
code --add-mcp '{"name":"civo","command":"npx","args":["civo-mcp"],"env":{"CIVO_API_KEY":"YOUR_API_KEY_HERE"}}'After installation, the Civo MCP server will be available for use with your GitHub Copilot agent in VS Code.
Follow Amp MCP documentation. Use following configuration:
"amp.mcpServers": {
"civo": {
"command": "npx",
"args": ["civo-mcp"],
"env": {
"CIVO_API_KEY": "YOUR_API_KEY_HERE"
}
}
}Use the Claude Code CLI to add the Civo MCP server:
claude mcp add civo npx civo-mcpThen set your API key as an environment variable:
export CIVO_API_KEY="your_api_key_here"Follow the MCP install guide, use following configuration:
{
"mcpServers": {
"civo": {
"command": "npx",
"args": ["civo-mcp"],
"env": {
"CIVO_API_KEY": "YOUR_API_KEY_HERE"
}
}
}
}Go to Cursor Settings → MCP → Add new MCP Server. Name to your liking, use command type with the command npx civo-mcp. You can also verify config or add command like arguments via clicking Edit.
{
"mcpServers": {
"civo": {
"command": "npx",
"args": ["civo-mcp"],
"env": {
"CIVO_API_KEY": "YOUR_API_KEY_HERE"
}
}
}
}Follow Windsurf MCP documentation. Use following configuration:
{
"mcpServers": {
"civo": {
"command": "npx",
"args": ["civo-mcp"],
"env": {
"CIVO_API_KEY": "YOUR_API_KEY_HERE"
}
}
}
}Follow the MCP install guide, use following configuration:
{
"mcpServers": {
"civo": {
"command": "npx",
"args": ["civo-mcp"],
"env": {
"CIVO_API_KEY": "YOUR_API_KEY_HERE"
}
}
}
}Instance Management: Create, manage, resize, start, stop, reboot, and delete cloud instances.
Disk Image Operations: List and get details of available disk images.
Network Management: Create, rename, and delete networks.
Kubernetes Support: Create, list, and delete Kubernetes clusters and list available versions.
Flexible Configuration: Set instance size, region, and other parameters.
Rate Limiting: Built-in rate limiting to prevent API abuse.
create_instance
Create new cloud instances on Civo
Inputs:
hostname (string): Fully qualified domain name
size (string): Instance size (e.g. 'g2.small')
template_id (string): Disk image ID
count (number, optional): Number of instances to create (default: 1)
region (string, optional): Region identifier (default: 'LON1')
list_instances
List all instances on Civo
Inputs:
region (string, optional): Filter by region
page (number, optional): Pagination page (default: 1)
per_page (number, optional): Results per page (default: 20)
reboot_instance
Reboot an existing instance
Inputs:
id (string): Instance ID
region (string): Region identifier
shutdown_instance
Shutdown an existing instance
Inputs:
id (string): Instance ID
region (string): Region identifier
start_instance
Start a stopped instance
Inputs:
id (string): Instance ID
region (string): Region identifier
resize_instance
Resize an existing instance
Inputs:
id (string): Instance ID
size (string): New instance size
region (string): Region identifier
delete_instance
Delete an existing instance
Inputs:
id (string): Instance ID
region (string): Region identifier
list_disk_images
List available disk images on Civo
Inputs:
region (string, optional): Region identifier
get_disk_image
Get details of a specific disk image
Inputs:
id (string): Disk image ID
region (string, optional): Region identifier
list_networks
List all available networks
Inputs: None
create_network
Create a new network
Inputs:
label (string): Network label
region (string, optional): Region identifier
rename_network
Rename an existing network
Inputs:
id (string): Network ID
label (string): New network label
region (string, optional): Region identifier
delete_network
Delete an existing network
Inputs:
id (string): Network ID
region (string): Region identifier
list_kubernetes_clusters
List all Kubernetes clusters
Inputs:
region (string, optional): Filter by region
page (number, optional): Pagination page
per_page (number, optional): Results per page
create_kubernetes_cluster
Create a new Kubernetes cluster
Inputs:
name (string): Cluster name
region (string): Region identifier
network_id (string): Network ID for the cluster
nodes (number): Number of worker nodes
node_size (string): Size of each node
kubernetes_version (string): Kubernetes version
delete_kubernetes_cluster
Delete a Kubernetes cluster
Inputs:
id (string): Cluster ID
region (string): Region identifier
list_kubernetes_versions
List available Kubernetes versions
Inputs: None
list_sizes
List all available instance sizes
Inputs: None
list_regions
List all available regions
Inputs: None
CIVO_API_KEY: Your Civo API Key (required)
NODE_ENV: Set to production to disable debug logging (optional)
Sign up for a Civo account if you don't have one.
Generate your API key following the API keys documentation
Contributions are welcome! Please follow these steps:
Fork the repository
Create a feature branch: git checkout -b feature-name
Make your changes and add tests
Run the test suite: npm run test:ci
Submit a pull request
git clone https://github.com/tao12345666333/civo-mcp.git
cd civo-mcp
npm install
npm run build# Run all tests
npm test
# Run tests in watch mode
npm run test:watch
# Generate coverage report
npm run test:coverageThis MCP server is licensed under the MIT License. See the LICENSE file for details.
Create a new cloud instance on Civo
| Name | Required | Description | Default |
|---|---|---|---|
| hostname | Yes | Fully qualified domain name | |
| size | Yes | Instance size (e.g. g2.small) | |
| template_id | Yes | Disk image ID | |
| count | No | Number of instances to create | |
| region | No | Region identifier | LON1 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits but only states the action; no mention of startup behavior, idempotency, or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise and front-loaded, but omits potentially valuable context; 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?
Lacks detail on return values, side effects, or lifecycle behavior; given no output schema and 5 parameters, the description is insufficient for complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so descriptions for each parameter exist; the tool description adds no extra semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create) and resource (cloud instance) on a specific platform (Civo), differentiating it from siblings like create_kubernetes_cluster.
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., create_kubernetes_cluster) or prerequisites, leaving the agent 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.
Create a new Kubernetes cluster on Civo
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Cluster name | |
| region | Yes | Region identifier | |
| network_id | Yes | Network ID | |
| nodes | Yes | Number of nodes | |
| node_size | Yes | Node size | |
| kubernetes_version | Yes | Kubernetes version |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears full responsibility for disclosing behavioral traits. It only states 'Create' (a write operation) but omits side effects like potential costs, asynchronous provisioning, idempotency, or authorization requirements. This is insufficient for an agent to assess impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It is well front-loaded, immediately stating the action and resource. However, it could be slightly more structured by listing key aspects like required parameters or default behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has six required parameters and no output schema, the description lacks critical context about the cluster creation process, such as expected return values, provisioning time, or error conditions. The agent cannot infer necessary steps like waiting for cluster readiness.
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?
Since the input schema provides descriptions for all six parameters, the description adds no additional semantic value beyond the schema. The baseline score of 3 is appropriate because the description does not further explain parameter formatting, constraints, or interdependencies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and the resource 'Kubernetes cluster on Civo', making the primary action unambiguous. However, it does not distinguish this from sibling tools like 'create_instance' beyond the resource type, and could benefit from specifying that it creates a new managed Kubernetes cluster.
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 usage guidelines are provided. The description does not indicate when to use this tool over alternatives (e.g., create_instance for non-managed clusters), nor does it mention prerequisites or context such as requiring an existing network or region.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new network on Civo
| Name | Required | Description | Default |
|---|---|---|---|
| label | Yes | Network label | |
| region | No | Region identifier |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose behavioral traits such as idempotency, async behavior, or side effects beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise and front-loaded, but lacks additional detail that could be included without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite simple tool with 2 params, lack of usage guidance, output schema, and annotations leaves gaps for an agent to understand full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. Description adds no additional meaning to parameters beyond what schema already 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 'Create a new network on Civo', providing verb and resource, and differentiates from sibling tools like delete_network, list_networks, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. Missing prerequisites or comparison with other creation tools like create_instance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a cloud instance on Civo
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Instance ID | |
| region | Yes | Region identifier |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits like irreversibility or side effects. It only states 'delete', giving no warning about permanent data loss or whether the instance must be stopped first.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence. While very short, it is front-loaded and contains no wasted words, though it could be slightly expanded 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 simple parameters and lack of output schema, the description still omits crucial context like permanence, required instance state, or any side effects. It is not complete enough for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds no extra meaning beyond what the schema already provides (id and region).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Delete', the resource 'cloud instance', and the platform 'Civo'. It distinguishes this tool from siblings like 'reboot_instance' or 'shutdown_instance' since deletion is a permanent action.
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 vs alternatives (e.g., shutdown for temporary stop). There is no mention of prerequisites or caution about permanent data loss.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a Kubernetes cluster on Civo
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Cluster ID | |
| region | Yes | Region identifier |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description lacks details on irreversibility, cascading effects, or required authentication, leaving the AI agent underinformed about behavioral traits.
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 redundant words, efficiently conveying the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks details about return values, deletion effects, or confirmation requirements, making it incomplete for a deletion tool despite clear schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already describes both parameters (id and region) with clear descriptions, so description adds no extra value. Baseline score of 3 applies due to full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Delete a Kubernetes cluster on Civo' with a specific verb and resource, distinguishing it from sibling tools like delete_instance and delete_network.
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, no prerequisites or conditions like cluster state or permissions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a network on Civo
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Network ID | |
| region | No | Region identifier |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states the action is deletion, but does not mention consequences (e.g., whether the network must be empty, if deletion is irreversible, 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 very short (one phrase), but it barely adds value beyond the tool name. It is not structured or front-loaded with key details; the single sentence could be considered under-specified.
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 deletion tool, the description lacks essential context such as whether deletion can be undone, effects on associated resources, or error conditions. No output schema, so return value details are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds no additional meaning beyond what the schema already provides for id and region.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Delete' and the resource 'network on Civo', distinguishing it from sibling delete tools (delete_instance, delete_kubernetes_cluster) which operate on 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?
Provides no guidance on when to use this tool versus alternatives (e.g., rename_network) or under what conditions deletion is appropriate. No prerequisites or cautionary notes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a specific disk image
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Disk image ID | |
| region | No | Region identifier |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavioral traits. It only states 'Get details' without indicating that the operation is read-only, whether authorization is needed, or any side effects. This leaves significant gaps in 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 concise sentence with no superfluous words. It is front-loaded and efficiently communicates the tool's 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 the absence of an output schema, the description should hint at return values, but it only says 'details'. The tool has a sibling list_disk_images, but no guidance is provided on how parameters affect results. This completeness gap keeps it at an adequate but not exceptional level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters with descriptions (100% coverage), so the baseline is 3. The description does not add additional semantics or constraints beyond the schema, thus meeting but not exceeding expectations.
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 'Get details of a specific disk image' clearly states the action (Get) and target (specific disk image), distinguishing it from sibling tools like list_disk_images which retrieves all disk images. This meets the criteria for specific verb+resource and differentiation.
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 you have a specific disk image ID, but it lacks explicit guidance on when to use this versus alternatives like list_disk_images. No context or exclusions are provided, relying on the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available disk images on Civo
| Name | Required | Description | Default |
|---|---|---|---|
| region | No | Region identifier |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation but lacks details on authentication requirements, pagination, or ordering. With no annotations, it provides minimal behavioral context beyond listing.
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, front-loaded sentence with no extraneous information. Every word serves a 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?
For a simple list tool with one optional parameter, the description is adequate but lacks information on return format, default region behavior, or typical usage scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'region', but its description only repeats 'Region identifier'. The tool description adds no extra semantics; baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list) and resource (disk images) with scope (on Civo). It effectively distinguishes from 'get_disk_image' and other list tools.
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. No mention of prerequisites, filtering, or context such as listing images for a specific purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all instances on Civo
| Name | Required | Description | Default |
|---|---|---|---|
| region | No | Filter by region | |
| page | No | Pagination page | |
| per_page | No | Results per page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should convey behavioral traits. It only states 'list all instances' without disclosing whether it is read-only, resource-intensive, or requires specific permissions. The agent lacks essential behavioral cues.
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 (four words) but underspecified. It fits the minimalism but sacrifices necessary detail, making it borderline adequate.
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?
Without an output schema, the description should explain what is returned. It does not mention response format, pagination behavior, or the effect of filtering. The presence of optional pagination parameters is not explained, leaving 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?
All three parameters have descriptions in the input schema (100% coverage), so the schema already documents their meaning. The description adds no additional context beyond what the schema provides, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all instances on Civo' clearly states the verb 'List', the resource 'instances', and the platform. It effectively distinguishes this tool from sibling tools like create_instance, delete_instance, etc., which have different actions.
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 list_disk_images or list_kubernetes_clusters. The description does not mention filtering, pagination, or context for choosing this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Kubernetes clusters on Civo
| Name | Required | Description | Default |
|---|---|---|---|
| region | No | Region identifier |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully convey behavioral traits. It only states a read action ('list') without confirming safety, idempotency, or potential side effects. Additional context like rate limits or pagination is absent.
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 of seven words, efficiently conveying the core purpose without extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool with one optional parameter and no output schema, the description adequately states the primary action but fails to clarify the effect of the region parameter or the output structure, leaving minor 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 coverage for parameters is 100% with 'region' described as 'Region identifier'. The description adds no additional meaning, so baseline score applies per guidelines.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states 'List all Kubernetes clusters on Civo' using a specific verb ('list') and resource ('Kubernetes clusters'), clearly distinguishing it from sibling tools like create_kubernetes_cluster and delete_kubernetes_cluster.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for viewing existing clusters, but offers no explicit guidance on when to use this tool versus alternatives (e.g., when inspecting vs. creating clusters). No exclusions or when-not-to-use advice are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available Kubernetes versions on Civo
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the operation is to list versions, which implies a read-only action, but it does not explicitly confirm non-destructiveness, rate limits, or behavior under error conditions. Minimal but adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It is front-loaded with the key action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description is complete enough. It clearly states what the tool does, which is sufficient for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so the description does not need to add parameter information. Baseline of 4 is appropriate as no param info is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List', the resource 'available Kubernetes versions', and the platform 'on Civo'. It unambiguously distinguishes from sibling tools like 'list_kubernetes_clusters'.
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. It is implied that it should be used before creating a cluster, but no when-not or alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available networks on Civo
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description bears full burden. It only states the action, omitting auth requirements, rate limits, or data freshness. Minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded, no wasted words. Perfectly concise for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool without output schema, the description is adequate but minimal. It could benefit from noting that it returns available networks or any default behavior.
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 no parameter info but is not required. Baseline score of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list), resource (networks), and platform (Civo). It is precise and distinguishes from sibling tools that list 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?
No guidance is provided on when to use this tool versus alternatives. For a simple list tool, implicit differentiation is weak.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available regions on Civo
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description only states 'List available regions' without disclosing read-only nature, potential limitations, or return format.
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 wasted words. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Minimal but adequate for a parameterless list tool. Lacks details about output or behavior, but no output schema exists to supplement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. Description doesn't need to add param info; baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Describes verb 'List' and resource 'available regions on Civo'. Clearly distinguishes from sibling list tools that target different resources like instances or disk images.
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. Lacks context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available instance sizes on Civo
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It does not mention any behavioral traits like pagination, auth requirements, or sorting. For a simple list with no parameters, this is acceptable but could be improved.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence with no wasted words. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no parameters, the description is adequate but could be more informative by detailing the return value (e.g., size names or specs).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters (schema coverage 100%), so the baseline is 4. The description adds no parameter-specific meaning, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists available instance sizes on Civo, with a specific verb and resource. It distinguishes from sibling tools like 'list_instances' and 'create_instance'.
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 or when not to use. However, the tool's simplicity and lack of alternatives for listing sizes make it self-explanatory, so a middle score is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reboot a cloud instance on Civo
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Instance ID | |
| region | Yes | Region identifier |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose side effects, permissions, or behavioral nuances beyond the basic reboot 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?
Single sentence, no wasted words, appropriately 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?
Minimal but sufficient for a simple reboot tool, though lacks usage guidance and behavioral details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions, so baseline is 3; description adds no extra semantic meaning.
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 (reboot) and resource (cloud instance on Civo), distinguishing it from sibling tools like shutdown_instance or start_instance.
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 over alternatives (e.g., shutdown + start) or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rename a network on Civo
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Network ID | |
| label | Yes | New network label | |
| region | No | Region identifier |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits like mutation, permissions, or side effects. It only says 'Rename a network', omitting any behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded, and concise with no wasted words. It is appropriately sized.
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 simple rename operation and no output schema, the description is too minimal. It does not mention constraints like network existence or label uniqueness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions, but the tool description adds no extra meaning beyond what the schema provides. Baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'rename' and the resource 'network' on platform 'Civo', distinguishing it from siblings like create_network and delete_network.
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 prerequisites or when not to use it. The description lacks usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resize a cloud instance on Civo
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Instance ID | |
| size | Yes | New instance size | |
| region | Yes | Region identifier |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It does not disclose side effects like downtime, restarting, or whether changes are reversible. Simply stating 'resize' is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise with a single clear sentence. 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?
Given no output schema and no annotations, the description should provide more context. It omits prerequisites (e.g., instance must exist, should be stopped), return values, and any constraints on the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds no extra meaning beyond the schema parameter descriptions. For instance, 'size' is described as 'New instance size' but no format or valid values are hinted.
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 (resize) and resource (cloud instance on Civo). It is specific and distinguishes from sibling tools like start, stop, or delete.
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. For example, does the instance need to be stopped? No mention of prerequisites or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Shutdown a cloud instance on Civo
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Instance ID | |
| region | Yes | Region identifier |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description does not disclose behavioral traits such as whether the shutdown is graceful, requires confirmation, or has side effects (e.g., data loss). The term 'shutdown' is ambiguous without further 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 a single concise sentence that front-loads the main purpose. However, it could benefit from a brief elaboration on context 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 tool with 2 parameters, no annotations, and no output schema, the description is too minimal. It does not explain return values, side effects, or prerequisites, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already describes both parameters (id and region) sufficiently. The description does not add any additional meaning beyond what is in 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 'Shutdown a cloud instance on Civo' clearly states the action (shutdown) and resource (cloud instance), and distinguishes from sibling tools like start_instance, reboot_instance, and delete_instance.
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., delete_instance). No prerequisites (e.g., instance must be running) or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a cloud instance on Civo
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Instance ID | |
| region | Yes | Region identifier |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description lacks behavioral details such as state change, idempotency, prerequisites, or potential errors. Burdens the agent to infer 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?
Single sentence is concise but too brief; lacks essential details while being acceptably front-loaded. Could include more context without sacrificing 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?
No output schema, and description omits expected return value, side effects, or usage nuances. Incomplete for an action tool with no additional structured fields.
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 100% description coverage for both parameters, so description adds no extra meaning beyond schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Start') and the resource ('cloud instance on Civo'), distinguishing it from siblings like shutdown_instance (stop) and create_instance (provision).
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 (e.g., requires instance to exist, opposite of shutdown_instance). Absence of usage context limits correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct resource-action pair: instances, Kubernetes clusters, networks, disk images, and metadata. No overlaps exist, as operations like create, list, delete, and specific actions (reboot, resize) are clearly separated.
All tools follow a consistent verb_noun pattern with snake_case (e.g., create_instance, list_networks). No deviations or mixed conventions, making the pattern predictable.
19 tools cover multiple resource types (instances, clusters, networks, disk images, metadata) without being excessive. While slightly above the typical 3-15 range, the count is justified given the scope.
Basic CRUD and lifecycle operations exist for instances, clusters, and networks, but notable gaps include missing get_instance, get_kubernetes_cluster, update_instance (except resize), and no support for volumes, firewalls, or advanced cluster management.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
An MCP server that let you interact with Cycloid.io Internal Development Portal and Platform
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
MCP server for interacting with the Supabase platform
A MCP server built for developers enabling Git based project management with project and personal…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/tao12345666333/civo-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
