Cluster Execution MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CLUSTER_DNS | No | DNS server for IP detection | 8.8.8.8 |
| CLUSTER_GATEWAY | No | Gateway IP for route detection | 192.168.1.1 |
| CLUSTER_SSH_USER | No | SSH username for remote execution | marc |
| AGENTIC_SYSTEM_PATH | No | Base path for databases | /mnt/agentic-system |
| CLUSTER_CMD_TIMEOUT | No | Command execution timeout (seconds) | 300 |
| CLUSTER_MACPRO51_IP | No | Mac Pro fallback IP | 192.168.1.183 |
| CLUSTER_SSH_RETRIES | No | Number of SSH retry attempts | 2 |
| CLUSTER_SSH_TIMEOUT | No | SSH connection timeout (seconds) | 5 |
| CLUSTER_INFERENCE_IP | No | Inference node fallback IP | 192.168.1.186 |
| CLUSTER_IP_CACHE_TTL | No | IP resolution cache TTL (seconds) | 300 |
| CLUSTER_MACSTUDIO_IP | No | Mac Studio fallback IP | 192.168.1.16 |
| CLUSTER_CPU_THRESHOLD | No | CPU usage % threshold for offloading | 40 |
| CLUSTER_MACBOOKAIR_IP | No | MacBook Air fallback IP | 192.168.1.172 |
| CLUSTER_MACPRO51_HOST | No | Mac Pro hostname | macpro51.local |
| CLUSTER_INFERENCE_HOST | No | Inference node hostname | completeu-server.local |
| CLUSTER_LOAD_THRESHOLD | No | Load average threshold for offloading | 4 |
| CLUSTER_MACSTUDIO_HOST | No | Mac Studio hostname | Marcs-Mac-Studio.local |
| CLUSTER_STATUS_TIMEOUT | No | Status check timeout (seconds) | 5 |
| CLUSTER_MACBOOKAIR_HOST | No | MacBook Air hostname | Marcs-MacBook-Air.local |
| CLUSTER_MEMORY_THRESHOLD | No | Memory usage % threshold for offloading | 80 |
| CLUSTER_SSH_CONNECT_TIMEOUT | No | Initial SSH connect timeout (seconds) | 2 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| cluster_bashA | Execute bash command with automatic cluster routing. Commands are automatically routed to optimal nodes based on:
Heavy commands (make, cargo, pytest, docker, etc.) are automatically offloaded. Simple commands (ls, cat, echo) run locally for speed. Parameters:
Returns execution result with node info and output. |
| cluster_statusA | Get current cluster status and load distribution. Shows real-time metrics for all cluster nodes:
Use this to:
Returns JSON with status for each node. |
| offload_toA | Explicitly route command to specific cluster node. Use when you need to:
Available nodes:
Parameters:
Returns execution result from specified node. |
| parallel_executeA | Execute multiple commands in parallel across cluster. Distributes commands across available nodes for maximum parallelism. Use for:
Commands are automatically distributed based on node availability and load. Parameters:
Returns list of results, one per command, with execution details. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
Each tool has a clearly distinct purpose: cluster_bash for general command execution, cluster_status for monitoring, offload_to for explicit routing to a node, and parallel_execute for batch execution. There is no overlap in functionality.
Tool names follow mixed conventions: cluster_bash and cluster_status share a prefix, but offload_to and parallel_execute use verb phrases without the prefix. The naming patterns are inconsistent, making it harder to infer the pattern at a glance.
With 4 tools, the server is lean but covers the core functions of cluster execution. It could benefit from a dedicated node listing tool, but the count is appropriate for its scope.
The tool set covers the key operations: executing commands, getting status, explicit routing, and parallel execution. Minor gaps like the absence of a tool to list available nodes dynamically are present but do not severely hinder typical workflows.