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

41–50 of 146 posts

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

#41

Post by chuckmcp »

ehnto wrote: post #34
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…

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 AI companies more money.

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

#42

Post by the_mitsuhiko »

coverj wrote: post #36
faangguyindia wrote: post #16

Here is why MCP is bad, here i am trying to use MCP to build a simple node cli tool to fetch documentation from Context7: https://pastebin.com/raw/b4itvBu4 And it doesn't work even after 10 attemps. Fails and i've no idea why, meanwhile python code works without issues but i can't use that one as it conflicts with existing dependencies in aider, see: https://pastebin.com/TNpMRsb9 (working code after 5 failed attempts…

I'm interested why you aren't using the actual context7 MCP?

He is if you look at the code.

From my experience context7 just does not work, or at least does not help. I did plenty of experiments with it and that approach just does not go anywhere with the tools and models available today.

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

#43

Post by stanleydrew »

juanviera23 wrote: post #15

I agree MCP has these flaws, idk why we need MCP servers when LLMs can just connect to the existing API endpoint Started on working on an alternative protocol, which lets agents call native endpoints directly (HTTP/CLI/WebSocket) via “manuals” and “providers,” instead of spinning up a bespoke wrapper server: https://github.com/universal-tool-calling-protocol/python-ut... even connects to MCP servers if you take a loo…

> 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 that only needs to be written once.

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

#44

Post by DrewADesign »

losvedir wrote: post #25
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.

If you don't know what "MCP" stands for, then this article isn't for you. It's okay to load it, realize you're not the target audience, and move on. Or, spend some of your own time looking it up. This is like complaining that HTTP or API isn't explained.

I think this issue seems completely straightforward to many people… and their answer likely depends on if they know what MCP means.

The balance isn’t really clear cut. On one hand, MCP isn’t ubiquitous like, say, DNS or ancient like BSD. On the other, technical audiences can be expected to look up terms that are new to them. The point of a headline is to offer a terse summary, not an explanation, and adding three full words makes it less useful. However, that summary isn’t particularly useful if readers don’t know what the hell you’re talking about, either, and using jargon nearly guarantees that.

I think it’s just one of those damned-if-you-do/don’t situations.

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

#45

Post by orra »

stanleydrew wrote: post #40
AznHisoka wrote: post #27

Earlier quoted context omitted.

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?

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.

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

#46

Post by skerit »

I don't get it. Tools are a way to let LLMs do something via what is essentially an API. Is it limited? Yes, it is. By design.

Sure in some cases it might be overkill and letting the assistant write & execute plain code might be best. There are plenty of silly MCP servers out there.

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

#47

Post by throwaway314155 »

s1mplicissimus wrote: post #26

I tried doing the MCP approach with about 100 tools, but the agent picks the wrong tool a lot of the time and it seems to have gotten significantly worse the more tools I added. Any ideas how to deal with this? Is it one of those unsolvable XOR-like problems maybe?

You wind up having to explicitly tell it to use a tool and how to use it (defeating the point, mostly)

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

#48

Post by the_mitsuhiko »

s1mplicissimus wrote: post #26

I tried doing the MCP approach with about 100 tools, but the agent picks the wrong tool a lot of the time and it seems to have gotten significantly worse the more tools I added. Any ideas how to deal with this? Is it one of those unsolvable XOR-like problems maybe?

Remove most tools. After 30 tools it greatly regresses.

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

#49

Post by lsaferite »

grim_io wrote: post #18
klez wrote: post #5

Earlier quoted context omitted.

I, for one, still need to look it up every time I see it mentioned. Not everyone is talking or thinking about LLMs every waking minute.

Are you looking up what the abbreviation stands for, or what an MCP is? The first case doesn't matter at all if you already know what an MCP actually is. At least for the task of understanding the article.

MCP being the initialism for "Model Context Protocol", the specification released by Anthropic, generally dictates you shouldn't say "an MCP" but simply "MCP" or "the MCP". If you are referring to a concrete implementation of a part of MCP, then you likely meant to say "an MCP Server" or "an MCP Client".

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

#50

Post by lsaferite »

s1mplicissimus wrote: post #26

I tried doing the MCP approach with about 100 tools, but the agent picks the wrong tool a lot of the time and it seems to have gotten significantly worse the more tools I added. Any ideas how to deal with this? Is it one of those unsolvable XOR-like problems maybe?

There are many routes to a solution.

Two options (out of multiple):

- Have sub-agents with different subsets of tools. The main agent then delegates. - Have dedicated tools that let the main agent activate subsets of tools as needed.

Post reply on HN