E2b
Open-source Code Interpreting for AI Apps. Run sandboxed code execution environments with support for multiple programming languages.
Verdict
Common use cases
- Prototype API endpoints in isolated environments
- Run deployment scripts before pushing to prod
- Debug dependency conflicts in clean VMs
- Execute data pipelines without local setup
- Test infrastructure code in disposable sandboxes
Integration
- Vendor
- E2b
- Category
- developer-tools
- Auth
- API_KEY
- Tools
- 27
- Composio slug
e2b
Tools
- Check API Health
Tool to check the health status of the E2B API. Use when you need to verify that the API service is operational and accessible.
- Connect to Sandbox
Tool to connect to an existing E2B sandbox and retrieve its details. Use when you need to reconnect to a sandbox from different environments or resume a paused sandbox. The TTL is extended upon connection.
- Create Sandbox
Tool to create a new E2B sandbox from a template. Use when you need to launch a fresh sandbox environment for code execution, testing, or development purposes.
- Create Template
Tool to create a new E2B template with specified configuration. Use when you need to define a new sandbox template that can be used to spawn sandbox environments.
- Create Webhook
Tool to register a new webhook to receive sandbox lifecycle events for the team. Use when you need to set up notifications for sandbox lifecycle events such as creation, updates, or termination.
- Delete Sandboxdestructive
Tool to terminate and permanently delete a running E2B sandbox instance. Use when you need to kill a sandbox that is no longer needed. Once terminated, the sandbox cannot be resumed.
- Delete Webhookdestructive
Tool to unregister a webhook and stop receiving lifecycle events. Use when you need to remove a webhook that is no longer needed or to clean up webhook registrations.
- Get Sandbox
Tool to retrieve detailed information about a specific sandbox by its ID. Use when you need to check sandbox status, metadata, or configuration details.
- Get Sandbox Lifecycle Events
Tool to retrieve the latest lifecycle events for a particular sandbox instance. Use when you need to track state changes including creation, pausing, resuming, updates, and termination of a sandbox.
- Get Sandbox Logs
Tool to retrieve logs from a specific E2B sandbox instance. Use when you need to debug or monitor sandbox execution by viewing its console output and system logs.
- Get Sandbox Metrics
Tool to retrieve timestamped CPU, memory, and disk usage metrics for a sandbox. Use when you need to monitor resource usage of a running sandbox. Metrics are collected every 5 seconds; returns empty array if no metrics available yet.
- Get Team Maximum Metrics
Tool to retrieve the maximum value for a specific team metric in a given interval. Use when you need to check team limits or peak usage, such as maximum concurrent sandboxes allowed or highest resource usage.
- Get Team Metrics
Tool to retrieve timestamped CPU, memory, and disk usage metrics for a team. Use when you need to monitor aggregated resource usage across all sandboxes belonging to a team.
- Get Template Build Status
Tool to get the status of a template build. Use when you need to check the build status of a template that was started asynchronously. Useful in polling loops to monitor template builds in progress.
- Get Template Files
Tool to get an upload link for a tar file containing build layer files. Use when you need to retrieve or download template build layer files by their hash.
- Get Webhook Configuration
Tool to retrieve the current webhook configuration for a specific webhook. Use when you need to inspect webhook settings, verify configuration, or check webhook status.
- List All Sandboxes
Tool to list all running and paused sandboxes associated with your team. Use when you need to view active sandboxes, monitor sandbox state, or retrieve sandbox identifiers for further operations. Supports pagination and filtering by state o
- List All Templates
Tool to list all available E2B templates for your team. Use when you need to view available templates, retrieve template identifiers, or audit template configurations.
- List All Webhooks
Tool to retrieve all registered webhooks for your team. Use when you need to view all webhook configurations, audit webhook settings, or manage multiple webhooks.
- List Sandboxes Metrics
Tool to retrieve timestamped CPU, memory, and disk usage metrics for multiple sandboxes. Use when you need to monitor resource usage across multiple sandboxes simultaneously. Metrics are collected every 5 seconds; returns empty array if no
- List Team Sandbox Lifecycle Events
Tool to retrieve the latest lifecycle events across all sandboxes associated with the team. Use when you need to monitor sandbox activity, track lifecycle changes, or audit sandbox operations.
- Pause Sandbox
Tool to pause a running E2B sandbox preserving its filesystem and memory state. Use when you need to temporarily suspend a sandbox while maintaining its state for later resumption. Takes approximately 4 seconds per 1 GiB of RAM to pause. Pa
- Refresh Sandbox
Tool to refresh an E2B sandbox and extend its time to live. Use when you need to keep a sandbox alive longer and prevent it from timing out.
- Set Sandbox Timeout
Tool to set the timeout for an E2B sandbox. Use when you need to extend or reduce the sandbox lifetime. The timeout is measured from the current time, and calling this multiple times overwrites the previous TTL.
- Start Template Build
Tool to start a build for an E2B template. Use when you need to initiate the build process for a template with specific configuration. The build runs asynchronously and returns immediately with a 202 Accepted status.
- Update Template
Tool to update an E2B template configuration. Use when you need to modify template settings such as changing visibility (public/private status).
- Update Webhook Configuration
Tool to update an existing webhook configuration including URL, enabled status, and subscribed events. Use when you need to modify webhook settings, change the destination URL, enable/disable a webhook, or update event subscriptions.
Setup
Setup guide
- 11. Sign up at e2b.dev and generate an API key from your team dashboard. 2. In Switchy, open Settings → Integrations → Developer Tools and select E2b. 3. Paste your API key into the credential field and click Connect. 4. Switchy will ping the E2b health endpoint to confirm the key works. 5. Open any Space and type '@E2b create a sandbox from the default template' to test. 6. E2b will return a sandbox ID and connection details. 7. Follow up with '@E2b run `uname -a` in sandbox <ID>' to execute a command. 8. Check the output in the thread — if you see kernel info, the integration is live. 9. Sandboxes persist until their TTL expires or you explicitly delete them with '@E2b delete sandbox <ID>'. 10. To reuse a sandbox across sessions, note its ID and reconnect with '@E2b connect to sandbox <ID>'.
What teammates see: by default, memories from E2b are scoped to the Space (PROJECT visibility) - you can mark any memory PRIVATE or share it ORG-wide.
Works well with
Top models
Compatibility data appears once enough Spaces have used this MCP together with a given model.
How Switchy teams use it
Starter prompts
Spin Up Python Sandbox
@E2b create a sandbox from the python-data template, then install pandas, numpy, and matplotlibOpen in a Space →
Test Deployment Script
@E2b create a sandbox, upload deploy.sh, and execute it with bash -x to show each stepOpen in a Space →
Check Sandbox Status
@E2b get details for sandbox sbx_abc123 and tell me how long it's been runningOpen in a Space →
Run Node.js Snippet
@E2b create a Node sandbox, upload index.js, and run it with node index.jsOpen in a Space →
Clean Up Old Sandboxes
@E2b list all sandboxes for my team, then delete any that have been running longer than 2 hoursOpen in a Space →
Example outputs
Illustrative - representative of the model's voice and quality, not literal recordings.
@e2b create a Python sandbox and run a quick data analysis script on this CSV sample I just uploaded
Created sandbox `sb_abc123` from the default Python template. Uploaded your CSV (1,247 rows) and executed the analysis script. Results: 3 outliers detected in the 'revenue' column, median response time 142ms, correlation coefficient 0.87 between variables A and B. The sandbox remains active for the next 15 minutes unless you extend the TTL or explicitly delete it.
This example shows E2b's core strength: ephemeral, isolated code execution environments. The sandbox auto-terminates after the TTL expires, so you won't accumulate orphaned instances. Requires an API key with sandbox creation permissions; each sandbox incurs usage charges based on runtime and resource tier.
@e2b list all active sandboxes for our team and kill any that have been idle for more than an hour
Found 4 active sandboxes. Two match your idle criteria: `sb_def456` (idle 73 minutes, last activity: file system read) and `sb_ghi789` (idle 89 minutes, last activity: process spawn). Terminated both sandboxes. Remaining active: `sb_jkl012` (Node.js, 12 minutes old) and `sb_mno345` (Python, 3 minutes old). Total runtime cost recovered: ~$0.14.
Demonstrates E2b's management tools for cost control. Deleting a sandbox is permanent — any unsaved state or files inside are lost. If you need to preserve outputs, copy them out before termination. Webhook integration (separate tool) can automate this cleanup based on lifecycle events.
@e2b create a custom template with Node 20, Playwright, and our internal test fixtures pre-installed, then spawn a sandbox from it to run our E2E suite
Created template `tpl_xyz789` with Node 20.11, Playwright 1.42, and your fixture directory mounted at `/workspace/fixtures`. Template build completed in 47 seconds. Spawned sandbox `sb_pqr234` from this template and executed the E2E suite: 18 tests passed, 2 failed (screenshot diffs attached), total runtime 4m 12s. The template is now reusable for future test runs without reinstalling dependencies.
Templates amortize setup cost across multiple sandbox runs — ideal for CI/CD pipelines. Template creation requires a Dockerfile or build spec; the MCP handles the API orchestration but you must provide the configuration. Failed tests here produced artifacts (screenshots) that persist only until sandbox deletion, so extract them promptly.
Use-case deep-dives
When E2b wins for running untrusted LLM-generated code
A 3-person AI startup is building a coding assistant that writes and executes Python scripts based on user prompts. They need to run LLM output without risking their infra. E2b is the right call here: spin up a sandbox per request with Create Sandbox, execute the code, grab the output, then Delete Sandbox. The 27 tools give you lifecycle control (pause, resume, reconnect) if a script needs multiple turns. The API key auth is simple enough for a small team. The threshold: if you're running more than 500 sandboxes per hour, you'll want to template heavily and monitor the webhook events to avoid orphaned instances eating your budget. For a team at this scale shipping an AI code feature, E2b removes the 'what if this deletes our database' risk without building your own container orchestration.
E2b for on-demand sales demo sandboxes
A 6-person devtools company runs live product demos where prospects write code in a browser IDE. They use E2b templates to pre-configure sandbox environments with their SDK and sample data, then Create Sandbox at demo start and Delete Sandbox when the call ends. The webhook tool lets them log sandbox usage to their CRM for follow-up context. This works well up to about 20 demos per week—beyond that, you'll want a dedicated demo platform with better session management. The trade-off: E2b gives you real compute isolation and a clean slate per demo, but you're paying per-sandbox-minute, so long-running demos (over 30 minutes) get expensive fast. If your demos are scripted 15-minute walkthroughs and you need zero setup time, E2b beats maintaining a fleet of pre-provisioned VMs.
When E2b fits technical interview infrastructure
A 10-person eng team runs 8-12 technical interviews per week, each candidate writing code in a live environment. They template a sandbox with their preferred language runtimes and testing frameworks, then Create Sandbox when the interview starts. The interviewer shares the sandbox ID so both can Connect to Sandbox and see the same state. After the hour, they snapshot the final code and Delete Sandbox. This setup works if your interview volume is under 50 per month and you don't need advanced features like replay or multi-candidate comparison. The limit: E2b doesn't store interview history beyond the sandbox TTL, so you'll need to export artifacts before deletion. For a small team that wants candidates writing real code without local setup friction, E2b is cheaper and faster than building a custom interview platform.
Frequently asked
What does the E2b MCP let me do in Switchy?
It lets your team spin up isolated code execution sandboxes on demand. You can create templates, launch fresh environments, run code safely, and tear them down when done. Useful for testing scripts, prototyping integrations, or running untrusted code without risking your local machine. All 27 tools are available to any team member who connects the MCP.
Do I need an E2b account to use this MCP?
Yes. You need an E2b API key, which means you need an active E2b account. The MCP authenticates via API_KEY, so whoever connects it in Switchy must paste their key from the E2b dashboard. That key determines which E2b team's sandboxes and templates Switchy can access. No OAuth flow — just copy-paste the key.
Can the E2b MCP run arbitrary code inside sandboxes?
Not directly. The MCP manages sandbox lifecycle — creating, connecting, deleting, checking health. It does not execute code inside the sandbox itself. You create a sandbox via the MCP, then use E2b's SDK or API separately to run code in it. Think of this MCP as the control plane, not the execution runtime.
Why use this MCP instead of calling the E2b API directly?
The MCP wraps the E2b API so your AI assistant can manage sandboxes conversationally. Instead of writing curl commands or SDK boilerplate, you ask Switchy to "spin up a Python sandbox" and it handles the API call. Faster for ad-hoc tasks. For production workflows, call the API directly from your codebase.
Who on my team should connect the E2b MCP?
Whoever owns your E2b account or has an API key with the right permissions. That person connects it once in Switchy; then everyone in the workspace can use it. Sandboxes created via the MCP count against your E2b plan limits, so coordinate with whoever manages your E2b billing.