MCP vs. API Explained

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

It sounds like pushing the logic of API calling into one of the many "mcp servers", with the user still needing to go through the manual step of creating accounts on third party services, generating a bunch of different tokens, and dealing with them all.

In essence it seems like an additional shim that removes all the security of API tokens while still leaving the user to deal with them.

Side note, has Tron taught us nothing about avoiding AI MCPs?

Your understanding is on point.

> As far as I understand, they would have to somehow pass in either a script to spin up their own server locally (unlikely for your everyday user), or a url to access some live MCP server. This means that the host they are using needs an input on the frontend specifically for this, where the user can input a url for the service they want their LLM to be able to talk to. This then gets passed to the client, the client calls the server, the server returns the list of available tools, and the client passes those tools to the LLM to be used.

This is precisely how it would work. Currently, I'm not sure how many host applications (if any) actually feature a URL input field to add remote servers, since most servers are local-only for now. This situation might change once authentication is introduced in the next protocol version. However, as you pointed out, even if such a URL field existed, the discovery problem remains.

But discovery should be an easy fix, in my opinion. Crawlers or registries (think Google for web or Archie for FTP) will likely emerge, so host applications could integrate these external registries and provide simple one-click installs. Apparently, Anthropic is already working on a registry API to simplify exactly this process. Ideally, host applications would automatically detect when helpful tools are available for a given task and prompt users to enable them.

The problem with local-only servers is that they're hard to distribute (just as local HTTP servers are) and that sandboxing is an issue. One workaround is using WASM for server development, which is what mcp.run is doing (https://docs.mcp.run/mcp-clients/intro), but of course this breaks the seamless compatibility.

It seems like you're describing a scenario where you know at design-time which tools will be included. In that case the benefit of using MCP is less clear.

While you usually get tools that work out of the box with MCP (and thus avoid the hassle of prompting + testing to get working tool code), integrating external APIs manually often results in higher accuracy and performance, as you're not limited by the abstractions imposed by MCP.

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.

This is mistaken. It was effectively true until recently but all kinds of people are building things with it now. This article is likely on HN today because there has been a surge of general interest lately. Here's another example: https://github.com/block/goose. MCP servers are a bit heavyweight but most common case is probably using those developed and/or hosted by others. Clients (e.g. Cursor, Claude Desktop) on the other hand will likely be widespread before long.

> If it was truly intelligent it could reason about things like API specifications without any precursors or shared structure, but it can’t

I can reason about any API or specification. But when I'm trying to get a different, compound, and higher-level task done, its quite a bit faster and less distracting if I can rely on someone else to have already distilled what I need (into a library, cheat-sheet, tutorial, etc).

Similarly, I've seen LLMs do things like generate clients and scripts for interacting with APIs. But its a lot easier to just hand them one ready to go.

My impression, and perhaps this is wildly off, is that MCP could be useful to whitelist safe usage of tools by LLMs.

I say this out loud so someone can correct me if I’m mistaken!

Exactly Any junior developer can reason about API and integrate

But LLm will replace them?

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.

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.

How many R's are in "strawberry"? ;)

MCPs goal is to standardize the transfer of application context and tool definitions to a client (let’s ignore prompts for the moment). That’s the same goal as Hypertext. In HTML, context is <p>, <img/> etc. and “tools” are <form>, <a> and <button>s. Instead of separating the two (like in MCP) - it’s all included in the same document.

I’ve used MCP quite a bit but perhaps I’m misunderstanding something? Happy to hear why you think it’s “wacky”.

Wouldn’t you just do that with an SDK? Why the extra layer of complexity with MCP?

This is like the simplest task you can give a software developer, as it is nigh-unto merely a document "translation" task, without much real thought required. If an LLM is failing to do this task, why do we hope whatever chain of reasoning it is about to embark on would work?

I am somewhat shocked by the level of incredulity people are having in this thread toward having an alternative to traditional APIs for use with LLMs. It is a lot of the same "If the AI is incapable of <blah blah> then why would anyone use it?". I guess I don't see what the big deal is in having a more robust standard for interfacing with a system such as LLMs. Do they fear the engineering effort is orders of magnitude? I mean really, I think it is more of an anti-AI or anti-LLM sort of sentiment, which, frankly, I am quite sympathetic to, but this is sort a bad argument or position to have.

So there’s a lot of noise about MCP but it’s just a tool - we found that we’re solving for developer workflows (where there’s pain). People want to get shit done but after coding to update JIRA tickets just kills momentum.

We just make it a highly reliable, easy to use, after committing - add a comment with a summary to that Jira/linear issue. Start a PR in GitHub and assign x, update the slack channel with an update.

In order to get this it wasn’t about porting APIs to mcp. It was thoughtfully designing and optimizing for these workflows. Also quality and polish where the calls are highly reliable - required lower level networking optimizations, sessions, etc to make to work smoothly.

But yes, also part of the frictionless experience was, just oauth.