Last Rock MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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
Server capabilities have not been inspected yet.
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| deploy_mcp_serverA | Deploy MCP server to Fly.io with state tracking, locks, and health checks. DO NOT use ssh_exec for deployments - always use this tool instead. |
| deploy_cloudflare_workerA | Deploy Cloudflare Worker with state tracking and health checks. DO NOT use ssh_exec('wrangler deploy') - always use this tool instead. |
| restart_serviceA | Restart a service with pre/post health checks and automatic rollback. DO NOT use ssh_exec('docker restart') - always use this tool instead. |
| check_services_healthB | Check health of one or more services. Safe read-only operation. |
| trigger_auto_recoveryB | Trigger automatic recovery for a failed service using predefined playbooks. |
| get_infrastructure_statusA | Get comprehensive overview of entire infrastructure. Safe read-only operation. |
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 6 tools
Each tool has a clearly distinct purpose with no overlap: health checking, two specific deployment tools (Cloudflare Worker and MCP server), infrastructure status overview, service restart, and auto-recovery. The descriptions reinforce distinct domains (deployment vs. operations vs. monitoring).
Tools follow a consistent verb_noun pattern (e.g., check_services_health, deploy_cloudflare_worker) with clear action-object naming. The only minor deviation is 'get_infrastructure_status' which uses 'get' instead of 'check' like the health tool, but the pattern remains readable and predictable.
Six tools is well-scoped for infrastructure management, covering deployment, monitoring, and recovery workflows. Each tool earns its place with no redundancy, and the count aligns with typical server ranges (3-15 tools) for this domain.
The toolset provides strong coverage for infrastructure lifecycle: deployment (two tools), health monitoring, status overview, restart, and recovery. A minor gap exists in lacking update/delete operations for deployed resources, but core workflows are well-covered with safe alternatives to raw SSH commands.