Live data from Hacker News

What if you don't need MCP at all?

mariozechner.at

161–170 of 194 posts

Re: What if you don't need MCP at all?

#161

Earlier quoted context omitted.

Probably a good read for you to start with: https://raz.sh/blog/2025-05-02_a_critical_look_at_mcp There are tons of articles detailing the problems if you are genuinely interested. Notice you couldn't technically point to anything to support your statements, but instead had to revert to religious zealotry and apologetics -- which has no place on this forum. >be objective about what MCP is and is not meant to do and d…

To get this out of the way, you are an unpleasant person, but that doesn't mean you should be ignored though, so I'll reply. > you couldn't technically point to anything to support your statements, but instead had to revert to religious zealotry and apologetics > You wrote all of that just to counter your own stated position, because I think at some fundamental level you realize how non-sense it is. You need to be sp…

>To get this out of the way, you are an unpleasant person

You are clearly very emotional about this, for whatever reason. But again it has no place on this forum.

>I would point out that I haven't see one link in all of your railing against MCP until this very response.

Because everything I've stated are fundamental facts about the technology. If you need sources for it, that means you are missing elementary concepts.

>After meandering

They literally point out several issues with the protocol that hamper observability.

You're being very verbose but not saying much and ignoring when things are directly answered for you. That's being generous.

Your position is like someone claiming lemongrass supplements cures COVID. Everyone is rightly pointing out that it's a placebo at best. Then your position is "well point out all the ways it DOESN'T help, everyone is doing it!"

Which is a really not-smart position to hold, to say the least.

Re: What if you don't need MCP at all?

#162

Earlier quoted context omitted.

To get this out of the way, you are an unpleasant person, but that doesn't mean you should be ignored though, so I'll reply. > you couldn't technically point to anything to support your statements, but instead had to revert to religious zealotry and apologetics > You wrote all of that just to counter your own stated position, because I think at some fundamental level you realize how non-sense it is. You need to be sp…

>To get this out of the way, you are an unpleasant person You are clearly very emotional about this, for whatever reason. But again it has no place on this forum. >I would point out that I haven't see one link in all of your railing against MCP until this very response. Because everything I've stated are fundamental facts about the technology. If you need sources for it, that means you are missing elementary concepts…

The absurdity of this response is astounding. As it's clear you have no actual interest is an honest discussion I'll just drop off here and leave you to your echo chamber.

Re: What if you don't need MCP at all?

#163

Earlier quoted context omitted.

Maybe this is a dumb question, but isn't this solved by publishing good API docs, and then pointing the LLM to those docs as a training resource?

>but isn't this solved by publishing good API docs, and then pointing the LLM to those docs as a training resource? Yes. It's not a dumb question. The situation is so dumb you feel like an idiot for asking the obvious question. But it's the right question to ask. Also you don't need to "train" the LLM on those resources. All major models have function / tool calling built in. Either create your own readme.txt with ex…

You keep saying that major models have "tool calling built in". And that by giving them context about available APIs, the LLM can "use the API".

But you don't explain, in any of your comments, precisely how an LLM in practice is able to itself invoke an API function. Could you explain how?

A model is typically distributed as a set of parameters, interpreted by an inference framework (such as llama.cpp), and not as a standalone application that understands how to invoke external functions.

So I am very keen to understand how these "major models" would invoke a function in the absence of a chassis container application (like Claude Code, that tells the model, via a prompt prefix, what tokens the model should emit to trigger a function, and which on detection of those tokens invokes the function on the model's behalf - which is not at all the same thing as the model invoking the function itself).

Just a high level explanation of how you are saying it works would be most illuminating.

Re: What if you don't need MCP at all?

#164

Earlier quoted context omitted.

Claude just reads the SKILL.md frontmatter into initial context and when the instructions match it reads the rest of the SKILL.md. Every LLM can do that.

If it's such a thing that every model already can support it and you don't need to do anything with it, why is it even a feature?

To be fair other providers have to implement reading a skill directory and only the frontmatter of the SKILL.md and read more of it when needed. But it's a LOT simpler than implementing MCP.

Re: What if you don't need MCP at all?

#165
post #125

Earlier quoted context omitted.

The mcp part is not essential for the actual controlling of the applications. You could “rip out” the mcp functionality and replace it with something else. The only reason why the authors chose mcp is most likely that it was the first and therefore most common plugin interface for llm tools.

MCP literally is the "something else", if you have a better idea in mind, now is the time to bring it out before the MCP train is going too fast to catch up.

(Not OP)

This is pretty well established. See for example:

https://www.anthropic.com/engineering/code-execution-with-mc...

https://blog.cloudflare.com/code-mode/

Code (including shell scripting) allows the LLM to manipulate the results programmatically, which allows for filtering, aggregation and other logic to occur without multiple round trips between the agent and tool(s). This results in substantially less token usage, which means less compute waste, less cost, and less confusion/"hallucination" on the LLM's part.

If one comes to the same conclusion that many others have (including CloudFlare) that code should be the means by which LLMs interface with the world, then why not skip writing an MCP server and instead just write a command-line program and/or library (as well as any public API necessary)?

Re: What if you don't need MCP at all?

#166
post #145

Earlier quoted context omitted.

Actually, MCP wastes a lot of tokens when compared to regular tool calling. You might not notice it on more trendy models with large contexts, but for those of us trying to use locked down/local/cheap models it makes very little sense. Also, MCP creates a new problem: providing the model with too much context when trying to combine tools across multiple servers. It works OK with small, very focused servers (like help…

Is that just bad implementation? Where are the wasted tokens? I noticed your second issue, but to me it's just from bad implementation. For some reason people keep exposing generic overlapping tools from multiple MCP servers. I don't know that MCP causes this issue, any vendor offering a "tools API" if they shove to many APIs it would bloat things up.

> Is that just bad implementation? Where are the wasted tokens?

How wouldn't it be wasteful?

I'll try to summarize a couple sources:

https://www.anthropic.com/engineering/code-execution-with-mc...

https://blog.cloudflare.com/code-mode/

Here's what Anthropic has to say about it: As MCP usage scales, there are two common patterns that can increase agent cost and latency:

    Tool definitions overload the context window;
    Intermediate tool results consume additional tokens.
    
    [...]
    
    Tool descriptions occupy more context window space, increasing response time and costs. In cases where agents are connected to thousands of tools, they’ll need to process hundreds of thousands of tokens before reading a request.
    
    [...]
    
    Most MCP clients allow models to directly call MCP tools. For example, you might ask your agent: "Download my meeting transcript from Google Drive and attach it to the Salesforce lead."
    
    The model will make calls like:
    
      TOOL CALL: gdrive.getDocument(documentId: "abc123")
              → returns "Discussed Q4 goals...\n[full transcript text]"
                 (loaded into model context)
      
      TOOL CALL: salesforce.updateRecord(
         objectType: "SalesMeeting",
         recordId: "00Q5f000001abcXYZ",
           data: { "Notes": "Discussed Q4 goals...\n[full transcript text written out]" }
        )
        (model needs to write entire transcript into context again)
    
    Every intermediate result must pass through the model. In this example, the full call transcript flows through twice. For a 2-hour sales meeting, that could mean processing an additional 50,000 tokens. Even larger documents may exceed context window limits, breaking the workflow.
    
    With large documents or complex data structures, models may be more likely to make mistakes when copying data between tool calls.

Now, if you were to instead have the LLM write code, that code can perform whatever filtering/aggregation/transformation etc that it needs, without having to round-trip from LLM to tool(s), back and forth, and the only tokens that are consumed are those of the final result. What happens with MCP? All of the text of each MCP call is flooded into the context, only for the LLM to have to make sense of what it just read to then either regurgitate that out into a file to post process (very likely with differences/"hallucinations" slipped in), or in the usual case (I'm personifying the LLM here for rhetorical purposes) it simply tries to reason about what it read to give you the filtered/aggregated/transformed/etc result you're looking for -- again, very likely with mistakes made.

Re: What if you don't need MCP at all?

#167
Admittedly, the scripts+README approach works well for individual setups and is extremely token-efficient, since it only loads a tiny README and the model can infer how to run the scripts. But that convenience depends on a single local environment—one shell, one OS, etc.

MCP is aimed at the opposite scenario: distributing tools to many users without relying on their environments. It provides automatic tool discovery, a server boundary that isolates credentials, and strict control over exposed capabilities. Its heavier JSON-schema definitions exist because they’re machine-readable contracts that behave consistently across clients, whereas CLI tools vary drastically across systems. So while MCP adds context overhead, it solves portability and distribution problems that scripts simply can’t.

Re: What if you don't need MCP at all?

#168

Earlier quoted context omitted.

>it is "known" at least as much as any other protocol. No. It is not. Please understand what the LLM's are doing. Claude nor ChatGPT nor any major model knows what MCP is. They know how to function & tool call. They have zero trained data on MCP. That is a factual statement, not an opinion.

That is an easily falsifiable statement. If I ask ChatGPT or Claude what MCP is Model Context Protocol comes up, and furthermore it can clearly explain what MCP does. That seems unlikely to be a coincidental hallucination.

You're misinterpreting OP.

OP is saying that the models have not been trained on particular MCP use, which is why MCP servers serve up tool descriptions, which are fed to the LLM just like any other text -- that is, these descriptions consume tokens and take up precious context.

Here's a representative example, taken from a real world need I had a week ago. I want to port a code base from one language to another (ReasonML to TypeScript, for various reasons). I figure the best way to go about this would be to topologically sort the files by their dependencies, so I can start with porting files with absolutely zero imports, then port files where the only dependencies are on files I've already ported, and so on. Let's suppose I want to use Claude Code to help with this, just to make the choice of agent concrete.

How should I go about this?

The overhead of the MCP approach would be analogous to trying to cram all of the relevant files into the context, and asking Claude to sort them. Even if the context window is sufficient, that doesn't matter because I don't want Claude to "try its best" to give me the topological sort straight from its nondeterministic LLM "head".

So what did I do?

I gave it enough information about how to consult build metadata files to derive the dependency graph, and then had it write a Python script. The LLM is already trained on a massive corpus of Python code, so there's no need to spoon feed it "here's such and such standard library function", or "here's the basic Python syntax", etc -- it already "knows" that. No MCP tool descriptions required.

And then Claude code spits out a script that, yes, I could have written myself, but it does it in maybe 1 minute total of my time. I can skim the script and make sure that it does exactly what it should be doing. Given that this is code, and not nondeterministic wishy washy LLM "reasoning", I know that the result is both deterministic and correct. The total token usage is tiny.

If you look at what Anthropic and CloudFlare have to say on the matter (see https://www.anthropic.com/engineering/code-execution-with-mc... and https://blog.cloudflare.com/code-mode/), it's basically what I've described, but without explicitly telling the LLM to write a script / reviewing that script.

If you have the LLM write code to interface with the world, it can leverage its training in that code, and the code itself will do what code does (precisely what it was configured to do), and the only tokens consumed will be the final result.

MCP is incredibly wasteful and provides more opportunities for LLMs to make mistakes and/or get confused.

Re: What if you don't need MCP at all?

#169
post #90

Earlier quoted context omitted.

probably easier to just tell people: You want MCP? Add a "description" field to your rest API that describes how to call it. That's all it's doing. Just plain ole context pollution. World could be better served by continuing to build out the APIs that exist.

Sometimes the actions you want to perform does not map cleanly into one or two API calls, or would be too messy to assume correct parsing. Maybe your UI is fine POSTing to /users and PUTing to /groups or whatever but giving the LLM a direct CreateUserAndAddToGroup action simplifies the task and keeps context cleaner.

This is very true. But why stop there?

Imagine a future where we have an evolved version of MCP -- call it MCP++.

In MCP++, instead of having to implement a finite list of specialized variants like CreateUserAndAddToGroup, imagine MCP++ has a way to to feed the desired logic (create user, then add that user to $GROUP) directly to the endpoint. So there would be something like a POST /exec endpoint. And then the /exec endpoint can run the code (maybe it's WASM for something)...

Wait a minute! We already have this. It's called programming.

You could have the LLM write code, so that any pipelining (like your example), aggregation, filtering, or other transformation happens in that code, and the LLM only needs to spend the output tokens to write the code, and the only input tokens consumed is the final result.

I definitely am not the first person to suggest this:

https://www.anthropic.com/engineering/code-execution-with-mc...

https://blog.cloudflare.com/code-mode/

... but I can say that, as soon as I read about MCP, my first thought was "why?"

MCP is wasteful.

If you want LLMs to interact with your software/service, write a library, let the scrapers scrape that code so that future LLM revisions have the library "baked into it" (so you no longer need to spam the context with MCP tool descriptions), and let the LLM write code, which it already "knows" how to do.

What if your library is too new, or has a revision, though?

That's already a solved problem -- you do what you'd do in any other case where you want the LLM to write code for you: point it at the docs / codebase.

Re: What if you don't need MCP at all?

#170
post #83
post #43

So I don't disagree with any of the criticisms of MCPs but no one here has mentioned why they are useful, and I'm not sure that everyone is aware that MCP is actually just a wrapper over existing cli/API: 1. Claude Code is aware of what MCPs it has access to at all times. 2. Adding an MCP is like adding to the agent's actuators/vocabulary/tools because unlike cli tools or APIs you don't have to constantly remind it w…

> 3. This effect is _significantly_ stronger than putting info about available API/cli into CLAUDE.md. What? Why? > unlike cli tools or APIs you don't have to constantly remind it what MCPs it has available I think I'm missing something, because I thought this is what MCP does, literally. It just injects the instructions about what tools it has and how to use them into the context window. With MCP it just does it for…

You are correct.

I think many here have no idea what exactly MCP is, and think it's some sort of magic sauce that transcends how LLMs usually work.

    “But Brawndo has what plants crave! It's got electrolytes! '...Okay - what are electrolytes? Do you know? Yeah. It's what they use to make Brawndo.' But why do they use them in Brawndo? What do they do?''They're part of what plants crave.'But why do plants crave them?'Because plants crave Brawndo, and Brawndo has electrolytes.”
    ― Idiocracy Movie
Post reply on HN