Allows executing JavaScript code in a sandboxed environment, including file operations and package installation via npm.
Provides Node.js runtime for executing JavaScript code in a sandboxed environment.
Allows installing npm packages into the sandbox environment for use in JavaScript execution.
Allows executing Python code in a sandboxed environment, including file operations and package installation via pip.
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., "@E2B MCP Server run Python code to compute mean of numbers"
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.
A production-ready Model Context Protocol (MCP) server that integrates AI assistants with E2B's sandboxed code execution environment.
This MCP server provides secure, sandboxed code execution capabilities for Python and JavaScript, along with file management and package installation features. Built for the Klavis AI coding assignment, it demonstrates enterprise-grade architecture with comprehensive error handling, security validation, and resource management.
Related MCP server: Code Executor MCP Server
execute_python - Execute Python code in sandboxed environment
execute_javascript - Execute JavaScript/Node.js code
create_file - Create files in sandbox
read_file - Read files from sandbox
list_files - List directory contents
install_packages - Install Python (pip) or Node.js (npm) packages
get_sandbox_info - Get sandbox status and resource information
Security-First Design: Input validation, output sanitization, and dangerous pattern detection
Resource Management: Automatic sandbox cleanup, idle timeout handling, and resource monitoring
Production Ready: Comprehensive logging, error handling, and graceful shutdown
Multi-language Support: Both Python and JavaScript execution environments
Persistent Sessions: Reuse sandboxes across tool calls for better performance
Clone and Install Dependencies
git clone <repository>
cd my-mcp-server
npm installSet Environment Variables
export E2B_API_KEY="your-e2b-api-key"
export LOG_LEVEL="info" # Optional: debug, info, warn, error
export NODE_ENV="production" # Optional: enables file loggingBuild the Project
npm run buildTest the Installation
npm testConfigure your MCP client to use this server:
{
"mcpServers": {
"e2b-server": {
"command": "node",
"args": ["/path/to/my-mcp-server/dist/index.js"],
"env": {
"E2B_API_KEY": "your-api-key"
}
}
}
}npm run dev# Run comprehensive tests
npm test
# Or run the built server directly
npm startExecute Python code in a sandboxed environment.
Parameters:
code (string, required): Python code to execute
sandbox_id (string, optional): Specific sandbox ID to reuse
Example:
print("Hello from E2B!")
import numpy as np
data = np.array([1, 2, 3, 4, 5])
print(f"Mean: {np.mean(data)}")Execute JavaScript/Node.js code in a sandboxed environment.
Parameters:
code (string, required): JavaScript code to execute
sandbox_id (string, optional): Specific sandbox ID to reuse
Example:
console.log("Hello from Node.js!");
const fs = require('fs');
const data = [1, 2, 3, 4, 5];
const mean = data.reduce((a, b) => a + b) / data.length;
console.log(`Mean: ${mean}`);Create a file in the sandbox environment.
Parameters:
path (string, required): File path to create
content (string, required): File content
sandbox_id (string, optional): Specific sandbox ID
Example:
{
"path": "data/example.txt",
"content": "Hello, E2B MCP Server!"
}Read a file from the sandbox environment.
Parameters:
path (string, required): File path to read
sandbox_id (string, optional): Specific sandbox ID
List files in a directory.
Parameters:
path (string, optional): Directory path (defaults to current directory)
sandbox_id (string, optional): Specific sandbox ID
Install packages in the sandbox environment.
Parameters:
packages (array of strings, required): Package names to install
language (string, required): "python" or "javascript"
sandbox_id (string, optional): Specific sandbox ID
Examples:
{
"packages": ["numpy", "pandas", "matplotlib"],
"language": "python"
}{
"packages": ["lodash", "axios", "moment"],
"language": "javascript"
}Get information about sandbox status and resource usage.
Parameters:
sandbox_id (string, optional): Specific sandbox ID (if not provided, lists all sandboxes)
Code length limits (50KB max)
Dangerous pattern detection
Package name validation
File path sanitization
ANSI escape code removal
Secret detection and masking
Output length limits (10KB max)
Execution timeout (30 seconds)
Idle sandbox cleanup (5 minutes)
Maximum file size (10MB)
Package installation limits
The server monitors for potentially dangerous patterns:
Network operations (socket, requests, fetch)
System file access (/etc, /root, /sys)
Process operations (subprocess, child_process)
Secret patterns (API keys, passwords)
SandboxService (src/sandbox-manager.ts)
Manages E2B sandbox lifecycle
Handles resource cleanup and idle timeouts
Provides sandbox pooling and reuse
E2BTools (src/tools.ts)
Implements all MCP tool handlers
Integrates with E2B API
Handles execution and file operations
SecurityValidator (src/security.ts)
Input validation and sanitization
Pattern detection for dangerous code
Output sanitization and secret masking
Logger (src/logger.ts)
Structured logging with Winston
Development and production configurations
Security event logging
Comprehensive try-catch blocks
Graceful degradation
Detailed error logging
User-friendly error messages
Automatic resource cleanup on failures
Automatic sandbox cleanup on idle timeout
Graceful shutdown handlers
Memory and resource monitoring
Connection pooling for better performance
Variable | Required | Default | Description |
| Yes | - | Your E2B API key |
| No | info | Logging level (debug, info, warn, error) |
| No | development | Environment (enables file logging in production) |
src/
├── index.ts # Main MCP server entry point
├── sandbox-manager.ts # E2B sandbox lifecycle management
├── tools.ts # MCP tool implementations
├── security.ts # Security validation and sanitization
├── logger.ts # Logging configuration
├── types.ts # TypeScript type definitions
└── test.ts # Comprehensive test suitenpm run build# Mock tests (no API key required) - verify implementation structure
npm run test-mock
# Full functionality tests (requires E2B_API_KEY environment variable)
npm testMock Testing:
The test-mock script verifies that your implementation is structurally correct without requiring an E2B API key. This is useful for:
Verifying tool definitions are correct
Checking method signatures
Testing implementation structure
CI/CD environments where API keys aren't available
Full Testing:
The test script runs comprehensive functionality tests including:
Python code execution
JavaScript code execution
File operations (create, read, list)
Package installation (Python & JavaScript)
Sandbox management
Error handling
npx tsc --noEmitCreate a Dockerfile:
FROM node:18-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY dist/ ./dist/
ENV NODE_ENV=production
CMD ["npm", "start"]# Production environment variables
export NODE_ENV=production
export LOG_LEVEL=info
export E2B_API_KEY=your-production-api-keyThe server provides structured JSON logging suitable for log aggregation services:
{
"level": "info",
"message": "Executing Python code in sandbox abc-123",
"timestamp": "2024-01-01T12:00:00.000Z",
"service": "e2b-mcp-server"
}Sandbox Reuse: Sandboxes are reused across tool calls to reduce latency
Idle Cleanup: Automatic cleanup after 5 minutes of inactivity
Output Limits: Output is truncated at 10KB to prevent memory issues
Timeout Management: 30-second execution timeout with graceful error handling
Resource Monitoring: Built-in sandbox resource usage tracking
"E2B_API_KEY environment variable is required"
Ensure your E2B API key is set in environment variables
Verify the key is valid and has appropriate permissions
"Sandbox creation failed"
Check E2B service status
Verify API key permissions
Check network connectivity
"Security validation failed"
Review code for dangerous patterns
Check file paths for directory traversal
Verify package names follow naming conventions
"Execution timeout"
Code took longer than 30 seconds to execute
Consider optimizing code or breaking into smaller chunks
✅ Code Execution Issue Resolved
The previous issue with Jupyter kernel port (49999) not being open has been completely resolved. The server now uses E2B's latest v1.5.1 SDK which provides direct code execution without relying on Jupyter kernels.
What was fixed:
Updated from legacy Jupyter-based execution to E2B's modern code execution API
Fixed execute_python ✅ - Now works with E2B v1.5.1 direct execution
Fixed execute_javascript ✅ - Now works with proper Node.js wrapping
Fixed install_packages ✅ - Now works for both Python (pip) and JavaScript (npm)
All features now working:
✅ execute_python - Execute Python code in sandboxed environment
✅ execute_javascript - Execute JavaScript/Node.js code
✅ create_file - Create files in sandbox
✅ read_file - Read files from sandbox
✅ list_files - List directory contents
✅ install_packages - Install Python (pip) or Node.js (npm) packages
✅ get_sandbox_info - Get sandbox status and resource information
Enable debug logging for detailed troubleshooting:
export LOG_LEVEL=debug
npm startThis project follows TypeScript strict mode and includes comprehensive error handling. When contributing:
Follow the existing code style
Add appropriate error handling
Include security validation for new features
Update tests for new functionality
Add logging for important operations
MIT License - see LICENSE file for details.
For issues specific to this MCP server implementation, please check the troubleshooting section above. For E2B-related issues, consult the E2B documentation.
Create a file in the sandbox environment
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | File path to create | |
| content | Yes | File content | |
| sandbox_id | No | Optional sandbox ID to use specific sandbox |
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 ('create a file') but does not mention whether the file is overwritten if it already exists, whether parent directories are created automatically, or any permission or sandbox constraints. This is minimal behavioral transparency 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 concise sentence with no filler. It is appropriately sized for a simple tool and immediately communicates the core 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 file-creating tool with no annotations and no output schema, the description omits important behavioral details such as overwrite behavior, path handling relative to the sandbox root, and whether content is written exactly as provided. The low complexity keeps this from being a 1, but the description is not complete enough for an agent to predict side effects.
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% coverage with descriptions for all three parameters, so the schema already documents the parameters. The description adds no parameter-specific information, but the baseline of 3 applies because the schema covers the needed semantics.
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 a specific verb ('Create') and resource ('file in the sandbox environment'), which distinguishes it from sibling tools like read_file and list_files. It lacks detail about the file path semantics, but the core purpose is unambiguous.
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 purpose implicitly communicates when to use the tool: whenever a file needs to be created in the sandbox. However, there is no explicit guidance about when not to use it or how it compares to related operations like writing files via execute_python or creating files through package installation. The usage context is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute JavaScript/Node.js code in an E2B sandbox environment
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | JavaScript code to execute | |
| sandbox_id | No | Optional sandbox ID to use specific sandbox |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It only mentions the sandbox environment and does not state whether execution returns output, how stdout/stderr are handled, whether state persists, or what side effects may occur. This leaves the agent guessing about execution semantics.
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, front-loaded sentence with no waste. It efficiently conveys the core operation and environment, though it sacrifices helpful context for brevity.
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?
With no output schema and no annotations, the description should clarify what the caller receives and how the sandbox behaves. It omits return format, timeout behavior, and environmental constraints, making it insufficient for confident invocation beyond passing arbitrary code.
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 input schema already documents both parameters and their purpose. The description adds no additional semantic value beyond what the schema provides, meeting the baseline for a fully documented schema.
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 states a specific verb ('Execute'), a specific resource ('JavaScript/Node.js code'), and a specific environment ('E2B sandbox'). This clearly distinguishes the tool from its sibling execute_python by language and from file operations, leaving no ambiguity about what resource it acts on.
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 gives no guidance on when to prefer this tool over execute_python or when not to use it. There are no exclusions, prerequisites, or alternative routing hints. Usage must be inferred entirely from 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.
Execute Python code in an E2B sandbox environment
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Python code to execute | |
| sandbox_id | No | Optional sandbox ID to use specific sandbox |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden of behavioral disclosure. It only says 'execute Python code in a sandbox', without mentioning side effects, sandbox persistence, execution timeouts, network/filesystem access, or whether the environment is ephemeral. For an arbitrary code execution tool this is a significant gap.
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 clear, front-loaded sentence with no wasted words. It is concise, though it could arguably include more behavioral context without becoming bloated.
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 tool that executes arbitrary code, this description is too minimal. With no annotations and no output schema, the agent is left unaware of return values, execution limits, environment behavior, or risk considerations, making the definition incomplete for safe and correct 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 covers both parameters with clear descriptions, so the schema already provides the needed semantic meaning. The description adds no extra parameter detail, which is acceptable under the high schema coverage baseline.
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 states a specific verb ('Execute') and resource ('Python code in an E2B sandbox environment'). It clearly distinguishes this from sibling execute_javascript by language, though it does not elaborate on broader sandbox capabilities.
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 Python execution, which differentiates it from execute_javascript, but it provides no explicit guidance on when to choose this tool over alternatives like create_file, list_files, or install_packages. Context is present, but exclusions and alternative routing are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about sandbox status and resource usage
| Name | Required | Description | Default |
|---|---|---|---|
| sandbox_id | No | Optional sandbox ID to get info for specific sandbox |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the transparency burden. 'Get information' signals a read-only operation, but it does not disclose what specific fields are returned, whether the call can be expensive, or what happens when sandbox_id is omitted. It's adequate but lacks behavioral detail.
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?
A single, front-loaded sentence with no filler. It conveys the core purpose in the fewest possible words and does not repeat schema 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?
The tool is simple, has one optional parameter, and the schema covers it. However, with no output schema, the description does not explain what the returned information looks like or the meaning of 'resource usage', leaving some agent-facing ambiguity about what to expect from the call.
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 already documents the only parameter fully (optional sandbox ID for a specific sandbox), giving 100% schema coverage. The description adds no extra parameter semantics, so the baseline of 3 applies.
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 uses a clear verb ('Get') and names the resource ('sandbox status and resource usage'), which distinguishes it from the sibling file/execution tools. It stops short of a fully specific outcome like a list of returned fields, so it's a 4 rather than 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 intended use case is implied by the description: call this when you need sandbox status or resource usage. However, there is no explicit guidance on when not to use it, when the optional sandbox_id should be supplied, or comparison to alternatives, so it earns only an implied-use score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Install packages in the sandbox environment (Python pip or Node.js npm)
| Name | Required | Description | Default |
|---|---|---|---|
| language | Yes | Language ecosystem for package installation | |
| packages | Yes | List of packages to install | |
| sandbox_id | No | Optional sandbox ID to use specific sandbox |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only states that packages are installed via pip/npm, without mentioning side effects, persistence, failure behavior, or return values. This is a significant gap for a tool that mutates the sandbox environment.
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?
A single sentence that front-loads the verb and resource, then adds the ecosystem detail efficiently. There is zero filler and no redundant repetition of schema 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?
The core call can be constructed from schema plus description, but with no annotations and no output schema, an agent is left guessing about return values, failure handling, and when to prefer this over the execute_* siblings. This is minimal but not entirely inadequate for a straightforward install 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?
Schema coverage is 100%, so the baseline is 3. The description adds value by mapping the language enum to actual package managers (pip for Python, npm for Node.js) and clarifying that installation targets the sandbox, which helps the agent interpret the parameters correctly.
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?
Clearly states a specific action (install packages), a target resource (sandbox environment), and the two ecosystems involved (Python pip or Node.js npm). This distinguishes it from sibling tools like execute_python/execute_javascript and file operations.
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 when to use it (when dependencies are needed in the sandbox) but does not explicitly compare it to alternatives like execute_python/execute_javascript or mention when not to use it. The usage context is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List files in a directory in the sandbox environment
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Directory path to list (defaults to current directory) | . |
| sandbox_id | No | Optional sandbox ID to use specific sandbox |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full behavioral burden. It only restates the basic operation and adds no context about return format, recursion, hidden behavior, or how sandbox_id affects listing. This adds little beyond the tool name itself.
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 concise sentence with no wasted words. The verb and object are front-loaded, making it easy to scan.
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 listing tool, this is minimally adequate, but with no output schema and no annotations, an agent is left unsure whether the return includes file names only, full paths, or directories. The description lacks enough detail for fully confident 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?
Schema description coverage is 100%, so the schema fully documents both parameters. The description adds no extra parameter-level meaning, which is acceptable given the 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 (list) and resource (files in a directory) within the sandbox environment. It is distinguishable from siblings like read_file and create_file, though it does not explicitly name or differentiate from 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 given about when to use this tool versus alternatives such as read_file or get_sandbox_info. The intended usage is only implied by the tool name and short description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a file from the sandbox environment
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | File path to read | |
| sandbox_id | No | Optional sandbox ID to use specific sandbox |
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 only says 'read', which implies no side effects, but it does not explain what is returned, how missing files are handled, or how sandbox_id affects behavior. This is a minimal disclosure for a tool with no annotation support.
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 front-loaded sentence with no filler or redundant detail. Every word contributes meaning, and the core action is immediately clear.
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 read operation with only two parameters, the description is largely sufficient. It lacks an explicit statement of return value and error behavior, but given the tool's simplicity and the fully covered schema, the remaining gaps are minor.
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 fully documents the two parameters, so the baseline is 3. The description adds useful context by specifying that the path refers to a file inside the sandbox environment, which is not stated in the schema's 'File path to read' property. This small semantic addition raises it to 4.
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 states a clear verb ('read') and resource ('file from the sandbox environment'), making it easy to distinguish from siblings like create_file and list_files. It does not explicitly name the sibling alternatives, so it stops short of a 5, but the purpose is unambiguous.
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?
There is no guidance on when to use this tool versus alternatives such as list_files or execute_python. The description implies reading a file's contents, but it gives no exclusions, prerequisites, or comparison to sibling tools.
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.
v0.1.0create_fileexecute_javascriptexecute_pythonget_sandbox_infoinstall_packageslist_filesread_fileEach tool targets a clearly distinct operation: executing code by language, managing files, installing packages, or retrieving sandbox metadata. There is no overlap or ambiguity between tool responsibilities.
All tool names use a consistent lowercase snake_case verb-first pattern, such as execute_python, create_file, and list_files. The convention is uniform and predictable across the entire set.
Seven tools is well-scoped for a sandbox execution server, covering code execution, file operations, package installation, and environment introspection without unnecessary redundancy. Each tool earns its place.
The tool surface covers the core sandbox workflow: executing code, managing files, installing packages, and checking sandbox status. Minor gaps like missing delete_file or explicit file update operations exist, but agents can work around them using code execution or existing file writes.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Build Apps and run code in 30 languages — sandboxed, with persistent sessions for agent loops.
Run Python code in a secure sandbox without local setup. Declare inline dependencies and execute s…
Execute code in 8 languages (Python, JS, TS, Go, Java, C++, C, Bash) in gVisor sandboxes.
Production-readiness for your AI coding agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/parth012001/e2b-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
