Two of the five tools run code; three move files. That ratio is the right one, because a script that writes a CSV, renders a chart or transforms a dataset leaves its result on disk, and an executor without a read path can only tell you it finished. Upload, list and read close that loop. The trade to understand is where the trust boundary sits: the code runs in E2B's infrastructure under your key, so this is safer than running it locally and is not the same thing as running it nowhere.
A thin client over E2B's sandboxes with five tools: execute JavaScript, execute Python, and upload, list and read files inside the sandbox.
- executeJavaScript and executePython run code in a cloud sandbox rather than on the host the agent is running on.
- uploadFile puts a file into the sandbox so code has something to work against.
- listFiles and readFile let the agent see what the run produced, which is what turns a one-shot execution into something it can iterate on.
E2B_API_KEY. The sandbox is E2B's, so quota and session lifetime follow their account, not this server.
One command plus a key — npx -y smart-e2b, then supply credentials