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

21–30 of 119 posts

Re: MCP vs. API Explained

#21

Post by saurik »

muzani wrote: post #19
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…

I wouldn't call it another form of API. It's more like an SDK. If you were accessing a REST API from Android, iOS, Windows, Mac, Firefox, they'd be mostly the same. But an SDK for Android and an SDK for iOS has been built for the platform. Often the SDK encapsulates the official API. That's a direct answer for (2) too - instead of writing a JS SDK or Swift SDK or whatever, it's an AI SDK and shared across Claude, Ope…

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 already have a giant drawer of those that never really worked out, including OpenA"P"I (lol ;P).

https://www.openapis.org/

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 understand -- and just have it output something akin to MCP. The entire point of having an AI agent is that it is able to do things similar to a software developer, and interfacing with a random API is probably the most trivial task you can possible do.

Re: MCP vs. API Explained

#22

Post by nsonha »

rsp1984 wrote: post #16

To be honest I don't understand why this is needed. All the leading AI models can already write code that interfaces perfectly with well-known APIs, and for the niche-APIs I can supply the docs of that API and the model will understand. So all that's needed are API docs. Or what am I missing?

Sorry but I'm extremelly annoyed with this idiotic take that many people seem to have. Is it that easy to prompt AI to write code and call an API predictably?

Re: MCP vs. API Explained

#23

Post by electroly »

campbel wrote: post #9

The most important thing for developers to understand when it comes to MCP: MCP is a protocol for dynamically loading additional capabilities into an AI application, e.g. Claude Desktop, Cursor, Highlight.ai etc... If you are building your own applications, you can simply use "Tools APIs" provided by the LLM directly (e,.g. https://platform.openai.com/docs/assistants/tools ). MCP is not something most people need to…

I saw you were downvoted and could not understand why, so I'm both upvoting and replying. This is all correct. MCP is, realistically speaking, the extension API for Claude Desktop and Cursor. It's really cool if you do want to extend those apps, but that's all it's for. The article in this case is really confusing and unnecessary.

Re: MCP vs. API Explained

#24

Post by nsonha »

chrislloyd wrote: post #17

MCP strikes me as roughly equivalent to HTML. Headline features like dynamic “tool” discovery (and more!) are solved well with HTML. MCP is probably easier for clients to implement but suffers from poor standardization, immaturity and non-human readability. It clearly scratches an itch but I think it’s a local-minimum that requires a tremendous amount of work to implement.

MCP is not that hard to understand why does it keep getting the wackiest comparison?

Re: MCP vs. API Explained

#25

Post by nsonha »

gsibble wrote: post #10
campbel wrote: post #9

The most important thing for developers to understand when it comes to MCP: MCP is a protocol for dynamically loading additional capabilities into an AI application, e.g. Claude Desktop, Cursor, Highlight.ai etc... If you are building your own applications, you can simply use "Tools APIs" provided by the LLM directly (e,.g. https://platform.openai.com/docs/assistants/tools ). MCP is not something most people need to…

Absolutely correct. You can also use tools everywhere while clients have to be MCP compatible. MCP is not all it's cracked up to be.

It's crack up to be because tools need to be hard-coded. MCP is not.

When computer use was demoed it seems like a big deal. However, with MCP, any one can create and MCP server and run it on their computer and hook it up to an MCP compatible client, regardless of the model.

Re: MCP vs. API Explained

#26

Post by nsonha »

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…

https://x.com/thdxr/status/1897369381195092197

Re: MCP vs. API Explained

#27

Post by cloudking »

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…

I've found BrowserTools MCP useful in my development workflow: https://browsertools.agentdesk.ai/installation

In Cursor for example, it gives the agent the ability to connect to the browser to gather console logs, network logs and take screenshots. The agent will often invoke the tools automatically when it is debugging or verifying it's work, without being explicitly prompted to do so.

It's a little bit of a set up process, as it requires a browser extension on top of the MCP configuration.

Re: MCP vs. API Explained

#28

Post by cloudking »

johnjungles wrote: post #15

I built https://skeet.build where anyone can try out mcp for cursor and dev tools without a lot of setup Mostly for workflows I like: - start a PR with a summary of what I just did - slack or comment to linear/Jira with a summary of what I pushed - pull this issue from sentry and fix it - pull this linear issue and do a first pass - pull in this Notion doc with a PRD then create an API reference for it based on this…

What is unique about your solution? Are you essentially handling auth tokens for the user to interface MCPs with external APIs?

Re: MCP vs. API Explained

#29

Post by nsonha »

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…

1) Valid point, this could haven been wsdl/swagger. But the MCP spec supports spinning up local applications and communicate via stdio which open api cannot do.

2 + 3) having a few commands that AI knows it should call and confidently so without security concern, is better than just give AI permision to do every thing under the sun and tell it to code a program doing so.

The prompt for the later is also much more complex and does not work as predictably.

Re: MCP vs. API Explained

#30

Post by outofpaper »

saurik wrote: post #21
muzani wrote: post #19

Earlier quoted context omitted.

I wouldn't call it another form of API. It's more like an SDK. If you were accessing a REST API from Android, iOS, Windows, Mac, Firefox, they'd be mostly the same. But an SDK for Android and an SDK for iOS has been built for the platform. Often the SDK encapsulates the official API. That's a direct answer for (2) too - instead of writing a JS SDK or Swift SDK or whatever, it's an AI SDK and shared across Claude, Ope…

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…

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.

Post reply on HN