The Sprite MCP Server enables comprehensive management of Sprite VMs through an MCP-compatible client like Claude, with interactive UI dashboards for visual management.
List & Manage VMs – View all Sprite VMs via an interactive visual dashboard, create new VMs by name, and destroy existing ones (with a required confirmation flag for safety)
Execute Commands – Run shell commands on remote Sprite VMs via a terminal UI with command history and configurable timeouts
Checkpoint Management – Create filesystem snapshots (with optional comments), list existing checkpoints, and restore a VM to a previous checkpoint state
File Transfer – Upload local files to a Sprite VM (push_file) or download files from a Sprite VM to local storage (fetch_file)
Session Management – List all active sessions running on a specific Sprite VM
Get VM URL – Retrieve the public URL for a specific Sprite VM
Interactive UIs – Visual dashboard and terminal interfaces integrate directly into Claude conversations for a seamless management experience
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., "@Sprite MCP Server show my active sprites and open the interactive dashboard"
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.
MCP server for managing Sprite VMs with interactive UI dashboards (MCP Apps).
Works with Claude.ai, Claude Desktop, Claude Code, VS Code, and any MCP-compatible client.
List & manage Sprite VMs - Interactive dashboard with status indicators
Execute commands - Terminal UI with command history
Checkpoints - Create, list, restore filesystem snapshots
File transfer - Push/pull files to/from remote sprites
Session management - List, attach, kill sessions
Related MCP server: MCP VPS Manager
Node.js 20+ - Download from nodejs.org
Git - Download from git-scm.com
Sprite CLI - Get your token from sprites.dev
Download and install the Sprite CLI for Windows:
# Using PowerShell (run as Administrator)
irm https://sprites.dev/install.ps1 | iexOr download manually from sprites.dev/downloads.
Get your API token from the Sprites dashboard, then:
# Authenticate with your token
sprite auth setup --token "your-org/org-id/token-id/token-value"
# Or use interactive login (opens browser)
sprite loginVerify it works:
sprite list# Clone the repository
git clone https://github.com/Anansitrading/sprite-mcp-server.git
cd sprite-mcp-server
# Install dependencies
npm install
# Build the server
npm run build# Find where sprite is installed
where spriteThis typically returns something like:
C:\Users\YourName\.local\bin\sprite.exe
C:\Users\YourName\AppData\Local\Programs\sprite\sprite.exe
Note this path - you'll need it for configuration.
Edit your Claude Desktop config file:
Location: %APPDATA%\Claude\claude_desktop_config.json
Open it with:
notepad "$env:APPDATA\Claude\claude_desktop_config.json"Add this configuration (replace paths with your actual paths):
{
"mcpServers": {
"sprite": {
"command": "node",
"args": ["C:\\Users\\YourName\\sprite-mcp-server\\dist\\index.js"],
"env": {
"SPRITE_BIN": "C:\\Users\\YourName\\.local\\bin\\sprite.exe"
}
}
}
}Important: Use double backslashes (\\) in paths or forward slashes (/).
Fully quit Claude Desktop (check system tray)
Reopen Claude Desktop
Look for the hammer icon (🔨) indicating MCP tools are available
Ask Claude:
"List my sprites"
"Execute ls -la on my sprite"
"Create a checkpoint"
For Claude Code CLI, add to your settings:
# Open Claude Code settings
claude mcp add sprite -- node "C:\Users\YourName\sprite-mcp-server\dist\index.js"Or edit ~/.claude/settings.json:
{
"mcpServers": {
"sprite": {
"command": "node",
"args": ["C:\\Users\\YourName\\sprite-mcp-server\\dist\\index.js"],
"env": {
"SPRITE_BIN": "C:\\Users\\YourName\\.local\\bin\\sprite.exe"
}
}
}
}Node.js 20+
Sprite CLI configured with credentials
# Clone & build
git clone https://github.com/Anansitrading/sprite-mcp-server.git
cd sprite-mcp-server
npm install
npm run build
# Authenticate with Sprite
sprite login
# or
sprite auth setup --token "your-token"
# Test
sprite listmacOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Linux: ~/.config/Claude/claude_desktop_config.json
{
"mcpServers": {
"sprite": {
"command": "node",
"args": ["/path/to/sprite-mcp-server/dist/index.js"],
"env": {
"SPRITE_BIN": "/home/youruser/.local/bin/sprite"
}
}
}
}claude mcp add sprite -- node /path/to/sprite-mcp-server/dist/index.jsFor hosting your own MCP server accessible from claude.ai:
Node.js 20+
A domain pointing to your server (for HTTPS)
Caddy or nginx for reverse proxy
# Clone & build
git clone https://github.com/Anansitrading/sprite-mcp-server.git
cd sprite-mcp-server
npm install
npm run build
# Configure
cp .env.example .env
# Edit .env:
# PORT=3847
# SPRITE_BIN=/home/sprite/.local/bin/sprite
# Run with systemd
sudo cp sprite-mcp.service /etc/systemd/system/
sudo systemctl daemon-reload
sudo systemctl enable sprite-mcp
sudo systemctl start sprite-mcpmcp.yourdomain.com {
reverse_proxy localhost:3847
}Add MCP Server:
Name: sprite-mcp
URL: https://mcp.yourdomain.com/sse
Test by asking Claude: "List my sprites"
Tool | Description |
| List all Sprite VMs (with interactive dashboard) |
| Execute command on a sprite (with terminal UI) |
| Create filesystem snapshot |
| List available checkpoints |
| Restore to a checkpoint |
| Get sprite's public URL |
| Download file from sprite |
| Upload file to sprite |
| List active sessions |
| Create new sprite VM |
| Delete a sprite VM |
This server uses MCP Apps to provide interactive interfaces:
Dashboard (ui://sprite/dashboard) - Visual sprite management
Terminal (ui://sprite/terminal) - Command execution interface
These render directly in the Claude conversation when using supported clients.
Add Sprite to your PATH or use the full path in SPRITE_BIN:
# Find sprite location
where sprite
# Add to PATH (PowerShell, run as admin)
$env:Path += ";C:\Users\YourName\.local\bin"
[Environment]::SetEnvironmentVariable("Path", $env:Path, [EnvironmentVariableTarget]::User)Ensure all paths use double backslashes or forward slashes
Verify the dist/index.js file exists (run npm run build first)
Check that SPRITE_BIN points to the actual .exe file
# Re-authenticate
sprite login
# Or with token
sprite auth setup --token "your-token"
# Verify
sprite list# If running HTTP server
curl http://localhost:3847/healthecho '{"jsonrpc":"2.0","method":"tools/list","params":{},"id":1}' | npm start┌─────────────────────────────────────────────────────────┐
│ Claude.ai / Desktop │
├─────────────────────────────────────────────────────────┤
│ MCP Protocol │
│ (stdio or HTTP/SSE transport) │
├─────────────────────────────────────────────────────────┤
│ sprite-mcp-server │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────────┐ │
│ │ MCP Tools │ │ UI Resources│ │ Sprite CLI │ │
│ │ (11 tools) │ │ (Dashboard) │ │ Integration │ │
│ └─────────────┘ └─────────────┘ └─────────────────┘ │
├─────────────────────────────────────────────────────────┤
│ Sprite CLI │
│ (sprite list, exec, checkpoint...) │
├─────────────────────────────────────────────────────────┤
│ Sprites API / VMs │
└─────────────────────────────────────────────────────────┘MIT
Create a filesystem checkpoint/snapshot of a Sprite VM for quick restore
| Name | Required | Description | Default |
|---|---|---|---|
| sprite | Yes | Name of the sprite to checkpoint | |
| comment | No | Optional comment describing the checkpoint | |
| org | No | Organization name (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions creating a checkpoint for restoration, which implies a write operation, but does not disclose behavioral traits such as whether it overwrites existing checkpoints, requires specific permissions, has side effects, or details about the snapshot process (e.g., performance impact). This leaves significant gaps 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 that front-loads the key information ('Create a filesystem checkpoint/snapshot') and adds purpose ('for quick restore') without unnecessary words. Every part 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 complexity of a mutation tool (creating checkpoints) with no annotations and no output schema, the description is incomplete. It lacks details on what the tool returns, error conditions, or how the checkpoint integrates with other tools like 'restore_checkpoint'. For a tool that modifies state, more context is needed to guide effective 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 schema description coverage is 100%, so the schema already documents all parameters ('sprite', 'comment', 'org') with descriptions. The description does not add any additional meaning or context beyond what the schema provides, such as explaining how 'sprite' relates to VMs or the format of 'comment'. Baseline 3 is appropriate when the schema handles parameter documentation.
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 ('Create a filesystem checkpoint/snapshot') and the target resource ('Sprite VM'), distinguishing it from siblings like 'restore_checkpoint' (which reverses this action) and 'list_checkpoints' (which only reads). It uses precise terminology like 'for quick restore' to clarify the purpose.
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 by mentioning 'for quick restore,' suggesting it should be used when you need to save VM state for later recovery. However, it does not explicitly state when to use this tool versus alternatives like 'list_checkpoints' or 'restore_checkpoint,' nor does it provide exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new Sprite VM
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name for the new sprite | |
| org | No | Organization name (optional) |
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. 'Create' implies a write operation, but the description doesn't mention permissions, side effects, error conditions, or what 'Sprite VM' entails. This is inadequate for a mutation tool with zero annotation coverage.
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's front-loaded with the core action and resource, making it easy to parse quickly without unnecessary elaboration.
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 no annotations and no output schema, the description is insufficient. It lacks details on what a 'Sprite VM' is, the creation process, expected outputs, or error handling, leaving significant gaps in understanding 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?
The schema description coverage is 100%, with both parameters ('name' and 'org') documented in the schema. The description adds no additional meaning beyond what the schema provides, such as format examples or constraints, so it meets 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 ('Create') and the resource ('new Sprite VM'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its siblings like 'destroy_sprite' or 'list_sprites' beyond the basic verb, which prevents a perfect 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?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'list_sprites' and 'destroy_sprite', there's no indication of prerequisites, typical workflows, or when not to use it, 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.
Destroy/delete a Sprite VM (requires confirmation)
| Name | Required | Description | Default |
|---|---|---|---|
| sprite | Yes | Name of the sprite to destroy | |
| confirm | Yes | Must be true to confirm destruction | |
| org | No | Organization name (optional) |
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 adds value by indicating the destructive nature ('Destroy/delete') and the confirmation requirement, which are crucial for safe usage. However, it lacks details on permissions, rate limits, or what happens post-deletion, leaving some behavioral aspects unclear.
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 tool's purpose and key requirement. Every word earns its place, with no unnecessary details or redundancy, making it highly efficient for quick comprehension.
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 as a destructive operation with no annotations and no output schema, the description is minimally adequate. It covers the basic action and confirmation need but lacks details on outcomes, error handling, or integration with sibling tools, leaving gaps in contextual understanding for safe and effective 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 schema description coverage is 100%, so the schema already documents all parameters (sprite, confirm, org). The description does not add any additional meaning or context beyond what the schema provides, such as explaining the confirmation process or organizational scope. Thus, it meets the baseline but does not enhance parameter understanding.
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 ('Destroy/delete') and resource ('a Sprite VM'), distinguishing it from sibling tools like create_sprite, list_sprites, or get_sprite_url. It precisely communicates the tool's function without being vague or tautological.
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 by stating 'requires confirmation', which implies this tool should be used cautiously and only when deletion is intended. However, it does not explicitly mention when not to use it or name alternatives like restore_checkpoint for undoing actions, so it falls short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a command on a remote Sprite VM
| Name | Required | Description | Default |
|---|---|---|---|
| sprite | Yes | Name of the sprite to execute the command on | |
| command | Yes | The command to execute | |
| org | No | Organization name (optional) | |
| timeout | No | Command timeout in milliseconds (default: 30000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the action ('Execute a command') but doesn't describe what happens during execution (e.g., synchronous/asynchronous, output capture, error handling), security implications, permission requirements, or rate limits. This leaves significant gaps for a tool that performs remote execution.
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 appropriately sized and front-loaded with the core functionality.
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 remote command execution tool with no annotations and no output schema, the description is inadequate. It doesn't explain what the tool returns (output, errors, status codes), behavioral characteristics, or integration with sibling tools. Given the complexity of remote execution, more context is needed.
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 four parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema, maintaining the baseline score 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 ('Execute a command') and target resource ('on a remote Sprite VM'), providing specific verb+resource pairing. However, it doesn't distinguish this tool from potential alternatives among its siblings (like 'fetch_file' or 'push_file'), which might also involve remote execution aspects.
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. With siblings like 'fetch_file', 'push_file', and various sprite management tools, there's no indication of appropriate contexts, prerequisites, or exclusions for command execution.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download a file from a remote Sprite VM to the local filesystem
| Name | Required | Description | Default |
|---|---|---|---|
| sprite | Yes | Name of the sprite | |
| remote_path | Yes | Path to the file on the remote sprite | |
| local_path | Yes | Local destination path | |
| org | No | Organization name (optional) |
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 download action but does not mention potential side effects (e.g., file overwriting, network usage), authentication needs, error handling, or rate limits. This leaves significant gaps in understanding the tool's behavior beyond the basic operation.
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 front-loaded with the core action and resources, making it easy to understand quickly. Every word earns its place.
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 annotations and no output schema, the description is minimal but covers the basic operation. However, for a tool that performs file operations (potentially involving network and filesystem changes), it lacks details on error conditions, return values, or safety considerations. It is adequate but has clear gaps in completeness.
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. The description does not add any additional meaning or context beyond what the schema provides (e.g., format examples, constraints). Baseline 3 is appropriate as the schema handles parameter documentation adequately.
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 ('Download a file') and resources involved ('from a remote Sprite VM to the local filesystem'), distinguishing it from sibling tools like 'push_file' (which uploads) and 'list_sprites' (which lists). It precisely communicates what the tool does without being vague or tautological.
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 downloading files from a Sprite VM to the local system, but does not explicitly state when to use this tool versus alternatives like 'push_file' for uploading or 'get_sprite_url' for obtaining URLs. It provides basic context but lacks explicit guidance on exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the public URL for a Sprite VM
| Name | Required | Description | Default |
|---|---|---|---|
| sprite | Yes | Name of the sprite | |
| org | No | Organization name (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool gets a public URL, implying a read-only operation, but doesn't disclose behavioral traits such as authentication needs, rate limits, or what 'public' entails (e.g., accessibility, expiration). This leaves gaps in understanding the tool's behavior.
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, direct sentence with zero waste. It front-loads the key action and resource efficiently, making it easy to parse without unnecessary details.
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 low complexity (2 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks context on usage, behavioral details, or output format, which could be important for a tool that retrieves URLs.
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 parameter descriptions ('Name of the sprite', 'Organization name (optional)'). The description adds no additional semantic context beyond this, so it meets the baseline of 3 where 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 ('Get the public URL') and the resource ('for a Sprite VM'), making the purpose immediately understandable. It doesn't explicitly differentiate from siblings like 'list_sprites' or 'fetch_file', but the specific focus on URL retrieval is distinct enough for a 4.
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 example, it doesn't mention if this is for sharing or accessing a sprite, or how it relates to siblings like 'fetch_file' (which might retrieve content) or 'list_sprites' (which lists sprites without URLs).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all checkpoints for a Sprite VM
| Name | Required | Description | Default |
|---|---|---|---|
| sprite | Yes | Name of the sprite | |
| org | No | Organization name (optional) |
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 is to 'List all checkpoints,' which implies a read-only operation, but does not specify details like pagination, rate limits, authentication needs, or what 'all' entails (e.g., completeness, ordering). This leaves significant gaps for a tool with no annotation coverage.
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, making it easy to understand quickly. Every part of the sentence earns its place by conveying essential 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 complexity of listing resources, no annotations, and no output schema, the description is incomplete. It does not explain return values, error conditions, or behavioral traits like how checkpoints are formatted or if there are limitations. For a tool with no structured support, more context is needed to be fully helpful.
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 both parameters ('sprite' and 'org'). The description does not add any meaning beyond what the schema provides, such as explaining parameter interactions or constraints. Since schema coverage is high, 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 ('List all checkpoints') and resource ('for a Sprite VM'), providing a specific verb+resource combination. However, it does not explicitly distinguish this tool from its sibling 'list_sessions' or 'list_sprites', which reduces it from a perfect score. 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, such as 'list_sessions' or 'list_sprites', nor does it mention prerequisites or exclusions. It implies usage by specifying the resource (Sprite VM), but this is minimal context without explicit when/when-not instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List active sessions on a Sprite VM
| Name | Required | Description | Default |
|---|---|---|---|
| sprite | Yes | Name of the sprite | |
| org | No | Organization name (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'active sessions' but doesn't clarify what constitutes 'active', whether this is a read-only operation, if there are rate limits, or what the output format might be. This leaves significant gaps for an agent to understand the tool's behavior.
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 appropriately sized and front-loaded, making it easy 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 lack of annotations and output schema, the description is incomplete for a tool that likely returns a list of sessions. It doesn't explain what information sessions include, how results are structured, or any limitations, leaving the agent with insufficient context 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%, so the schema already documents both parameters ('sprite' and 'org') with descriptions. The description doesn't add any additional meaning beyond what's in the schema, such as explaining the relationship between sprite and sessions or clarifying optionality, meeting 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 verb ('List') and resource ('active sessions on a Sprite VM'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'list_sprites' or 'list_checkpoints' beyond the resource type, which prevents a perfect 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?
The description provides no guidance on when to use this tool versus alternatives like 'list_sprites' or 'list_checkpoints', nor does it mention prerequisites or context for usage. It simply states what the tool does without indicating appropriate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available Sprite VMs in the organization. Returns an interactive dashboard to manage sprites.
| Name | Required | Description | Default |
|---|---|---|---|
| org | No | Organization name (optional, uses default if not specified) |
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 mentions the return format ('interactive dashboard to manage sprites'), which adds some value, but fails to address critical aspects like whether this is a read-only operation, potential rate limits, authentication requirements, or pagination behavior for a list operation.
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 efficiently structured in two sentences: the first states the core purpose, and the second describes the return format. It's appropriately sized without wasted words, though the second sentence could be more precisely integrated with the first.
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 and no output schema, the description covers the basic purpose and return format adequately. However, without annotations and with sibling tools present, it lacks sufficient context about behavioral traits and differentiation from alternatives to be considered fully complete.
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 fully documents the single optional 'org' parameter. The description adds no additional parameter information beyond what the schema provides, meeting 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 verb ('List') and resource ('all available Sprite VMs in the organization'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_checkpoints' or 'list_sessions' beyond the resource type, which prevents a perfect 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?
The description provides no guidance on when to use this tool versus alternatives like 'list_checkpoints' or 'list_sessions', nor does it mention prerequisites or exclusions. It simply states what the tool does without contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload a file from local filesystem to a remote Sprite VM
| Name | Required | Description | Default |
|---|---|---|---|
| sprite | Yes | Name of the sprite | |
| local_path | Yes | Path to the local file | |
| remote_path | Yes | Destination path on the remote sprite | |
| org | No | Organization name (optional) |
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 upload action but doesn't mention critical behavioral aspects such as required permissions, whether the operation overwrites existing files, error handling, or network implications. This is a significant gap for a mutation tool with zero annotation coverage.
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, 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 complexity of a file upload operation (a mutation with potential side effects), no annotations, and no output schema, the description is incomplete. It fails to address key contextual elements like what happens on failure, response format, or interaction with sibling tools, leaving the agent under-informed.
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%, so the schema already documents all four parameters with clear descriptions. The description adds no additional parameter semantics beyond what's in the schema, such as format examples 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 action ('Upload a file') and the resources involved ('from local filesystem to a remote Sprite VM'), making the purpose immediately understandable. It distinguishes this as a file transfer operation, though it doesn't explicitly differentiate from sibling tools like 'fetch_file' (which likely does the reverse).
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 'fetch_file' or other file-related operations. It lacks context about prerequisites (e.g., needing an existing sprite), exclusions, or typical use cases, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Restore a Sprite VM to a previous checkpoint state
| Name | Required | Description | Default |
|---|---|---|---|
| sprite | Yes | Name of the sprite | |
| checkpoint_id | Yes | ID of the checkpoint to restore | |
| org | No | Organization name (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. 'Restore' implies a potentially destructive mutation, but the description doesn't disclose whether this overwrites current state, requires specific permissions, affects other resources, or has side effects. For a mutation 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 with zero waste. It's appropriately sized for a straightforward operation and front-loads the core purpose without unnecessary elaboration.
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 mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'restore' entails behaviorally, what the response contains, or how it interacts with sibling tools. Given the complexity of state restoration, more context is needed.
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 three parameters. The description doesn't add any parameter-specific context beyond what's in the schema (e.g., format of checkpoint_id, what 'sprite' refers to). 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 action ('Restore') and target resource ('Sprite VM to a previous checkpoint state'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'create_checkpoint' or 'list_checkpoints' beyond the obvious verb difference.
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 existing checkpoints), when restoration is appropriate, or what happens to current state. With multiple checkpoint-related siblings, this is a significant gap.
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_checkpointcreate_spritedestroy_spriteexec_commandfetch_fileget_sprite_urllist_checkpointslist_sessionslist_spritespush_filerestore_checkpointEvery tool has a clearly distinct purpose with no ambiguity. For example, create_sprite, destroy_sprite, and list_sprites handle VM lifecycle management, while fetch_file and push_file handle file transfers, and checkpoint tools manage snapshots. The descriptions clearly differentiate each tool's specific function.
All tools follow a consistent verb_noun naming pattern throughout (e.g., create_checkpoint, list_sessions, push_file). There are no deviations in style or convention, making the tool set predictable and easy to understand.
With 11 tools, this is well-scoped for managing Sprite VMs. Each tool earns its place by covering essential operations like VM lifecycle, file management, checkpointing, and session monitoring without being excessive or insufficient.
The tool surface provides complete coverage for the Sprite VM domain, including CRUD operations (create, list, destroy), file management (push, fetch), checkpoint lifecycle (create, list, restore), and additional utilities (exec_command, get_sprite_url, list_sessions). There are no obvious gaps that would hinder agent workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Manage Sprites: sandboxed compute environments with exec, services, and checkpoints.
Provides capabilities that let LLM agents perform a range of infrastructure management tasks.
Operate Linux, macOS and Windows from your LLM. Every action runs through an auditable allowlist.
Let AI operate servers without SSH. Choose actions, approve risky changes, and audit every step.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Anansitrading/sprite-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
