Connect E2B to Claude: Automate filesystem tasks and template builds

If you are building AI agents that write, execute, and debug code, you need a secure runtime environment. E2B provides cloud-based sandboxes tailored for LLM execution, allowing models to run processes, manipulate filesystems, and build custom environment templates safely. To connect E2B to Claude natively, you need a Model Context Protocol (MCP) server that translates Claude's tool calls into E2B's REST API commands. If your team uses ChatGPT, check out our guide on connecting E2B to ChatGPT or explore our broader architectural overview on connecting E2B to AI Agents.

Giving a Large Language Model (LLM) read, write, and execute permissions inside an infrastructure provisioning platform is a massive engineering challenge. You have to handle API authentication lifecycles, manage asynchronous build states, and feed strict schema requirements to the model. Every time an endpoint shifts or a required field is deprecated, you have to update your server code, redeploy, and test the integration. Instead of building and maintaining this infrastructure yourself, you can use Truto to dynamically generate a secure, authenticated MCP server URL.

This guide breaks down exactly how to generate a managed MCP server for E2B using Truto, connect it natively to Claude, and orchestrate complex sandbox execution workflows using natural language.

The Engineering Reality of the E2B API

A custom MCP server is a self-hosted translation layer between an LLM and an external REST API. While the open MCP standard provides a predictable framework for models to discover tools, implementing it against E2B's specific infrastructure operations presents unique hurdles.

If you decide to build a custom MCP server for E2B, you are responsible for managing the entire integration lifecycle. Here are the specific challenges you will encounter:

Asynchronous Build Lifecycles E2B is heavily reliant on asynchronous operations, particularly when building custom sandbox templates. When you call an endpoint to start a build (e_2_b_templates_start_build), the API returns a 202 Accepted response, not the finished build. If you expose this raw behavior to Claude, the LLM will often assume the build is complete immediately and try to instantiate a sandbox that doesn't exist yet. Your custom integration layer must handle the polling of e_2_b_templates_get_build_status and accurately translate the build logs (which are often paginated or streamed) back into a deterministic tool response for the LLM.

Stateful Process and Filesystem Management E2B allows you to run arbitrary bash commands or Python scripts inside the sandbox. However, the E2B API treats processes as stateful entities with distinct PTY (pseudo-terminal) inputs and outputs. You cannot simply "send a string and get a string back" without managing the process ID (pid), handling standard error vs standard output streams, and managing filesystem states. Closing a stdin stream or resizing a PTY requires precise endpoint calls. If your MCP tools don't abstract this cleanly, the LLM will hallucinate process IDs or get stuck in terminal prompts waiting for input.

Concurrency Limits and Strict Rate Limiting E2B enforces strict concurrency limits based on your tier. If your AI agent spins up too many sandboxes in parallel to test code variants, E2B will return an HTTP 429 Too Many Requests error. Truto normalizes upstream rate limit info into standardized headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset) per the IETF spec. Truto does not retry, throttle, or apply backoff on rate limit errors - when E2B returns a 429, Truto passes that error directly to the caller. The LLM orchestrator is strictly responsible for interpreting the 429 and executing exponential backoff logic.

How to Generate an E2B MCP Server with Truto

Truto's dynamic MCP server generation maps E2B's resources into MCP-compatible tools automatically. Rather than hardcoding tool definitions, Truto reads the E2B API specification and documentation records, parses the expected payload schemas, and injects instructions directly into the JSON schemas (such as explicitly instructing the LLM to pass pagination cursors unchanged).

You can generate an E2B MCP server using either the Truto UI or the API.

Method 1: Via the Truto UI

If you prefer a visual interface, you can generate an MCP server directly from your connected E2B account.

1. Navigate to the Integrated Accounts page in the Truto dashboard.
2. Select your connected E2B integration.
3. Click the MCP Servers tab.
4. Click Create MCP Server.
5. Select your desired configuration (e.g., allow read and write methods, set an optional expiration date, or filter by specific tags).
6. Click Generate and copy the resulting MCP server URL (e.g., https://api.truto.one/mcp/abc123def456...).

Method 2: Via the Truto API

For teams dynamically provisioning AI agents in production, you can generate MCP servers programmatically. This endpoint creates a secure token in Cloudflare KV and returns a ready-to-use URL.

curl -X POST https://api.truto.one/integrated-account/{integrated_account_id}/mcp \
  -H "Authorization: Bearer YOUR_TRUTO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "E2B Execution Agent",
    "config": {
      "methods": ["read", "write", "custom"]
    }
  }'

The response contains the secure URL you will use to connect Claude:

{
  "id": "mcp_srv_898989",
  "name": "E2B Execution Agent",
  "config": { "methods": ["read", "write", "custom"] },
  "expires_at": null,
  "url": "https://api.truto.one/mcp/abc123def456..."
}

Connecting the E2B MCP Server to Claude

Once you have the MCP server URL, connecting it to Claude is a one-time configuration step. You do not need to manage API keys on the client side - the URL token itself securely authenticates the connection back to the specific integrated E2B account.

Method A: Via the Claude UI

If you are using Claude Desktop or an enterprise workspace that supports custom connectors:

1. Open Claude and navigate to Settings.
2. Go to Integrations (or Connectors depending on your plan tier).
3. Click Add MCP Server.
4. Give the connection a name (e.g., "E2B Sandboxes").
5. Paste the Truto MCP Server URL.
6. Click Add. Claude will immediately perform a protocol handshake and discover all available E2B tools.

(Note: If you are using ChatGPT Enterprise, the process is identical: Settings -> Apps -> Advanced settings -> Developer mode -> Custom connectors).

Method B: Via Manual Config File

If you are running Claude Desktop locally and prefer file-based configuration, or if you are orchestrating an automated agent framework, you can connect via Server-Sent Events (SSE).

Open your claude_desktop_config.json file (typically located at ~/Library/Application Support/Claude/claude_desktop_config.json on macOS) and add the following:

{
  "mcpServers": {
    "e2b_truto": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-sse",
        "--url",
        "https://api.truto.one/mcp/abc123def456..."
      ]
    }
  }
}

Restart Claude Desktop. The E2B tools will now be available in your chat interface.

Hero Tools for E2B Automation

Truto abstracts E2B's infrastructure APIs into a flat input namespace, meaning the LLM doesn't have to differentiate between URL parameters, query parameters, and JSON body parameters. The MCP router handles schema mapping automatically.

Here are the highest-leverage operations your AI agent can perform using the E2B MCP server:

Create a Sandbox

Tool Name: create_a_e_2_b_sandbox

This is the core provisioning tool. It instructs E2B to spin up an isolated compute environment based on a template ID. You can configure timeouts and environment variables.

"Spin up a new E2B sandbox using template ID 'base-python' with a 300-second timeout."

Upload a File to the Sandbox

Tool Name: e_2_b_filesystem_upload_file

Agents use this to inject source code, test data, or configuration files into the running sandbox. It ensures parent directories are created automatically.

"Upload the attached data.csv file to the path '/home/user/data/data.csv' in sandbox ID 'sbx-123'."

Start a Process

Tool Name: e_2_b_process_start

Executes arbitrary terminal commands or scripts inside the isolated sandbox. The LLM can pass standard shell commands and monitor the process execution.

"Start a process in sandbox ID 'sbx-123' to run 'python3 /home/user/script.py' and return the output."

Start a Template Build

Tool Name: e_2_b_templates_start_build

Allows the LLM to kick off an asynchronous build of a custom sandbox environment. It accepts build steps, a base image, and post-build commands.

"Start a build for template ID 'custom-node-env' using build ID 'bld-456' with the base image 'node:18-bullseye'."

Create a Sandbox Snapshot

Tool Name: e_2_b_sandboxes_create_snapshot

Creates a persistent snapshot of the sandbox's current state. This is highly useful for pausing work or saving a successfully configured environment as a new baseline.

"Create a persistent snapshot of sandbox ID 'sbx-123' and assign it the alias 'debugged-environment'."

List Running Sandboxes

Tool Name: list_all_e_2_b_sandboxes

Enables the AI to monitor concurrent executions, check resource utilization, and identify rogue processes to shut down.

"List all currently running E2B sandboxes so I can check if any testing environments are still active."

To view the complete schema details and the full list of supported E2B endpoints, visit the E2B integration page.

Workflows in Action

Once Claude has access to the E2B MCP server, you can chain these tools together to execute complex engineering workflows autonomously.

Workflow 1: Automated Script Testing and Execution

Developers frequently need to run untrusted code, process data safely, or run end-to-end tests in clean environments.

"I have a Python script that analyzes CSV data. Spin up a base Python environment in E2B, write this script to /home/user/analyze.py, execute it, and tell me the standard output. If it errors, read the traceback and tell me what failed."

Execution Steps:

1. Claude calls create_a_e_2_b_sandbox using a standard Python template ID.
2. Claude calls e_2_b_filesystem_upload_file to write the LLM-generated Python code to /home/user/analyze.py.
3. Claude calls e_2_b_process_start passing python3 /home/user/analyze.py as the command.
4. Claude analyzes the resulting process output. If successful, it relays the analysis to the user. If it fails, Claude uses the traceback to debug.

sequenceDiagram
    participant User
    participant Claude as Claude Desktop
    participant MCP as Truto MCP Server
    participant E2B as E2B API
    
    User->>Claude: "Run this python script..."
    Claude->>MCP: Call create_a_e_2_b_sandbox
    MCP->>E2B: POST /sandboxes
    E2B-->>MCP: Sandbox ID sbx-123
    MCP-->>Claude: Sandbox running
    
    Claude->>MCP: Call e_2_b_filesystem_upload_file
    MCP->>E2B: POST /sandboxes/sbx-123/fs
    E2B-->>MCP: 200 OK
    MCP-->>Claude: File uploaded
    
    Claude->>MCP: Call e_2_b_process_start
    MCP->>E2B: POST /sandboxes/sbx-123/process
    E2B-->>MCP: Process Output / Logs
    MCP-->>Claude: Standard Output returned
    Claude->>User: "The script ran successfully. Here is the output..."

Workflow 2: Custom Environment Provisioning

Platform engineering teams often need to prepare specific Docker-like environments for specialized tasks.

"Create a new E2B template for a Rust build environment. Kick off the template build process using a standard Rust image, and check the build status until it completes."

Execution Steps:

1. Claude calls create_a_e_2_b_template to register the new environment template.
2. Claude calls e_2_b_templates_start_build to initiate the actual container build process using the Rust base image.
3. Claude repeatedly calls e_2_b_templates_get_build_status to poll the async job.
4. Once the build returns a success status, Claude notifies the user that the custom Rust sandbox is ready for future operations.

Security and Access Control

Granting an LLM the ability to provision infrastructure requires strict guardrails. Truto's MCP servers provide several layers of access control out of the box:

• Method Filtering: Use the methods array during MCP server creation to restrict the AI to specific HTTP operations. For example, setting methods: ["read"] prevents the LLM from deleting templates or starting rogue processes.
• Tag Filtering: Limit the server's scope by assigning tags. If you configure tags: ["sandbox_ops"], the LLM will only see tools related to running sandboxes, completely hiding the template build endpoints.
• Secondary Authentication (require_api_token_auth): Enable this flag to require the client to pass a valid Truto API token in addition to the server URL. This prevents unauthorized execution if the MCP URL is ever leaked in a config file.
• Automatic Expiration (expires_at): Assign a strict time-to-live for the MCP server. Once the timestamp passes, a durable object alarm automatically cleans up the token in Cloudflare KV, revoking Claude's access to E2B instantly.

The Shift to Agentic Infrastructure

Connecting E2B to Claude via MCP transforms an LLM from a static code generator into a highly capable, sandboxed DevOps engineer. By delegating the API boilerplate - schema resolution, cursor normalization, and token authentication - to Truto, your engineering team can focus entirely on designing the semantic routing and prompting logic that makes the agent valuable.

You no longer have to maintain custom REST wrappers to run secure code environments. The tools generate dynamically based on the E2B documentation, giving Claude instant, type-safe access to your infrastructure.