MCP vs. API Explained

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.

I feel like you are being overly hostile and you and saurik are both arguing the same point... maybe? Following this thread has not been easy, not sure which positions each of you are even defending.

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 understand -- and just have it output something akin to MCP.

This example is like telling someone who just wants to check their email to build an IMAP client. It's an unnecessary and expensive distraction from whatever goal they are actually trying to accomplish.

As others have said, models are now being trained on MCP interactions. It's analogous to having shared UI/UX patterns across different webapps. The result is we humans don't have to think as hard to understand how to use a new tool because of the familiar visual and interaction patterns. As the design book title says, 'don't make me think.'

> 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.

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).