Your AI Agent Doesn’t Need 50 Tools. It Needs a Terminal.

The model doesn’t want your tools. It wants a computer.

Eiso Kant, founder of Poolside AI, said something last week most agent builders haven’t processed: “I think MCP and tools are stupid.”

He meant for complex, long-horizon work. Not weather calls. Not “look up a customer in Stripe.” He meant the work you actually want an agent to do — the work you’re probably wiring MCP servers for right now.

His point in one line: if the task isn’t trivial, don’t hand a model 50 tool definitions in a prompt. Hand it a virtual machine, a filesystem, a few pre-installed binaries, and permission to write and run code.

I’ve been watching frontier coding models for a year. He’s right. Not because he said it — he’s a competitor and has every reason to jab MCP — but because the evidence is already here in Claude Code, in Poolside’s Laguna S and XS2 releases, in the way senior engineers describe their most productive workflows. You can see echoes in Vercel v0 and in Stripe’s internal agent tooling. The models keep asking for a terminal. We keep handing them a menu.

Here’s why the shift matters, what it does to your product, and one concrete audit for Monday.

MCP was built for a world where models could not code

Model Context Protocol solved a real problem. In 2023 and early 2024, if you wanted GPT‑4 to touch an external system, you wrapped it as a small, well-defined tool with a JSON schema. The model wasn’t good enough to write code against your service. It was good enough to fill out a form.

So we built the form.

Fifty forms. A hundred. Anthropic standardized the protocol, everyone shipped MCP servers, and now serious agent stacks drag around prompts stuffed with tool schemas — each one a brittle contract between a model getting smarter and an API surface that isn’t.

MCP’s bet was simple: the model needs structure, so give it structure. That was correct in 2023. It’s aging fast in 2025 for one reason: the models can code now. Well enough that writing a Python script against a real filesystem is often faster, cheaper, and more expressive than hunting through fifty tools and bargaining with their schemas.

What VM-native actually looks like

Concrete example. You’re shipping a coding agent into construction-tech — an automation that reads IFC (Industry Foundation Class) files, runs clash detection between HVAC and structural elements, and generates a report. Maybe it scripts Revit through its API, too.

The MCP way: define tools for parse_ifc, extract_elements_by_type, check_geometric_intersection, generate_pdf_report. Wire each to a backing service. Pray your schemas cover real-world edge cases. Add tool #51 when the first bug report lands.

The VM-native way: start a container with IFCOpenShell installed, mount the client’s file drop as a volume, give the agent shell access. It writes a Python script. It runs it, reads stack traces, fixes bugs, re-runs. Client wants a new report format? The agent writes new code. You don’t ship a new tool.

That used to be science fiction. Models couldn’t debug their own scripts. That changed. Claude Code works like this — a harness around a model that can read files, run commands, and see output. Not a pile of tool definitions. Poolside’s Laguna S and XS2 are trained for this pattern — RL tuned for long-horizon interaction with a system, not for filling JSON forms one call at a time.

Why this is not just an implementation detail

You can try to split the world: MCP for simple stuff, VM sandboxes for complex stuff. That’s fine today.

The deeper issue is what it does to your advantage as a builder.

If your product is 50 MCP tools stitched together, your ceiling is the quality of that tool graph. Every new capability is a new tool. Every model upgrade forces you to re-check every schema. Your moat is a tool library — exactly the kind of asset that evaporates when frontier models get 20% better at code and stop needing your scaffolding.

If your product is a well-built VM environment — right binaries installed, right data mounted, right observability — your ceiling rises when the model does. You’re shipping infrastructure the agent uses, not crutches it needs.

That’s a very different asset to own.

The Poolside story is a warning about being early

Here’s the part of Kant’s story that sticks. In 2015, he read Andrej Karpathy’s “The Unreasonable Effectiveness of RNNs,” pivoted overnight to building language models on code, raised $12M, hired 40 people, worked almost five years, and shut it down in 2019. The scaling laws were visible. The team missed them.

Two years later, ChatGPT shipped, and the ideas he was working on became default thinking.

The lesson isn’t “too early.” It’s that seeing the right abstraction while you’re inside it is hard. Sourced was on the right problem with the wrong architecture. Poolside is now betting that three years from now we’ll look back at MCP-heavy agent stacks the way we look at bash+Slurm training runs — something you cobbled together before you realized it was a factory problem. Kant even uses the SpaceX factory analogy for a reason.

He might be wrong. But last time, the contrarian bet — that scale and RL would define the next era while OpenAI, Google, and Anthropic publicly disagreed — turned out right in eighteen months.

Open research is the tell

One more pattern from Poolside that matters. Kant and his co-founder decided to open not just weights, but training methodology. Full technical reports. Optimizer bugs they hit. Epsilon values in Adam that early Llama papers quietly juiced and that made no sense until they debugged their way out.

Open weights let you run a model locally. Open research tells you why it behaves the way it does — so you can fine-tune for your domain with signal, not vibes.

If you build in a vertical — construction, legal, medical imaging, whatever — this is bigger than most teams realize. A closed Anthropic API gives you a strong model and no explanation. An open-research model gives you a slightly less polished base and a training playbook. Your team can decide how to fine-tune on domain data and roughly predict what will happen.

For domain work, that trade is usually worth it, even if the headline benchmarks are lower.

What to do this week

Run one audit of your current agent stack. Two questions:

• How many tool definitions sit in your system prompt or MCP server list? If it’s more than ten, you’re likely on the wrong side of this shift for complex tasks. Simple lookups are fine. The multi-step reasoning flows where users say the agent gets confused are not.
• For your three most complex workflows, would a well-configured sandbox — Docker container, mounted volume, pre-installed CLI tools, a working directory the agent can write to — replace half your tool graph? If yes, prototype it. One workflow, one weekend. Compare latency, error rate, and how many lines of glue code you wrote.

You’ll probably find the VM path is uglier to demo and cleaner to maintain. That’s the shape of the shift.

The frontier isn’t asking you to torch MCP tomorrow. It’s telling you the ceiling of a tool-graph architecture is lower than the ceiling of a sandbox — and the models are racing up to that ceiling faster than most builders think.

Give the model a terminal. See what it does.