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

21–30 of 146 posts

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

#21

Post by yxhuvud »

jahsome wrote: post #12
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.

Are you referring to MCP? If so, it's fully spelled out in the first sentence of the first paragraph, and links to a more thorough post on the subject. That meets 2 of the 3 criteria you've dictated.

That was not the case when I commented. It has obviously been updated since then.

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

#24

Post by rco8786 »

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…

> when LLMs can just connect to the existing API endpoint

The primary differentiator is that MCP includes endpoint discovery. You tell the LLM about the general location of the MCP tool, and it can figure out what capabilities that tool offers immediately. And when the tool updates, the LLM instantly re-learns the updated capability.

The rest of it is needlessly complicated (IMO) and could just be a bog standard HTTP API. And this is what every MCP server I've encountered so far actually does, I haven't seen anyone use the various SSE functionality and whatnot.

MCP v.01 (current) is both a step in the right direction (capability discovery) and an awkward misstep on what should have been the easy part (the API structure itself)

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

#25

Post by losvedir »

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.

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

#27

Post by AznHisoka »

rco8786 wrote: post #24
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…

> when LLMs can just connect to the existing API endpoint The primary differentiator is that MCP includes endpoint discovery. You tell the LLM about the general location of the MCP tool, and it can figure out what capabilities that tool offers immediately. And when the tool updates, the LLM instantly re-learns the updated capability. The rest of it is needlessly complicated (IMO) and could just be a bog standard HTTP…

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?

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

#28

Post by mattacular »

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.

It's not really like your examples because MCP has been around for about 1 year whereas those others have been around for decades and are completely ubiquitous throughout the software industry as a result.

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

#29

Post by AznHisoka »

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.

The difference is those terms are ubiquitous terms after 20 years of usage. MCP is a relatively new term that hasnt even been around for a year or so

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

#30

Post by avereveard »

abtinf wrote: post #23

I’ve posted this before[1], and have searched, but still haven’t found it: I wish someone would write a clear, crisp explanation for why MCP is needed over simply supporting swagger or proto/grpc. [1] https://news.ycombinator.com/item?id=44848489

Think a LLM driving a Browser, where it fills field, click things, and in general where losing the state loses the work done so far

That's the C in the protocol.

Sure you can add a session key to the swagger api and expose it that way so that llm can continue their conversation, but it's going to be a fragile integration at best.

A MCP tied to the conversation state abstract all that away, for better or worse.

Post reply on HN