Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MCP doesn't need tools, it needs code

lucumr.pocoo.org

Post reply on HN
Print view View original

91–100 of 146 posts

Re: MCP doesn't need tools, it needs code

#91

Post by mdaniel »

juanviera23 wrote: post #64
stanleydrew wrote: post #43

Earlier quoted context omitted.

> idk why we need MCP servers when LLMs can just connect to the existing API endpoint Because the LLM can't "just connect" to an existing API endpoint. It can produce input parameters for an API call, but you still need to implement the calling code. Implementing calling code for every API you want to offer the LLM is at minimum very annoying and often error-prone. MCP provides a consistent calling implementation tha…

yupp that's what UTCP does as well, standardizing the tool-calling (without needing an MCP server that adds extra security vulnerabilities)

heh, relevant to the "do what now?" thread, I didn't recognize that initialism https://github.com/universal-tool-calling-protocol

I'll spare the audience the implied XKCD link

Re: MCP doesn't need tools, it needs code

#92

Post by dragonwriter »

throwmeaway222 wrote: post #88

problem with MCP right now is that LLMs don't natively know what it is an LLM natively knows bash and how to run things MCP is forcing a weird set of non-normal rules that most of the writing of the web doesn't support. Most of the web writes a lot about bash and getting things done. Maybe in a few years LLMs will "natively" understand them, but I see MCP more as a buzzword right now.

> problem with MCP right now is that LLMs don't natively know what it is

Most models that it is used with natively know what tools are (they are trained with particular prompt formats for the use of arbitrary tools), and the model never sees MCP at all, it just sees tool definitions, or tool responses, in the format it expects in prompts. MCPs are a way to communicate information about tools to the toolchain running the LLM, when the LLM sees information that came via MCP it is indistinguishable from tools that might be built into the toolchain or provided by another mechanism.

Re: MCP doesn't need tools, it needs code

#93

Post by doikor »

spacebanana7 wrote: post #78
sam0x17 wrote: post #73

Yeah 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.

We have that in Scala with the MCP tools metals provides but convincing Claude to actually use the tools has been really painful.

https://scalameta.org/metals/blog/2025/05/13/strontium/#mcp-...

Re: MCP doesn't need tools, it needs code

#94

Post by mdaniel »

CharlieDigital wrote: post #19

A few weeks back, I actually started working on an MCP server that is designed to let the LLM generate and execute JavaScript in a safe, sandboxed C# runtime with Jint as the interpreter. https://github.com/CharlieDigital/runjs Lets the LLM safely generate and execute whatever code it needs. Bounded by statement count, memory limits, and runtime limits. It has a built in secrets manager API (so generated code can mak…

I don't meant to throw shade on your toy, but trying to get a prediction model to use a language that actively hates developers is a real roll-the-dice outcome

Re: MCP doesn't need tools, it needs code

#95

Post by sam0x17 »

mgsloan2 wrote: post #85
sam0x17 wrote: post #73

Yeah 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

I agree the current way tools are used seems inefficient. However there are some very good reasons they tend to operate on code instead of syntax trees: * Way way way more code in the training set. * Code is almost always a more concise representation. There has been work in the past training graph neural networks or transformers that get AST edge information. It seems like some sort of breakthrough (and tons of $) w…

Didn't want to bury the lead, but I've done a bunch of work with this myself. It goes fine as long as you give it both the textual representation and the ability to walk along the AST. You give it the raw source code, and then also give it the ability to ask a language server to move a cursor that walks along the AST, and then every time it makes a change you update the cursor location accordingly. You basically have a cursor in the text and a cursor in the AST and you keep them in sync so the LLM can't mess it up. If I ever have time I'll release something but right now just experimenting locally with it for my rust stuff

On the topic of LLMs understanding ASTs, they are also quite good at this. I've done a bunch of applications where you tell an LLM a novel grammar it's never seen before _in the system prompt_ and that plus a few translation examples is usually all it takes for it to learn fairly complex grammars. Combine that with a feedback loop between the LLM and a compiler for the grammar where you don't let it produce invalid sentences and when it does you just feed it back the compiler error, and you get a pretty robust system that can translate user input into valid sentences in an arbitrary grammar.

Re: MCP doesn't need tools, it needs code

#96

Post by mdaniel »

PhilipRoman wrote: post #58

Can't wait until I can buy a H100 with a DisplayPort input and USB keyboard and mouse output and just let it figure everything out.

I'm guessing I'm spoiling the joke, but why not just a Thunderbolt dock and plug the H100 into your existing machine, no DisplayPort interpretation required?

Although I could easily imagine the external robot(?) being a "hold my beer" to the interview cheat arms race

To extra ruin the joke, the 96GB versions seem to be going for $24,000 on ebay right now

Re: MCP doesn't need tools, it needs code

#97

Post by sam0x17 »

kelseyfrog wrote: post #82
sam0x17 wrote: post #73

Yeah 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

Structured output generally gives a nice performance boost, so I agree. Specifically, I'd love to see widespread structured output support for context free grammars. You get a few here and there - vLLM for example. Most LLMs as a service only support JSON output which is better than nothing but doesn't cover this case at all. Something with semantic analysis - scope informed output, would be a cherry on the top, but…

Yeah see my other comment above, I've done it with arbitrary grammars, works quite well, don't know why this isn't more widespread

Re: MCP doesn't need tools, it needs code

#98

Post by throwmeaway222 »

dragonwriter wrote: post #92
throwmeaway222 wrote: post #88

problem with MCP right now is that LLMs don't natively know what it is an LLM natively knows bash and how to run things MCP is forcing a weird set of non-normal rules that most of the writing of the web doesn't support. Most of the web writes a lot about bash and getting things done. Maybe in a few years LLMs will "natively" understand them, but I see MCP more as a buzzword right now.

> problem with MCP right now is that LLMs don't natively know what it is Most models that it is used with natively know what tools are (they are trained with particular prompt formats for the use of arbitrary tools), and the model never sees MCP at all, it just sees tool definitions, or tool responses, in the format it expects in prompts. MCPs are a way to communicate information about tools to the toolchain running…

No that's not what I'm saying. If you tell an LLM that you need a report on a specific member of congress and provide a prompt saying you can use bash tools like grep/curl/ping/git/etc... just return bash then a formatted code block

Or you can use fetch_record followed by a formatted code block of the name of a google search you want to perform.

The LLM will likely use bash and curl because it NATIVELY knows what it is and is capable of, while this other tool you have to feed it all these parameters that it is not used to.

I'm not saying go ahead and throw that in chatgpt, I'm talking from experience at our company using MCP vs bashable stuff, it keeps ignoring the other tools.

Re: MCP doesn't need tools, it needs code

#99

Post by fny »

sam0x17 wrote: post #73

Yeah 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

Strings are a universal interface with no dependencies. You can do anything in any language across any number of files. Any other abstraction heavily restricts what you can accomplish.

Also, LLMs aren't trained on ASTs, they're trained on strings -- just like programmers.

Re: MCP doesn't need tools, it needs code

#100

Post by skydhash »

sam0x17 wrote: post #73

Yeah 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

AST is only half of the picture. Semantics (aka the action taken by the abstract machine) are what’s important. What code helps with is identifying patterns which helps in code generation (defmacro and api services generations) because it’s the primary interface. AST is implementation detail.
Post reply on HN