E2B MCP Server

E2B

E2B provides cloud-based sandboxes (ephemeral virtual machines) for AI-generated code execution. This bundle manages sandbox lifecycle, templates, and snapshots through the platform REST API. Code execution inside sandboxes happens via the sandbox-side envd API (Connect RPC), not through these tools — these tools manage the infrastructure.

Entity Hierarchy

• Templates define sandbox environments (OS, packages, config). Create sandboxes from templates.
• Sandboxes are running VM instances created from a template. They have a lifecycle: running → paused → resumed → killed.
• Snapshots capture a sandbox's state for later restoration. Created from running sandboxes.
• Metrics track CPU, memory, and network usage per sandbox or per team.

CRUD Capabilities

Full CRUD (create, read, list, delete/kill):

• Sandboxes — create from template, list with state/metadata filters, get details by ID, kill by ID.

Lifecycle operations (state transitions):

• Pause — freeze a running sandbox (no billing while paused).
• Resume — wake a paused sandbox and extend its timeout.
• Timeout — set or extend the TTL (time-to-live) before auto-kill.

Create + Read:

• Snapshots — capture sandbox state, list all snapshots.

Read + Delete:

• Templates — list available templates, get template details, delete templates.

Read-only:

• Logs — sandbox stdout/stderr with cursor pagination, level filtering, and text search.
• Metrics — per-sandbox CPU/memory/network time series.

Workflows

Run ephemeral code: Create a sandbox from the default template (or a custom one). The sandbox gets an ID you can use to connect via SDK for code execution. Set timeout to auto-kill after your job finishes. Kill explicitly when done to avoid charges.

Pause/resume long-running environments: Pause a sandbox to stop billing, resume later with a new timeout. State is preserved across pause/resume cycles.

Snapshot and restore: Create a snapshot of a configured sandbox to save its state. Use the snapshot's template ID to create identical sandboxes later.

Monitor sandbox health: Pull metrics (CPU, memory) and logs for running sandboxes. Use log search to find errors. Filter by level (error, warn, info).

Manage templates: List templates to see available environments. Delete unused templates to clean up.

Gotchas

• Template ID required for creation: You must specify a template_id when creating a sandbox. List available templates to find IDs, or use "base" for the default Ubuntu template.
• Timeout is from NOW: Setting a sandbox timeout resets the TTL to N seconds from the current time, not from creation.
• Pause stops billing: Paused sandboxes are not billed, but they still consume snapshot storage.
• Max session length varies by plan: Hobby = 1 hour max, Pro = 24 hours. Exceeding the limit auto-kills the sandbox.
• Concurrent limits: Hobby = 20 sandboxes, Pro = 100 (up to 1,100 with add-on).
• Rate limits: 20,000 API calls per 30 seconds. Sandbox creation rate: 1/sec (Hobby) or 5/sec (Pro). Exceeding returns HTTP 429.
• No code execution through these tools: These tools manage sandbox lifecycle only. To run code inside a sandbox, use the E2B SDK or connect to the sandbox's envd endpoint directly.