MCP vs. API Explained

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

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.

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?

Random: I tried posting this as ShowHN, but I am guessing I don't have enough reputation, because it was hidden.

So if you are here for MCP, I will use the opportunity to share what I've been working on the last few months.

I've hand curated hundreds of MCP servers, which people can access and browse via https://glama.ai/mcp/servers and made those servers available via API https://glama.ai/mcp/reference

The API allows to search for MCP servers, identify their capabilities via API attributes, and even access user hosted MCP servers.

However, you can also try these servers using an inspector (available under every server) and also in the chat (https://glama.ai/chat)

This is all part of a bigger ambition to create an all encompassing platform for authoring, discovering and hosting MCP servers.

I am also the author of https://github.com/punkpeye/fastmcp framework and several other supporting open-source tools, like https://github.com/punkpeye/mcp-proxy

If you are also interested in MCP and want to chat about the future of this technology, drop me a message.

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.

The article has the same usb-c photo three times, but doesn't actually explain what it is, or how it works.

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.

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?

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.

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.

I'd like to recommend another protocol—ANP (AgentNetworkProtocol).

While similar to MCP, ANP is significantly different. ANP is specifically designed for agents, addressing communication issues encountered by intelligent agents. It enables identity authentication and collaboration between any two agents.

Key differences include:

ANP uses a P2P architecture, whereas MCP follows a client-server model. ANP relies on W3C DID for decentralized identity authentication, while MCP utilizes OAuth. ANP organizes information using Semantic Web and Linked Data principles, whereas MCP employs JSON-RPC. MCP might excel at providing additional information and tools to models and connecting models to the existing web. In contrast, ANP is particularly effective for collaboration and communication between agents.

Here is a detailed comparison of ANP and MCP (including the GitHub repository): https://github.com/agent-network-protocol/AgentNetworkProtoc...

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!

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.

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

I don't really get how MCP is materially different from a standardized API interface. It will be interesting to see if the other big model providers decide to standardize on MCP or push their own competing standards.

A sample MCP example with data would be helpful.

So how does MCP differ from a regular library like aisuite or vercel ai sdk?

Regular SDK lib: - Integration Effort: just like MCP - Real-Time Communication - Sure - Dynamic Discovery - obviously. just call refresh or whatever - Scalability - infinite, it is a library - Security & Control - just like mcp

i trully don't get it

Tangential but it's a shame people are often missing the opportunity to align jsonrpc with programming language semantics 1) name methods so they can be methods in programming langugage (no "/" in names like MCP does) 2) use arity based calling convention (no named params, use array instead because that's what your programming language does when you define functions or methods; if you want named params, just use object as first argument).

Following those two principles means your implementation ends up as simple class, with simple methods, with simple params - possibly using decorators to expose it as rpc and perform runtime type assertion for params (exposing rpc, server side) and result (using rpc, client side) – consuming jsonrpc now looks like using any ordinary library/package that happens to have async methods (this is important, there is no special dialect of communication, it's all ordinary semantics everybody is already used to, your code on client and server side doesn't jump between mapping to/from language and jsonrpc, there is a lot of complexity that's collapsed, code looks minimal, it's small, natural to read etc).

Notifications also map naturally to well established pattern (ie. event emitter in nodejs).

And yes, that's my main criticism of MCP – you're making standard for communication meant to be used from different languages, why adding this silly, unnecessary complexity by using "/" in method names? It frankly feels like amateur mistake by somebody who thinks it should be a bit like REST where method is URL path.

Another tangent – this declaration of available enpoints is unnecessarily complicated – you can just use url: file://.. scheme to start process on that executable with stdin/stdout as communication channels (this idea is great btw, good job!), ws:// or wss:// for websocket comms to existing service and http:// or https:// for jsonrpc over http (no notifications).

Here's the spec: https://spec.modelcontextprotocol.io/specification/2024-11-0...

Every API is different/custom whereas MCP is supposed to be universal. Is that it?

Ok but why would every app and website implement this new protocol for the benefit of LLMs/agents?

> MCP allows AI models to dynamically discover and interact with available tools without hard-coded knowledge of each integration

Did they just now discover abstract base classes?

Ironic this post is written in repetitive SEO spam format.

So it's yet another one API to rule them all?

The only thing that idea ever lead to was more (complicated) APIs.

shameless plug: we're building a registry and tooling for multi-platform MCP-based tools check it out https://www.mcp.run/

I missed an update. How did MCPs come into this world?

Erlang