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

81–90 of 146 posts

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

#81

Post by ctoth »

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.

Which is why I wrote a code extractor MCP which uses Tree-sitter -- surely something that directly connects MCP with LSP would be better but the one bridge layer I found for that seemed unmaintained. I don't love my implementation which is why I'm not linking to it.

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

#82

Post by kelseyfrog »

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 while technically possible, I don't see arriving anytime soon. But hey - maybe an opportunity for product differentiation.

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

#83

Post by TZubiri »

jumploops wrote: post #20

The 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…

All of this superhuman intelligence and we still haven't solved the "CALL MOM" demo

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

#84

Post by turnsout »

> One surprisingly useful way of running an MCP server is to make it an MCP server with a single tool (the ubertool) which is just a Python interpreter that runs eval() with retained state.

Wow, you better be sure you have that Python environment locked down.

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

#85

Post by mgsloan2 »

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 $) would be needed for those approaches to have any chance of surpassing leading LLMs.

Experimentally having agents use ast-grep seems to work pretty well. So, still representing a everything as code, but using a syntax aware search replace tool.

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

#86

Post by dragonwriter »

faangguyindia wrote: post #70
jumploops wrote: post #20

The 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…

> what do i need MCP and other agents for?

For your use cases, maybe you don't. Not every use case for an LLM is identical to your coding usage pattern.

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

#87

Post by mdaniel »

cgriswald wrote: post #33
yxhuvud wrote: post #2

First rule of writing about something that can be abbreviated: First have some explanation so people have an idea of what you are talking about. Either type out what the abbreviation stands for, have an explanation or at least a link to some other page that explain what is going on. EDIT: This has since been fixed in link, so it is outdated.

Just so folks who want to do this know, the proper way to introduce an initialism is to use the full term on first use and put the initialism in parentheses. Thereafter just use the initialism. Always consider your audience, but for most non-casual writing it’s a good default for a variety of reasons.

You're welcome to do that in print media, but on the web the proper way is the abbr element with its title attribute https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...>. Related to the distinction, I'd bet $1 there's some fancy CSS that would actually expand the definition under @media print

I can attest the abbr is also mobile friendly, although I am for sure open to each browser doing its own UI hinting that a long-press is available for the term

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

#88

Post by throwmeaway222 »

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.

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

#89

Post by dragonwriter »

oooyay wrote: post #61
jumploops wrote: post #20

The 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…

In my uneducated experience MCP is nothing more than a really well structured prompt. You can call out tools for the agent or model to use in the instruction prompt, especially for certain project. I define workflows that trigger for certain files being changed in Cursor and usually the model can run uninterrupted for a while.

> In my uneducated experience MCP is nothing more than a really well structured prompt.

MCP isn't a prompt (though prompts are a resource an MCP server can provide). An MCP client that is also the direct LLM manager toolchain has to map the data from MCP servers tool/prompt/resource definition into the prompt, and it usually does so using prompt templates that are defined for each model, usually by the model provider. So the meaningful part of having a “really well-structured prompt” part isn't from MCP at all, just something that already exists that the MCP client leverages.

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

#90

Post by jonfw »

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…

> * Way way way more code in the training set.

Why not convert the training code to AST?

Post reply on HN