Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MCP vs. API Explained

norahsakal.com

Post reply on HN
Print view View original

81–90 of 119 posts

Re: MCP vs. API Explained

#81

Post by swyx »

crabmusket wrote: post #60
SamBam wrote: post #41

Earlier quoted context omitted.

Not only that, but the whole section on "Consider these scenarios" simply described the same thing as an API each time, but added words like "smoothly" and "richer" to make it sound different. I honestly think most of the article was written by an LLM.

The structure seems very LLM-ish. And the details are blurry: > Two-way communication: MCP supports persistent, real-time two-way communication - similar to WebSockets. The AI model can both retrieve information and trigger actions dynamically". This is not what two-way communication means.

unfortunately it is indistinguishable from what a reasonable human high on mcp copium might write

Re: MCP vs. API Explained

#82

Post by imtringued »

ondrsh wrote: post #11

It's much simpler: MCP allows tools to be added at runtime instead of design-time. That's it. And because this can happen at runtime, the user (NOT the developer) can add arbitrary functionality to the LLM application (while the application is running — hence, runtime). One could make the argument that LLM applications with MCP support are conceptually similar to browsers — both let users connect to arbitrary MCP/HTT…

The spec and server docs also contain a helpful explanation:

https://spec.modelcontextprotocol.io/specification/2024-11-0...

https://modelcontextprotocol.io/sdk/java/mcp-server

Also, btw, how long until people rediscover HATEOAS, something which inherently relies on a generalised artificial intelligence to be useful in the first place?

Re: MCP vs. API Explained

#83

Post by fulafel »

saurik wrote: post #13

1) Ok, so you are reinventing SOAP or WSDL or whatever... did that ever go well? How and why is this different from every prior attempt to create the one true API layer? 2) Is this meaningfully different from just having every API provide a JavaScript SDK to access it, and then having the model write code? That's how humans solve this stuff. 3) If the AI is actually as smart at doing tasks like writing clients for AP…

Most people hate SOAP and WSDL. You can argue most web APIs are reinventing them in the sense that you could reimplement them with WSDL, to get worse versions of them.

Re: MCP vs. API Explained

#84

Post by notpushkin »

myownpetard wrote: post #66
saurik wrote: post #21

Earlier quoted context omitted.

I didn't have a good term so I went with "API layer" (not merely "API"), but, to try to clarify... that's what you also get with SOAP/WSDL or any of the other numerous attempts over the years to build an API "layer" thing: you can use the one universal SDK you have, plus only the schema / IDL, to use the API. Every time people try to describe MCP it just sounds like yet another API description language when we alread…

MCP is more like a UI that is optimized for LLMs for interacting with a tool or data source. I'd argue that an API is not a user interface and that's not really their intention. > Regardless, again: if the AI is so smart, and it somehow needs something akin to MCP as input (which seems silly), then we can use the AI to take, as input, the human readable documentation -- which is what we claim these AIs can read and u…

> I'd argue that an API is not a user interface and that's not really their intention.

API is a user interface for other developers – just like MCP is a UI for LLMs.

Re: MCP vs. API Explained

#85

Post by ondrsh »

imtringued wrote: post #82
ondrsh wrote: post #11

It's much simpler: MCP allows tools to be added at runtime instead of design-time. That's it. And because this can happen at runtime, the user (NOT the developer) can add arbitrary functionality to the LLM application (while the application is running — hence, runtime). One could make the argument that LLM applications with MCP support are conceptually similar to browsers — both let users connect to arbitrary MCP/HTT…

The spec and server docs also contain a helpful explanation: https://spec.modelcontextprotocol.io/specification/2024-11-0... https://modelcontextprotocol.io/sdk/java/mcp-server Also, btw, how long until people rediscover HATEOAS, something which inherently relies on a generalised artificial intelligence to be useful in the first place?

Exactly. An AI-web based on the principles of HATEOAS is the next step, where instead of links, we would have function calls.

As you said, HATEOAS requires a generic client that can understand anything at runtime — a client with general intelligence. Until recently, humans were the only ones fulfilling that requirement. And because we suck at reading JSON, HATEOAS had to use HTML. Now that we have strong AI, we can drop the Hypermedia from 'H'ATEOAS and use JSON instead.

I wrote about that exact thing in Part 2: https://www.ondr.sh/blog/ai-web

Re: MCP vs. API Explained

#86

Post by evalstate »

starik36 wrote: post #8

It seems like MCP is a pretty cool protocol, but has anyone seen any actually useful integrations? I've played a lot with the FileSystem MCP server but couldn't get it to do something useful that I can't already do faster on my own. For instance, asking it how many files have word "main" in it. It returns 267, but in reality there are 12k. Looks promising, but I am still looking for useful ways to integrate it into m…

Most LLMs including Claude struggle using the @modelcontextprotocol/server-filesystem server - it's way too complex (and tools like Goose wrap ripgrep in an MCP to handle it). A simple MCP Server with the SDKs can easily be less than 20 lines of code and be useful.

I wrote mcp-hfspace to let you connect to Hugging Face Spaces; that opens up a lot of image generation, vision, audio transcription and other services that can be integrated quickly and easily in to your Host app.

Re: MCP vs. API Explained

#87

Post by thierrydamiba »

ondrsh wrote: post #85
imtringued wrote: post #82

Earlier quoted context omitted.

The spec and server docs also contain a helpful explanation: https://spec.modelcontextprotocol.io/specification/2024-11-0... https://modelcontextprotocol.io/sdk/java/mcp-server Also, btw, how long until people rediscover HATEOAS, something which inherently relies on a generalised artificial intelligence to be useful in the first place?

Exactly. An AI-web based on the principles of HATEOAS is the next step, where instead of links, we would have function calls. As you said, HATEOAS requires a generic client that can understand anything at runtime — a client with general intelligence. Until recently, humans were the only ones fulfilling that requirement. And because we suck at reading JSON, HATEOAS had to use HTML. Now that we have strong AI, we can d…

Both blog posts were excellent. Thanks for the breakdown.

I’m bullish on MCP-what is are some non-obvious things I shod consider that might dampen my fire?

Re: MCP vs. API Explained

#88

Post by outofpaper »

saurik wrote: post #53
outofpaper wrote: post #30

Earlier quoted context omitted.

No, an API is the closest term, as calling MCP, which is a simple protocol, an SDK is literally wrong. A protocol is not a software development kit.

I am not even the person who said "I wouldn't call it another form of API"... can you maybe just stick to the concrete and explain how this is different from SOAP/WSDL or OpenAPI/Swaggar? I honestly don't even know what short term either I or you would now use for any of them, but I feel confident that the overall premise described by this article doesn't differentiate: they offer a standardized connector to various…

Yup. Though it's a JSON API and not an XML API like SOAP. As for how it differs form the old OpenAPI/Swaggar... shrug... not much... its got a lot less flexibility to it and it has specific tooling for agentic tool use.

https://github.com/modelcontextprotocol/specification/blob/m...

Re: MCP vs. API Explained

#89

Post by whazor »

The MCP protocol is very similar to Language Server Protocol (LSP) in design. LSP has the same requests, responses, and notifications setup. Also the initialization with what capabilities the server has it the same.

Normally, LSP when running on a remote server, you would use a continuous (web)socket instead of API requests. This helps with the parsing overhead and provides faster response for small requests. Also requests have cancellation tokens, which makes it possible to cancel a request when it became unnecessary.

Post reply on HN