runloop-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| RUNLOOP_API_KEY | Yes | Your Runloop API key. Get one at https://app.runloop.ai |
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": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| create_devboxB | Create a new Runloop Devbox. |
| list_devboxesB | List devboxes on the account. |
| get_devboxA | Retrieve details for a single devbox by id. |
| update_devboxA | Update a devbox's name and/or metadata. |
| suspend_devboxA | Suspend a devbox, preserving its disk state. In-memory state (running processes, env vars) is lost; restart background processes after resuming. |
| resume_devboxA | Resume a suspended devbox. |
| shutdown_devboxA | Shut down (delete) a devbox and release its resources. |
| execute_commandA | Execute a command on a devbox and block until it completes. Each call spawns an isolated shell by default - env vars and CWD do not
persist between calls. Pass the same |
| execute_command_asyncA | Start a command on a devbox and return immediately. Use this for long-running or background processes (servers, watchers). The
returned |
| write_fileA | Create or overwrite a file on a devbox. Use this to write new files or edit existing ones (the full contents are written atomically). |
| read_fileB | Read the contents of a file on a devbox. |
| create_snapshotA | Create a disk snapshot of a devbox's current state. Snapshots persist and accrue storage charges until explicitly deleted.
A new devbox can later be created from the snapshot via |
| list_snapshotsA | List disk snapshots, optionally filtered to a devbox. |
| pty_connectA | Create or reconnect to an interactive PTY session on a devbox. Reusing the same |
| pty_send_commandA | Send a command to an interactive PTY session and capture its output. Creates the session if it does not exist (or reconnects if it does), opens
the WebSocket data plane, writes the command, and reads output until the
terminal is quiet for Prefer |
| pty_controlA | Control an existing PTY session: resize, signal, or close. |
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 16 tools
Each tool maps to a distinct resource and action. The three command execution tools are clearly differentiated by blocking vs async vs interactive PTY, and the PTY tools have separate connect/send/control roles. No two tools appear to do the same thing.
All tools follow a consistent verb_noun pattern (e.g., create_devbox, list_devboxes, write_file, pty_connect). The PTY tools use a common pty_ prefix, and the async variant uses a clear _async suffix.
16 tools cover the devbox lifecycle, file operations, snapshots, and PTY interactivity without redundancy. Even though slightly above the typical range, each tool serves a distinct purpose and the set feels well-scoped.
Core devbox lifecycle is fully covered (create/get/list/update/suspend/resume/delete). However, there are notable gaps: no way to retrieve results from execute_command_async (no polling/status tool), and no delete operation for snapshots. These are workable but missing.