Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I hoped OpenAI would support OpenAPI for connecting to tools. Having created a couple of MCP servers, it feels like a less flexible and worse documented API to me. I can’t really see anything that is made better by MCP over OpenAPI. It’s a little bit less code for a lot less options. Give it some time and it will also get Swagger built in.

It’s solving a problem that was already robustly solved. So get we go with another standard.



> I can’t really see anything that is made better by MCP over OpenAPI

Well it’s transport agnostic, for one.

I think a big part of it is defining a stateful connection and codifying the concepts of prompts and tools.

Another issue with OpenAPI / swagger is that you still need to create a client per API, but with MCP it’s all uniform.


transport argument is irrelevat when http can be both TCP and UDP, and even if you wanna do one protocol, it can be proxied/tunneled via another protocol transparently via VPN/wireguard/proxy.

so transport protocol is moot, especially from latency perspective when most time is spent doing AI inference (seconds) rather than passing packets (milliseconds).

I really wish OpenAI just embraced OpenAPI and that would have instantly gained millions of existing sites available to ChatGPT with zero code change.


It's transport-agnostic in the sense that it works locally (over stdout), not just remotely. It's not just for web-services. That's why HTTP isn't baked into this.


HTTP also works locally(over local files including stdin/stdout), not just remotely.


I feel like we should have transport agnostic RPC by now, GRPC? And MCP is stateless too. And you don't have to create a client per API, it's up to implementation.


Are we reading the same documents? MCP implementations are all websockets so it's not really transport agnostic. They try to talk about how you can use other transports but its just that it's JSON-RPC and if you're willing to code both ends you can do whatever… which is always true. And MCP is explicitly a stateful protocol [1].

https://spec.modelcontextprotocol.io/specification/2025-03-2...

* JSON-RPC message format

* Stateful connections

* Server and client capability negotiation

There's a draft [1] maybe about resolving this.

https://github.com/modelcontextprotocol/specification/pull/2...


https://spec.modelcontextprotocol.io/specification/2025-03-2...

They mention stdio specifically under the transport section of the spec.

Most protocols are transport agnostic, but http APIs tend to require HTTP methods. Http itself is transport agnostic, but truthfully all we’re doing is shuffling bytes around.

If you look at the stateless examples in that PR, they both assume some state (specifically the capabilities) and just behave accordingly.

To get the full features of the protocol (like notifications) a stateful connection would still be required.


I think MCP is a layer higher than grpc. MCP can be implemented on gRPC

Mcp is definitely not stateless. It’s explicitly stateful…

See the 2nd bullet where it says “stateful connections” [1]

And I was saying that with OpenAPI, you need a client per API, or at least a series of http api calls.

1. https://spec.modelcontextprotocol.io/specification/2025-03-2...


Higher in what way?

But HOW is it stateful? That "mandate" the only occurence of that string "state" in that document.


Also

> Higher in what way?

Higher as in at a higher level in the network stack (not exactly, I don’t think, but lower on the same level)

Higher as in you can implement MCP on top of grpc.

You can’t implement grpc in mcp, that doesn’t make sense, because grpc is at a lower level, so to speak, in the network stack.


“That document” is the MCP spec. What is says _is_ MCP, regardless of your understanding of it.

It’s not a “mandate” it’s a specification for how the protocol works. If the connection isn’t stateful, then it isn’t adhering to the specification.

I mean also like… how is it stateless? For both example transports (stdio and SSE) a connection must be maintained.

ANY connection must be initialized via an MCP message and both server and client must negotiate capabilities.

Those capabilities must be honored through the entire lifetime of the connection.

That alone is state.

I suggest you read the spec…


Whatever the current state, if everyone throws their shoulders behind a common interface, we all win.


There's already swagger MCP service out there, I don't know how production ready it is, but I saw something the other day when searching through GitHu. One of several implementations: https://github.com/dcolley/swagger-mcp


Emcee is a good implementation of this.

https://github.com/loopwork-ai/emcee


GraphQL looks like an even better choice - it really looks like they re-invented the wheel here.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: