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

111–120 of 146 posts

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

#111

Post by [deleted] »

fny wrote: post #99
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.

[deleted]

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

#112

Post by turnsout »

starkparker wrote: post #108
turnsout wrote: post #84

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

yeah, check out the article's "Security is a Sham" heading that explicitly covers why the author doesn't really give a shit

Yeah, I saw that, it's still just wild. I guess "YOLO" is one response to the difficulties of securing endpoints.

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

#113

Post by p_j_w »

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 think you've hit the nail on the head here.

After being pleasantly surprised at how well an AI did at a task I asked of it a few months ago that I thought was much more complicated, I was amused at how badly it did when I asked it to refactor some code to change variable names in one single source file to match a particular coding standard. After doing the work that a good junior developer might have needed a couple of days for, it failed hard at refactoring, working more at the level of a high school freshman.

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

#114

Post by MarkMarine »

sam0x17 wrote: post #95
mgsloan2 wrote: post #85

Earlier quoted context omitted.

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…

I’d love to see how you’re giving this interface to the LLM

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

#115

Post by anon7000 »

fny wrote: post #99
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.

Exactly. LLMs are trained on huge amounts of bash scripts. They “know” how to use grep/awk/whatever. ASTs are, I assume, not really part of that training data. How would they know how to work well with on? LLMs are trained on what humans do to code. Yes, I assume down the road someone will train more efficient versions that can work more closely with the machine. But LLMs work as well as they do because they have a large body of “sed” statements in their statistical models

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

#116

Post by tough »

ctoth wrote: post #81
spacebanana7 wrote: post #78

Earlier quoted context omitted.

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.

both opencode and charm's crush support LSP's and MCP's as configs

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

#117

Post by 0x457 »

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

If you look API exposed by LSP you would understand why. It's very hard to use LSP outside an editor because a lot of it is "where is a symbol in file X on line Y between these two columns is used"

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

#118

Post by otterley »

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)

There's still an agent between the user and the LLM. The model isn't making the tool calls and has no mechanism of its own to accomplish this.

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

#120

Post by limagnolia »

PhilippGille wrote: post #38
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…

Given the security issues that come with MCP [1], I think it's a bad idea to call MCP a "guardrail/sandbox". Also, there are MCP servers that allow running any command in your terminal, including apt install / brew install etc. [1] https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/

The security issues aren't so much with "MCP", they are with folks giving access to LLMs to do things they don't want those LLMs to be able to do. By describing MCP as guardrails, you might convince some of the nimkumpoops to think about where they place those guardrails.
Post reply on HN