This is how tools are implemented in latest Gemini models like gemini-2.5-flash-preview-native-audio-dialog: the LLM has access to a code execution tool that can run code in python and all tools are available in a default_api class
MCP doesn't need tools, it needs code
71–80 of 146 posts
Re: MCP doesn't need tools, it needs code
#72Earlier quoted context omitted.
If you're running one of the popular coding agents, they can run commands in bash which is more or less access to the infinite space of tooling I myself use to do my job. I even use it to troubleshoot issues with my linux laptop that in the past I would totally have done myself, but can't be bothered. Which led to the most relatable AI moment I have encountered: "This is frustrating" - Claude Code thought, after 6 tr…
Even with all of the CLI tools at its disposal (e.g. sed), it doesn’t consistently use them to make updates as it could (e.g. widespread text replacement). Once in a blue moon, an LLM will choose some tool and use it in a way that they almost never do in a really smart way to handle a problem. Most of the time it seems optimized for using too many individual things, probably both for safety and because it makes the A…
It's because the broader the set of "tools" the worse the model gets at utilizing them effectively. By constraining the use you ensure a much higher % of correct usage.
Re: MCP doesn't need tools, it needs code
#73Yeah I quite agree with this take. I don't understand why editors aren't utilizing language servers more for making changes. Crazy to see agents running grep and sed and awk and stuff, all of that should be provided through a very efficient cursor-based interface by the editor itself.
And for most languages, they shouldn't even be operating on strings, they should be operating on token streams and ASTs
Re: MCP doesn't need tools, it needs code
#74Earlier quoted context omitted.
> when LLMs can just connect to the existing API endpoint The primary differentiator is that MCP includes endpoint discovery. You tell the LLM about the general location of the MCP tool, and it can figure out what capabilities that tool offers immediately. And when the tool updates, the LLM instantly re-learns the updated capability. The rest of it is needlessly complicated (IMO) and could just be a bog standard HTTP…
How is this different than just giving the LLM an OpenAI spec in the prompt? Does it somehow get around the huge amount of input tokens that would require?
Because again, discoverability is baked into the protocol. OpenAI specs are great, but they are: optional, change over time, and have a very different target use case.
MCP discoverability is designed to be ingested by an LLM, rather than used to implement an API client like OAI specs. MCP tools describe themselves to the LLM in terms of what they can do, rather than what their API contract is.
It also removes the responsibility of having to inject the correct version of the spec into the prompt from the user, and moves it into the protocol.
Re: MCP doesn't need tools, it needs code
#75Earlier quoted context omitted.
Technically it's not really much different from just giving the LLM an OpenAPI spec. The actual thing that's different is that an OpenAPI spec is meant to be an exhaustive list of every endpoint and every parameter you could ever use. Whereas an MCP server, as a proxy to an API, tends to offer a curated set of tools and might even compose multiple API calls into a single tool.
It's a farce, though. We're told these LLMs can already perform our jobs, so why should they need something curated? A human developer often gets given a dump of information (or nothing at all), and has to figure out what works and what is important.
You should try and untangle what you read online about LLMs from the actual technical discussion that's taking place here.
Everyone in this thread is aware that LLMs aren't performing our jobs.
Re: MCP doesn't need tools, it needs code
#76What this is saying is again, that MCP is not a protocol. Which is the point of MCP, making it essentially worthless because it doesn't define actual behavioral rules, it can only describe existing rules informally.
This is because defining a formal system, that can do everything MCP promises to enable, is a logical impossibility.
Re: MCP doesn't need tools, it needs code
#77codeact is a really interesting area to explore. I expanded upon the JS platform I started sketching out in https://www.youtube.com/watch?v=J3oJqan2Gv8 . LLMs know a million APIs out of the box and have no trouble picking more up through context, yet struggle once you give them a few tools. In fact just enabling a single tool definition "degrades" the vibes of the model.
Give them an eval() with a couple of useful libraries (say, treesitter), and they are able not only to use it well, but to write their own "tools" (functions) and save massively on tokens.
They also allow you to build "ephemeral" apps, because who wants to wait for tokens to stream and a LLM to interpret the result when you could do most tasks with a normal UI, only jumping into the LLM when fuzziness is required.
Most of my work on this is sadly private right now, but here's a few repos github.com/go-go-golems/jesus https://github.com/go-go-golems/go-go-goja that are the foundation.
Re: MCP doesn't need tools, it needs code
#78Yeah I quite agree with this take. I don't understand why editors aren't utilizing language servers more for making changes. Crazy to see agents running grep and sed and awk and stuff, all of that should be provided through a very efficient cursor-based interface by the editor itself. And for most languages, they shouldn't even be operating on strings, they should be operating on token streams and ASTs
It's so weird that codex/claude code will manually read through sometimes dozens of files in a project because they have no easy way to ask the editor to "Find Usages".
Even though efficient use of CLI tools might make the token burn not too bad, the models will still need to spent extra effort thinking about references in comments, readmes, and method overloading.
Re: MCP doesn't need tools, it needs code
#79The promise of MCP is that it “connects your models with the world”[0]. In my experience, it’s actually quite the opposite. By giving an LLM a set of tools, 30 in the Playwright case from the article, you’re essentially restricting what it can do. In this sense, MCP is more of a guardrail/sandbox for an LLM, rather than a superpower (you must choose one of these Stripe commands!). This is good for some cases, where y…
My coding agent just has access to these functions: ask> what all tools u have? I have access to the following tools: 1 code_search: Searches for a pattern in the codebase using ripgrep. 2 extract_code: Extracts a portion of code from a file based on a line range. 3 file_operations: Performs various file operations like ls, tree, find, diff, date, mkdir, create_file. 4 find_all_references: Finds all references to a s…
Which coding agent are you using?
Re: MCP doesn't need tools, it needs code
#80Earlier quoted context omitted.
MCP is Model Context Protocol, welcome to the land of the living. Make sure you turn the lights off to the cave. :) It’s pretty well known by now what MCP stands for, unless you were referring to something else…
Master Control Program: https://www.youtube.com/watch?v=atmQjQjoZCQ
Mysteriously Convoluted Protocol ...to get LLM's to do tool calling. I do agree that direct code execution in an enclave is the way to go.