Most active commenters
  • whoknowsidont(13)
  • cstrahan(8)
  • paulddraper(6)
  • didibus(5)

←back to thread

237 points jdkee | 69 comments | | HN request time: 0.534s | source | bottom
1. whoknowsidont ◴[] No.45948637[source]
MCP was a really shitty attempt at building a plugin framework that was vague enough to lure people into and then allow other companies to build plugin platforms to take care of the MCP non-sense.

"What is MCP, what does it bring to the table? Who knows. What does it do? The LLM stuff! Pay us $10 a month thanks!"

LLM's have function / tool calling built into them. No major models have any direct knowledge of MCP.

Not only do you not need MCP, but you should actively avoid using it.

Stick with tried and proven API standards that are actually observable and secure and let your models/agents directly interact with those API endpoints.

replies(8): >>45948748 #>>45949815 #>>45950303 #>>45950716 #>>45950817 #>>45951274 #>>45951510 #>>45951951 #
2. cyanydeez ◴[] No.45948748[source]
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.

replies(6): >>45949052 #>>45949068 #>>45950107 #>>45950478 #>>45951105 #>>45951859 #
3. tacticus ◴[] No.45949052[source]
> Add a "description" field to your rest API that describes how to call it.

Isn't that swagger\grpc etc?

4. jes5199 ◴[] No.45949068[source]
yesss, and OpenAI tried this first when they were going to do a “GPT store”. But REST APIs tend to be complicated because they’re supporting apps. MCP, when it works, is very simple functions

in practice it seems like command line tools work better than either of those approaches

replies(1): >>45949514 #
5. CuriouslyC ◴[] No.45949514{3}[source]
Command line tools are my preference just because they're also very useful to humans. I think providing agents function libraries and letting them compose in a repl works about as well but is higher friction due env management.
6. voidhorse ◴[] No.45949815[source]
Yeah there's no there there when it comes to MCP. It's crazy to me that the world bought into the idea when the "spec" literally boils down to "have your server give the LLM some json". Just illustrates how powerful it is to attach names to things, especially in a hypestorm in which everyone is already frothing at the mouth and reason is hard to come by. Give people some word they can utter to help them sound like they're on the "bleeding edge" and they'll buy into it even if it's totally pointless.
replies(2): >>45949936 #>>45960553 #
7. tptacek ◴[] No.45949936[source]
"Have your XYZ give the LLM some JSON" is pretty close to how all tool calling works with or without MCP.
replies(2): >>45950118 #>>45950384 #
8. mycall ◴[] No.45950107[source]
Also, keep your api small as all the tool call, DTOs and user messages (e.g. workflow recipes) add up to big context windows and accuracy confusion, at least in the latest models. I hope that gets resolved.
9. mycall ◴[] No.45950118{3}[source]
Markdown is for output too.
10. paulddraper ◴[] No.45950303[source]
> No major models have any direct knowledge of MCP.

Claude and ChatGPT both support MCP, as does the OpenAI Agents SDK.

(If you mean the LLM itself, it is "known" at least as much as any other protocol. For whatever that means.)

replies(1): >>45950488 #
11. what-the-grump ◴[] No.45950384{3}[source]
What next you are going to tell me rest and async are implemented in code?! And not just willed into existence by the compiler!
12. pests ◴[] No.45950478[source]
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.
replies(1): >>45957677 #
13. whoknowsidont ◴[] No.45950488[source]
>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.

replies(6): >>45950540 #>>45950541 #>>45950569 #>>45950763 #>>45950803 #>>45951338 #
14. choilive ◴[] No.45950540{3}[source]
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.
replies(2): >>45950578 #>>45957524 #
15. Bockit ◴[] No.45950541{3}[source]
This is probably a semantics problem. You’re right. The models don’t know how to mcp. The harness they run in does though (Claude code, Claude desktop, etc), and dynamically exposes mcp tools as tool calls.
replies(2): >>45950559 #>>45950581 #
16. llbbdd ◴[] No.45950559{4}[source]
HN loves inventing semantics problems around AI. It's gotten really, really annoying and I'm not sure the people doing it are even close to understanding it.
17. numpad0 ◴[] No.45950569{3}[source]
(pedantry)it's something humans are talking about a lot, so up-to-date models do know about it...
replies(1): >>45950600 #
18. whoknowsidont ◴[] No.45950578{4}[source]
Training data =/= web search

Both ChatGPT and Claude will perform web searches when you ask them a question, which the fact that you got this confused is ironically topical.

But you're still misunderstanding the principle point because at some point these models will undoubtedly have access to that data and be trained on it.

But they didn't need to be, because LLM function & tool calling is already trained on these models and MCP does not augment this functionality in any way.

replies(2): >>45950678 #>>46003517 #
19. whoknowsidont ◴[] No.45950581{4}[source]
>dynamically exposes mcp tools as tool calls.

It doesn't even do that. It's not magic.

20. whoknowsidont ◴[] No.45950600{4}[source]
Most likely! It's hard to qualify which specific models and version I'm talking about because they're constantly being updated.

But the point is that function & tool calling was already built in. If you take a model from before "MCP" was even referenced on the web it will still _PERFECTLY_ interact with not only other MCP servers and clients but any other API as well.

21. davidcbc ◴[] No.45950678{5}[source]
Claude gives me a lengthy explanation of MCP with web search disabled
replies(1): >>45950731 #
22. didibus ◴[] No.45950716[source]
> MCP was a really shitty attempt at building a plugin framework

Can you go more in depth? The protocol is relatively simple, what about it you feel is "shitty" as a plugin framework?

replies(1): >>45950814 #
23. whoknowsidont ◴[] No.45950731{6}[source]
Great! It's still irrelevant.
24. cookiengineer ◴[] No.45950763{3}[source]
> That is a factual statement,

I think most people, even most devs, don't actually know how crappy an MCP client is built, and that it's essentially an MITM approach and that the client sends the LLM on the other end a crappy pretext of what tools are mounted and how to call their methods in a JSON, and then tries to intelligently guess what response was a tool call.

And that intelligent guess is where it gets interesting for pentesting, because you cannot guess anything failsafe.

25. paulddraper ◴[] No.45950803{3}[source]
> They have zero trained data on MCP.

They have significant data trained on MCP.

> They know how to function & tool call.

Right. You can either use MCP to transmit those tool calls, or you can create some other interface.

replies(1): >>45950854 #
26. paulddraper ◴[] No.45950814[source]
The hate for MCP here is absurd.

It's JSON-RPC, with some descriptors.

And some comments about OAuth 2.

The value is in the consensus. You can make a tool that agents can connect to with no apriori knowledge.

replies(3): >>45950849 #>>45953015 #>>45954572 #
27. jcelerier ◴[] No.45950817[source]
> LLM's have function / tool calling built into them. No major models have any direct knowledge of MCP.

but the major user interfaces for operating LLMs do and that's what matters

> Not only do you not need MCP, but you should actively avoid using it.

> Stick with tried and proven API standards that are actually observable and secure and let your models/agents directly interact with those API endpoints.

so what's the proven and standard API I can use to interact with ableton live? blender? unity3d? photoshop?

replies(1): >>45950829 #
28. whoknowsidont ◴[] No.45950849{3}[source]
>It's JSON-RPC, with some descriptors.

That's not even true. It defines the lifecycle of tool calling.

JSON-RPC with some descriptors would have been fine and amazing.

replies(2): >>45952839 #>>45954388 #
29. whoknowsidont ◴[] No.45950854{4}[source]
>They have significant data trained on MCP.

No they don't lol.

replies(1): >>45954410 #
30. nilslice ◴[] No.45951039{3}[source]
What do all of the links below have in common? Do you know of another way you can control all of those applications via LLMs? Computer use?

https://github.com/ahujasid/ableton-mcp

https://github.com/ahujasid/blender-mcp

https://github.com/CoplayDev/unity-mcp

https://github.com/mikechambers/adb-mcp

replies(2): >>45951271 #>>45955037 #
31. EagnaIonat ◴[] No.45951105[source]
> Just plain ole context pollution.

It would normally be a second context window to figure out what tool / agent to run.

My only quibble with MCP is in the usual AI bandwagon people are implementing for FOMO than business value. My experience is likely anecdotal though.

32. growt ◴[] No.45951271{4}[source]
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.
replies(3): >>45951322 #>>45951403 #>>45951426 #
33. timClicks ◴[] No.45951274[source]
MCP is an example of "worse is better". Everyone knows that it's not very good, but it gets the job done.
34. Zetaphor ◴[] No.45951322{5}[source]
Isn't that the point they are making? MCP is useful because everyone is using it, not because it has a technical advantage over rolling your own solution. It won mindshare because of marketing and a large company pushing it.

I've actually taken to both approaches recently, using the mcp-client package to give me an interface to a wide array of prebuilt tools in my non-LLM application. I could have written or sourced 10 different connectors, or I can write one client interface and any tool I plug in shares the same standard interface as all the others.

35. ◴[] No.45951338{3}[source]
36. theshrike79 ◴[] No.45951403{5}[source]
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.
replies(1): >>45957037 #
37. TranquilMarmot ◴[] No.45951426{5}[source]
Unfortunately, most standards that we end up with are only standard because they're are widely used and not because they are the best or they make the most sense.
replies(1): >>45955046 #
38. block_dagger ◴[] No.45951510[source]
Perhaps you haven't used many MCP server, but those that I have used (GitHub, Atlassian, Glean, BuildKite, Figma, Google Workspace, etc) work very well. They teach an LLM how to do exactly what you're saying - "use the API standards...your models/agents directly interact with those API endpoints." Most MCP severs don't sit in between the LLM and the API endpoints, they just teach them how to use the tools and then the LLM calls the APIs directly as any HTTP client would. I find it works quite well and seems far better than manually maintaining rules or pointing at docs and installing CLI tools (like "gh" for GitHub) or using curl to interact with APIs from a terminal within a chat session.
replies(2): >>45955057 #>>45958326 #
39. blitzar ◴[] No.45951859[source]
> World could be better served by continuing to build out the APIs that exist.

before LLM's and MCP the world was depreciating or locking down APIs

40. pjmlp ◴[] No.45951951[source]
Fully agree, however we need to reach our KPIs and OKRs regarding AI adoption.
41. frumplestlatz ◴[] No.45952839{4}[source]
I’m struggling to understand where you’re coming from. Your hate for MCP seems grossly outsized relative to what it actually is.
42. manbitesdog ◴[] No.45953015{3}[source]
Things like OpenAPI have existed for 15 years now and they also offer standarization.

The value on MCP is not on its features or innovation, but on the rate of adoption it has had. Companies have now an incentive to open, document and standarize their APIs to enable this new distribution channel.

43. paulddraper ◴[] No.45954388{4}[source]
This comment is unhinged.

https://modelcontextprotocol.info/docs/concepts/transports/

replies(1): >>45955076 #
44. paulddraper ◴[] No.45954410{5}[source]
Wild claim.

MCP has been popular for well over a year.

To filter it out of the training data would be laughable.

replies(2): >>45955218 #>>45958411 #
45. rcarmo ◴[] No.45954572{3}[source]
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 helpers for a specific data set), but if you try to mix and match servers things get out of hand really quickly and the entire workflow becomes very unreliable—too many options to digest and pursue, just like humans.

replies(1): >>45955557 #
46. whoknowsidont ◴[] No.45955037{4}[source]
Can you do yourself a favor and look at the source code and tell me why you think MCP is necessary here?

I mean you just took some examples and went "See MCP!" without any actual understanding of what that code is doing.

All of these have underlying API's that have exactly ZERO need for MCP. All of this functionality already exists and can be used with LLM's.

* https://help.ableton.com/hc/en-us/articles/209072009-Install...

* https://docs.blender.org/api/current/info_quickstart.html

* https://docs.unity3d.com/6000.2/Documentation/ScriptReferenc...

The most hilarious quote from one of those projects:

>The proxy server is required because the public facing API for UXP Based JavaScript plugin does not allow it to listen on a socket connection (as a server) for the MCP Server to connect to (it can only connect to a socket as a client).

Maybe that should have been the sign that this was completely unnecessary and stupid?

>Do you know of another way you can control all of those applications via LLMs?

Seriously. This becoming a bad joke. I mean conceptually, what did you think was happening here? MCP was just magically doing something that didn't already exist before?

It's a waste of effort and time. Do not use MCP.

replies(2): >>45958897 #>>45966010 #
47. whoknowsidont ◴[] No.45955046{6}[source]
It's not even a standard. It's literally not doing anything here. Not only "can" you rip out MCP there is zero technical reason for any of those things to be an "MCP" in the first place.
48. whoknowsidont ◴[] No.45955057[source]
>, they just teach them how to use the tools and then the LLM calls the APIs directly as any HTTP client would.

No. MCP does not do this. Function & tool calling is built into the LLM. MCP is not augmenting this ability in ANY way.

49. whoknowsidont ◴[] No.45955076{5}[source]
You linked to one part of the spec and just wanted to ignore everything else? That's fine, but then you wouldn't be obeying the standard and wouldn't be an "MCP."

So, are you agreeing with me?

Respectfully I think I've engaged with you before and you just seem generally confused about nuanced concepts.

replies(1): >>45955624 #
50. whoknowsidont ◴[] No.45955218{6}[source]
Please give this a read before engaging further: https://huggingface.co/docs/hugs/en/guides/function-calling

You're just utilizing your ignorance to yap at this point.

51. didibus ◴[] No.45955557{4}[source]
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.

replies(1): >>45957243 #
52. didibus ◴[] No.45955624{6}[source]
I'm open mindedly hoping you'll be more specific in what about the protocol you find problematic?

The base protocol is just JSON-RPC, and then you have to implement initialize. Everything else is optional.

53. cstrahan ◴[] No.45957037{6}[source]
(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)?

54. cstrahan ◴[] No.45957243{5}[source]
> 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.
replies(3): >>45959894 #>>45960427 #>>45970909 #
55. cstrahan ◴[] No.45957524{4}[source]
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.

56. cstrahan ◴[] No.45957677{3}[source]
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.

57. cstrahan ◴[] No.45958326[source]
> but those that I have used (GitHub, [...])

> Most MCP severs don't sit in between the LLM and the API endpoints [...]

Your first example certainly isn't an example of that: https://github.com/github/github-mcp-server

I suppose someone could try to abuse MCP by stuffing information about REST API endpoints into a the prompt/descriptions in a small MCP "skeleton" service, but I don't know of any. Can you provide examples?

> they just teach them how to use the tools and then the LLM calls the APIs directly as any HTTP client would.

I suspect you might have some deep misunderstandings about MCP.

58. cstrahan ◴[] No.45958411{6}[source]
What whoknowsidont is trying to say (IIUC): the models aren't trained on particular MCP use. Yes, the models "know" what MCP is. But the point is that they don't necessarily have MCP details baked in -- if they did, there would be no point in having MCP support serving prompts / tool descriptions.

Well, arguably descriptions could be beneficial for interfaces that let you interactively test MCP tools, but that's certainly not the main reason. The main reason is that the models need to be informed about what the MCP server provides, and how to use it (where "how to use it" in this context means "what is the schema and intent behind the specific inputs/outputs" -- tool calls are baked into the training, and the OpenAI docs give a good example: https://platform.openai.com/docs/guides/function-calling).

59. nilslice ◴[] No.45958897{5}[source]
Idk what you think you have to gain with your stance lol

No one looks at MCP and sees "magic", they just see "finished integration". Something you can pretty much use straight away. That's the point.

60. didibus ◴[] No.45959894{6}[source]
But none of the criticisms here is specific to MCP, just to tool calls in general, it wouldn't matter if the agent used a custom tool protocol, plain OpenAPIs, etc. These issues would still exist.
replies(1): >>45977799 #
61. anon84873628 ◴[] No.45960427{6}[source]
Sounds like what we need is for the MCP client to expose the tools as libraries for the agent's code interpreter. Then it can write code to wire them together without flowing through context.

We still get the benefits of standardization, higher level RPC endpoints, and vendor-supplied instructions.

62. anon84873628 ◴[] No.45960553[source]
It gave everyone a reason to think about the usability of the interfaces they were exposing.

Many endpoints have tons of fields irrelevant to 95% of external users. Now those are gone.

Or they implemented higher level abstractions for the actual tasks instead of making developers compose a bunch of little pieces.

And it has a standardized manifest.

Execs, PMs, and customers having that word to utter as part of the AI hype train created the opportunity for that industry-wide cleanup to happen. Calling it pointless is very naive. It's actually kind of extraordinary.

replies(1): >>45961673 #
63. voidhorse ◴[] No.45961673{3}[source]
Thanks for offering another perspective on it. I can buy into this partially.

At the same time, I'm skeptical that this won't just become yet another dead protocol once the hype abates, at which point all of the perceived benefits were for naught.

64. jcelerier ◴[] No.45966010{5}[source]
So again, how do I automate Ableton live over a network socket with a standard API? I don't know if you've read the remote control API but it doesn't open a magic socket to remote control Live, you have to code the entire integration and protocol yourself to map whatever API messages you want to Live actions manually.

Let's forget about LLMs completely as they are only tangentially relevant to the benefits of MCP. I want to write 15 lines of python that - no matter the software - is going to trigger the "play" button/action in that software. E.g. I want to hit "play" in both Ableton, Unity and Blender without having to write three times the code, without having to manually write them each an extension plug-ins. How do you do that, today, 2025-11-17 ?

65. paulddraper ◴[] No.45970909{6}[source]
> Now, if you were to instead have the LLM write code

Okay....now what function calls or libraries should the API use to write that code?

Anthropic article describes a good approach, combining code gen with MCP.

replies(1): >>45977613 #
66. cstrahan ◴[] No.45977613{7}[source]
> Okay....now what function calls or libraries should the API use to write that code?

Whatever the most popular library is which provides a client to whatever "thing" (locally running process, or service, or whatever) you are trying to interact with via LLM.

I have had LLMs generate probably 10s of thousands of lines of code, all without providing an MCP. LLMs can do that. They are trained on code.

What if there isn't a library available? Well, sure, then you could go implement an MCP server... or you could just write a library. It's practically the same effort.

Not that I'm 100% against MCP servers. But I think there's some misconception spreading across the software community that an MCP server is always inherently the optimal, obvious solution; all I'm suggesting is that people actually think about the problem, instead of outsourcing that responsibility via a "no one ever got fired for buying IBM" type of appeal to bandwagon fallacy.

67. cstrahan ◴[] No.45977799{7}[source]
> These issues would still exist.

I just explained why these issues don't apply to the LLM writing and invoking code: again, this is because code can apply successive transformations to the input without having to feed the intermediate results into the LLM's context. That code can read a file that would weigh in at 50,000 tokens, chain 100 functions together, producing a line that would be 20 tokens, and only the LLM will only see the final 20 token result. That really is only 20 tokens for the entire result -- the LLM never sees the 50,000 tokens from the file that was read via the program, nor does the LLM see the 10s of thousands of tokens worth of intermediate results between the successive transformations from each of the 100 functions.

With MCP, there's no way for the LLM to invoke one tool call that expresses "compose/pipeline these 100 tools, please, and just give me the final result" -- the LLM must make 100 individual tool calls, manually threading the results through each tool call, which represents 100 opportunities for the LLM to make a mistake.

It sounds like you are disagreeing with what I am saying, but it doesn't look you're giving any reason why you disagree, so I'm a bit confused.

replies(1): >>45983657 #
68. didibus ◴[] No.45983657{8}[source]
I'm not exactly disagreeing, its just that I don't think that's a criticism of MCP for tool calls.

You need a way to expose tools to LLM, even for what you're talking about. The LLM can't write code without access to code writing tools.

MCP is a protocol for exposing tools to an LLM agent in an extensible way.

If you didn't have MCP for this, the alternative wouldn't be a python script. It would be some other tool calling protocol.

Maybe a good criticism is that the protocol doesn't have a defined mechanism for piping tool calls together. It be nice to define as part of the protocol a standard way for the model to say call tool1 and then pass output.foo as input.bar of tool2.

I feel that can probably be an eventual extension.

As an advanced user of coding agents that you let run locally or have sandboxed yourself, you might get more power and mileage by having it implement scripts and execute them, or use bash/curl and so on, to say access the Google Drive standard APIs for whatever you want to do, than to use the Google Drive MCP. I 100% agree. But that's not adequate for all users, and it's not really an alternative to supporting custom tools in an agent.

69. judahmeek ◴[] No.46003517{5}[source]
> But they didn't need to be, because LLM function & tool calling is already trained on these models and MCP does not augment this functionality in any way.

I think you're making a weird semantic argument. How is MCP use not a tool call?