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., "@CloudLab MCP Server list my experiments and show their status"
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 (Model Context Protocol) server for managing CloudLab/Emulab experiments. This allows AI assistants like Claude to interact with your CloudLab experiments directly.
Create experiments - Create new experiments from profiles
List experiments - View all your CloudLab experiments
Get experiment details - See detailed status including node states
Reboot nodes - Reboot individual nodes or all nodes in an experiment
Reload/reimage nodes - Reload a node with its disk image
Power cycle nodes - Hard reboot for unresponsive nodes
Extend experiments - Request time extensions
Terminate experiments - Clean up when done
Related MCP server: MLflow MCP Server
Node.js 18+
A CloudLab account with API access
A valid CloudLab JWT token
npm install
npm run buildLog in to CloudLab
Go to your user profile
Navigate to "Download Credentials" or generate an API token
Save the token as cloudlab.jwt
The server looks for your JWT token in these locations (in order):
Path specified in CLOUDLAB_TOKEN_PATH environment variable
cloudlab.jwt in the project directory
~/Downloads/cloudlab.jwt
Important: Never commit your JWT token to version control!
Add to your Claude Desktop configuration (~/Library/Application Support/Claude/claude_desktop_config.json):
{
"mcpServers": {
"cloudlab": {
"command": "node",
"args": ["/path/to/cloudlab-mcp/dist/index.js"]
}
}
}Tool | Description |
| Create a new experiment from a profile |
| List all your experiments |
| Get detailed status of an experiment |
| Reboot a specific node |
| Reboot all nodes in an experiment |
| Reload/reimage a node |
| Power cycle a node (hard reboot) |
| Extend experiment expiration |
| Terminate an experiment |
Variable | Description |
| Custom path to your JWT token file |
| Override the API endpoint (default: |
MIT
Create a new CloudLab experiment from a profile
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | Project name (e.g., 'UCY-CS499-DC') | |
| profile_name | Yes | Profile name (e.g., 'small-lan') | |
| profile_project | Yes | Project that owns the profile (e.g., 'PortalProfiles') | |
| name | No | Optional experiment name (auto-generated if not provided) | |
| bindings | No | Optional profile parameter bindings (e.g., {nodeCount: '2', phystype: 'c220g1'}) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral context. It implies a write operation ('Create') but doesn't disclose critical traits like required permissions, whether creation is idempotent, typical response time, or what happens on failure (e.g., if the profile doesn't exist).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. Every element ('new CloudLab experiment from a profile') directly contributes to understanding the tool's function.
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 creation tool with 5 parameters, no annotations, and no output schema, the description is inadequate. It doesn't cover behavioral aspects (e.g., what the tool returns, error conditions), usage context, or compensate for the lack of structured metadata, leaving significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds no additional meaning about parameters beyond what's in the schema (e.g., it doesn't explain relationships between 'profile_project' and 'project', or typical 'bindings' values).
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 ('new CloudLab experiment from a profile'), making the purpose immediately understandable. It distinguishes from siblings like 'get_experiment' or 'terminate_experiment' by specifying creation, though it doesn't explicitly differentiate from 'extend_experiment' which also modifies experiments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing project or profile), when not to use it (e.g., for modifying existing experiments), or refer to sibling tools like 'extend_experiment' for updates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extend the expiration time of an experiment
| Name | Required | Description | Default |
|---|---|---|---|
| experiment_id | Yes | Experiment UUID (from list_experiments) | |
| hours | Yes | Number of hours to extend |
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 states the action ('Extend') but doesn't describe what happens upon execution—e.g., whether it's idempotent, requires specific permissions, has rate limits, returns a confirmation or updated experiment object, or affects experiment status. For a mutation tool with zero annotation coverage, this is a significant gap 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, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and resource, making it easy to parse. Every word earns its place, and there's no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a mutation tool (extending an experiment's expiration) with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects like side effects, error conditions, or return values, leaving gaps for an AI agent to understand how to use it correctly. The description should do more to compensate for the lack of structured data.
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%, with both parameters ('experiment_id' and 'hours') fully documented in the input schema. The description doesn't add any meaning beyond what the schema provides—it doesn't explain parameter interactions, constraints (e.g., 'hours' must be positive), or default behaviors. Baseline 3 is appropriate when the schema does the heavy lifting.
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 ('Extend') and the target resource ('expiration time of an experiment'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from potential alternatives like 'renew_experiment' or 'update_experiment_expiry', though no such siblings exist in the provided list. The purpose is unambiguous but lacks sibling 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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., the experiment must be active or not yet expired), exclusions (e.g., cannot extend beyond a maximum limit), or related tools like 'terminate_experiment' for ending experiments. Usage is implied only by the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed status of a specific experiment including node states
| Name | Required | Description | Default |
|---|---|---|---|
| experiment_id | Yes | Experiment UUID (from list_experiments) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a read operation ('Get'), implying it's non-destructive, but doesn't cover aspects like authentication needs, rate limits, error handling, or what 'detailed status' includes (e.g., format, timestamps). For a tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Get detailed status of a specific experiment') and adds a key detail ('including node states') without waste. Every word earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (read operation with one parameter) and no annotations or output schema, the description is minimally complete. It covers the basic purpose but lacks details on behavior, usage context, and return values, leaving gaps that could hinder effective agent 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?
The input schema has 100% description coverage, with 'experiment_id' documented as 'Experiment UUID (from list_experiments)'. The description adds no additional parameter semantics beyond this, such as format details or constraints. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'detailed status of a specific experiment including node states', which specifies what the tool does. It distinguishes from siblings like 'list_experiments' by focusing on a single experiment's details rather than listing multiple. However, it doesn't explicitly contrast with all siblings (e.g., 'create_experiment'), so it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an experiment_id from 'list_experiments'), exclusions, or compare to other read operations. This leaves the agent with minimal context for tool selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all your CloudLab experiments
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool lists experiments but doesn't describe output format, pagination, permissions needed, or other behavioral traits like rate limits 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, efficient sentence with no wasted words, clearly front-loading the purpose. It's appropriately sized for a simple tool.
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 no parameters and no output schema, the description is minimally adequate. However, without annotations or output details, it lacks completeness in explaining what the list includes or how results are structured.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the schema description coverage is 100%, so no parameter information is needed. The description doesn't add param semantics, but this is acceptable given the lack of parameters, aligning with the baseline for 0 params.
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 ('CloudLab experiments'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'get_experiment' which might retrieve a specific experiment, so it doesn't reach the highest score.
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 'get_experiment' for retrieving a single experiment. The description implies usage for listing all experiments but lacks 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.
Power cycle a node (hard reboot)
| Name | Required | Description | Default |
|---|---|---|---|
| experiment_id | Yes | Experiment UUID (from list_experiments) | |
| node | Yes | Node client_id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the action without behavioral details. It doesn't disclose potential impacts (e.g., service interruption, data loss), permissions required, rate limits, or what happens if the node is unavailable. 'Hard reboot' implies forceful restart but lacks operational 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, efficient sentence with zero waste. It is front-loaded with the core action and resource, and the parenthetical 'hard reboot' adds useful clarification without verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool like power cycling with no annotations and no output schema, the description is insufficient. It doesn't cover behavioral risks, success/failure outcomes, or integration with sibling tools (e.g., relationship to 'list_experiments' for getting experiment_id). More context is needed given the tool's potential impact.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters ('experiment_id' and 'node') adequately. The description adds no additional parameter semantics beyond implying the node is part of an experiment, which is already suggested by the schema. Baseline 3 is appropriate when schema does the heavy lifting.
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 specific action ('power cycle') and resource ('a node'), with 'hard reboot' providing additional technical clarification. It distinguishes from siblings like 'reboot_node' (likely soft reboot) and 'reboot_all_nodes' (multiple nodes).
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 'reboot_node' or 'reload_node'. The description doesn't mention prerequisites, dependencies, or scenarios where a hard reboot is preferred over other options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reboot all nodes in an experiment
| Name | Required | Description | Default |
|---|---|---|---|
| experiment_id | Yes | Experiment UUID (from list_experiments) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but provides minimal behavioral insight. It mentions 'reboot' but doesn't clarify if this is destructive (e.g., interrupts processes), requires specific permissions, has side effects, or details response behavior (e.g., success/failure indicators). This is inadequate for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It is front-loaded with the core action and target, making it highly concise and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation affecting multiple nodes), lack of annotations, and no output schema, the description is incomplete. It fails to address critical aspects like safety, permissions, or expected outcomes, leaving significant gaps for an agent to use 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?
Schema description coverage is 100%, so the schema already documents the 'experiment_id' parameter fully. The description adds no additional meaning beyond implying the parameter's role in targeting nodes, aligning with the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('reboot') and target ('all nodes in an experiment'), making the purpose immediately understandable. It distinguishes from sibling tools like 'reboot_node' (singular) and 'powercycle_node' (different action), though it doesn't explicitly contrast them.
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 'reboot_node' for individual nodes or 'reload_node' for a different action. The description lacks context about prerequisites (e.g., experiment state) or exclusions, leaving usage ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reboot a specific node in an experiment
| Name | Required | Description | Default |
|---|---|---|---|
| experiment_id | Yes | Experiment UUID (from list_experiments) | |
| node | Yes | Node client_id (e.g., 'node0') |
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 states the action ('Reboot') but does not explain what 'reboot' entails (e.g., graceful restart vs. forced, downtime implications, permissions required, or side effects). For a mutation tool with zero annotation coverage, this is a significant gap 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, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, with zero waste, making it easy for an agent to parse quickly.
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 complexity (a mutation operation with potential side effects), lack of annotations, and no output schema, the description is incomplete. It does not cover behavioral aspects like what happens during the reboot, error conditions, or return values, leaving critical gaps for an agent to use the tool effectively.
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%, with clear descriptions for both parameters (experiment_id and node). The description does not add any additional meaning beyond what the schema provides, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate as the schema handles the heavy lifting.
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 target ('a specific node in an experiment'), providing a specific verb+resource combination. However, it does not explicitly differentiate from sibling tools like 'reboot_all_nodes' (which reboots all nodes) or 'powercycle_node' (which might have different behavior), leaving some ambiguity in sibling 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 provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., needing an experiment ID from 'list_experiments'), exclusions (e.g., when not to reboot), or comparisons to siblings like 'reboot_all_nodes' or 'powercycle_node', leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reload/reimage a node with its disk image
| Name | Required | Description | Default |
|---|---|---|---|
| experiment_id | Yes | Experiment UUID (from list_experiments) | |
| node | Yes | Node client_id |
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 mentions 'Reload/reimage', implying a potentially destructive or resetting operation, but doesn't specify permissions needed, whether data is lost, or other behavioral traits like rate limits or response 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?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and appropriately sized for its function.
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 complexity of a reload/reimage operation (likely destructive), no annotations, and no output schema, the description is incomplete. It lacks critical behavioral details like safety warnings, expected outcomes, or error handling, making it inadequate for informed use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear documentation for 'experiment_id' and 'node'. The description doesn't add any semantic details beyond what the schema provides, such as explaining the relationship between these parameters or their impact on the reload operation.
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 ('Reload/reimage') and the resource ('a node with its disk image'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'reboot_node' or 'powercycle_node', which likely perform different operations on nodes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'reboot_node' or 'powercycle_node', nor does it mention prerequisites or context. It's a basic statement of function without usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Terminate an experiment (WARNING: destroys all data)
| Name | Required | Description | Default |
|---|---|---|---|
| experiment_id | Yes | Experiment UUID (from list_experiments) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively communicates the destructive nature ('destroys all data'), which is crucial for a mutation tool. However, it lacks details on permissions, reversibility, or response behavior, leaving some 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 extremely concise and front-loaded, consisting of a single sentence that directly states the purpose and includes a critical warning. Every word earns its place, with no unnecessary information or redundancy.
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 complexity (destructive mutation) and lack of annotations or output schema, the description is minimally adequate. It covers the core action and warning but omits details like error handling, confirmation steps, or return values, which could enhance completeness for such a high-stakes 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?
The schema description coverage is 100%, with the parameter 'experiment_id' fully documented in the schema. The description does not add any additional meaning or context beyond what the schema provides, such as format examples or usage tips, so it meets 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 clearly states the specific action ('Terminate') and the resource ('an experiment'), distinguishing it from siblings like create_experiment, extend_experiment, get_experiment, and list_experiments. It uses a precise verb that indicates a destructive operation, which is distinct from the read operations (get, list) and other maintenance actions (powercycle, reboot, reload).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage through the warning 'destroys all data', implying this tool should be used when permanent deletion is intended. However, it does not explicitly state when not to use it (e.g., vs. extend_experiment for modifications) or name specific alternatives, which prevents a score of 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0create_experimentextend_experimentget_experimentlist_experimentspowercycle_nodereboot_all_nodesreboot_nodereload_nodeterminate_experimentEach tool has a clearly distinct purpose with no ambiguity. The tools cover different actions on experiments (create, get, list, extend, terminate) and nodes (powercycle, reboot, reload), with clear boundaries between them. An agent can easily tell them apart based on their specific functions.
All tools follow a consistent verb_noun naming pattern throughout. The verbs are clear and descriptive (e.g., create_experiment, reboot_node), and the nouns consistently specify the target resource (experiment or node). There are no deviations in style or convention.
With 9 tools, the count is well-scoped for managing CloudLab experiments and nodes. Each tool earns its place by covering essential operations like lifecycle management (create, terminate), status retrieval (get, list), and node control (reboot, reload). This is neither too sparse nor overwhelming for the domain.
The tool set provides strong coverage for the CloudLab domain, including CRUD-like operations for experiments (create, get, list, terminate) and comprehensive node management (reboot, powercycle, reload). A minor gap is the lack of tools for modifying experiment configurations or profiles after creation, but agents can work around this by recreating experiments if needed.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Provides capabilities that let LLM agents perform a range of infrastructure management tasks.
Manage Rackspace Spot Kubernetes Cloudspaces, node pools, and VMs from your AI assistant.
Discover, preview, estimate, run, and retrieve reusable AI workflows.
Run A/B experiments through your AI assistant. SDKs for Ruby, Python, JS, Node, React Native, Go.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ArdaGurcan/cloudlab-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
