Code execution with MCP: Building more efficient agents | Hacker News Reader

Code execution with MCP: Building more efficient agents

anthropic.com

39 pointspmkelly44445 comments

"Code interpreters" are incredibly powerful tools for agents as it allows them to process large amounts of data without actually having to move the tokens through it's context window.

However, I don't actually see what any of this has to do with MCP. It's more-so just tool calling + code interpreter design patterns. If anything, the MCP hype has resulted in a lot of BAD tools being written that return ridiculous number of tokens.

SQL is really a perfect solution for allowing the agent to access data, but in most applications, it's not realistic to provide it with a db connection. Your either need RLS and user connection pooling (like supabase) or strict application tenant filtering (which is tricky) and even then, you still can't efficiently join data from multiple sources.

I recently built a system using tenant isolated S3 "dataponds", populated with parquet files, that the agent queries with duckdb.

The VM (agent core) gets an short lived "assume role" STS token injected so it can only access buckets the user is entitled to (also VPC networking so no other ingress/egress). Each location has a `manifest.json` file that describes the contents and schema. The agent can query the parquet files using duckdb, do additional processing with pandas and then share files back to user by writing it to S3 in special predefined display formats (data-table, time-series, etc).

The file ids, along with a sample of the data is pass back the LLM. It can then embed the file in it's response using a special tag and a custom markdown renderer displays it back to the user.

From what I can tell, this is basically what Chat-GPT has done for a long time (minus the preconfigured "datapond" and special response formats), but it's pretty awesome how "low-effort" a system like this can be built today.

An I losing my mind? I feel like we're making things harder for ourselves. My mantra is: just use CLI tools. Or maybe "CLI tools are all you need"?

"--help" mechanics are already built in so the agent can discover what commands are available and how to use them. The agent can write shell scripts to wrap recurring uses or sequences, and then invoke those via CLI. And there are tons of well-tested existing CLI tools available.

I feel like this article being written with the assumption of MCP forces it to overcomplicate the issue.

Just one example: the Atlassian CLI works much more reliably (generally and as an agent tool) than the Atlassian MCP server. For example, the Atlassian MCP server has weird auth issues ask the time where it will just fail to auth in a session. Atlassian publishes both officially,

I definitely agree with you, but it’s probably a little apples and oranges. MCP server is a one stop shop for discovering “tools”. To leverage a CLI tool “from scratch”, your agent has to do a web search to find if a CLI tool even exists, figure out how to install it, install it. Not saying those are impossible, but it’s way less automated and “deterministic” than what MCP provides.

I don't quite follow your meaning. Are you referring to an MCP registry of some kind, that the agent would operate itself to discover and install new tools? I would say that is a separate concern from the tool form factor itself. Also, there are CLI-focused solutions to this as well (e.g. brew, npm).

I see MCP with agentic runtimes the next step of Web API orchestration tools, which is kind of interesing, but also depressing in the sense we will keep writting less and less code.

I doesn't matter how great Rust happens to be over Python, if most of the modern coding will become voice/text prompts, and flow diagrams, orchestracting MCP tools.

Reply on news.ycombinator.com