[HN Gopher] MCP vs. API Explained
___________________________________________________________________
MCP vs. API Explained
Author : typhon04
Score : 38 points
Date : 2025-03-08 18:32 UTC (4 hours ago)
(HTM) web link (norahsakal.com)
(TXT) w3m dump (norahsakal.com)
| smallnix wrote:
| So it's an indirection layer to the actual APIs.
|
| The value of MCP then depends on it's adoption. If I need to
| write an MCP adapter for everything, it's value is little. If
| everyone (API owners, OS, Clouds, ...) puts in the work to have
| an MCP compatible interface it's valuable.
|
| In a world where I need to build my own X-to-USB dongle for every
| device myself, I wouldn't use USB, to stay with the articles
| analogy.
| redm wrote:
| What the article doesn't say (well, there's a lot it doesn't say)
| is that this protocol was created by Anthropic but is being
| adopted more widely.
|
| MCP reminds me of a new platform opportunity akin to the Apple
| App Store.
|
| It's rapidly adopted, with offerings from GitHub, Stripe, Slack,
| Google Maps, AirTable, etc. Many more non-official integrations
| are already out there. I expect this will only gain adoption over
| the coming year.
| jameslk wrote:
| If the goal is to build AI agents, I'd think the maximum utility
| from them would come from building agents that can use the UI
| that humans use. Or at the very least, the lesser available
| _API_. MCP is yet another interface to services when there's
| already at least two out there available to use
| paulgb wrote:
| One thing I like about MCP's decision _not_ to just use HTTP
| APIs is that it makes it possible to build and distribute tools
| that people can use without having to set up a server for them.
| This goes a long way for enabling open-source and locally-
| running tools.
| ozten wrote:
| A sample MCP example with data would be helpful.
| 1116574 wrote:
| The article has the same usb-c photo three times, but doesn't
| actually explain what it is, or how it works.
| starik36 wrote:
| 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 my workflow.
| gsibble wrote:
| So far I have not found anything useful.
| campbel wrote:
| 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 bother with unless you
| are building an application that needs extension or you are
| trying to extend an application (like those I listed above).
| Under the hood the MCP is just an interface into the tools API.
| gsibble wrote:
| 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.
| nsonha wrote:
| 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.
| electroly wrote:
| 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.
| ondrsh wrote:
| 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/HTTP servers
| at runtime.
|
| But the comparison with HTTP is not a very good one, because MCP
| is stateful and complex. MCP is actually much more similar to FTP
| than it is to HTTP.
|
| I wrote 2 short blog posts about this in case anyone is curious:
| https://www.ondr.sh/blog/thoughts-on-mcp
| saurik wrote:
| 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 APIs as people like to claim, why does it need this
| to be made machine readable in the first place?
| no_wizard wrote:
| Question three is what hits the nail on the head about how this
| "AI revolution" isn't as robust as often claimed.
|
| If it was truly intelligent it could reason about things like
| API specifications without any precursors or shared structure,
| but it can't.
|
| Are LLMs powerful? Yes. Is current "AI" simply a re-brand of
| machine learning? IMO, also yes
| muzani wrote:
| 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, OpenAI, Groq, and so on.
|
| (3) is exactly related to this. The AI has been trained to run
| MCPs, viewing them as big labeled buttons in their "mind".
|
| I think you got the questions spot on and the answers right
| there as well.
| saurik wrote:
| 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.
| johnjungles wrote:
| 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 codebase, then create a new Notion page with
| the reference
|
| MCP tools are what the LLM uses and initiates
|
| MCP prompts are user initated workflows
|
| MCP resources is the data that the APIs provide and structure of
| that data (because porting APIs to MCPs are not as straight
| forward) Anyways please give me feedback!
| rsp1984 wrote:
| 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?
| muzani wrote:
| Writing code for interfaces is an extra "cognitive layer" for
| the AI, just like it would be for a human.
|
| Let's say you want to add or delete Jira tickets. A MCP is like
| a big labeled button for the AI to do this, and it doesn't come
| with the token cost of reading an API or the possibility of
| making a mistake while accessing it.
| nsonha wrote:
| Sorry but I'm extremelly annoyed with this idiotic argument
| that many people seem to have. Is it that easy to prompt AI to
| write code and call an API predictably?
| chrislloyd wrote:
| 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.
| nsonha wrote:
| MCP is not that hard to understand why does it keep getting the
| wackiest comparison?
| codr7 wrote:
| So it's yet another one API to rule them all?
|
| The only thing that idea ever lead to was more (complicated)
| APIs.
___________________________________________________________________
(page generated 2025-03-08 23:00 UTC)