[ants_everywhere]

My bias is I generally think RPC is much nicer than REST. But what's kind of funny here is that we have

(1) an RPC to call a (remote) method called "tools/call", which is a method that

(2) calls a method called get_weather

Both methods have arguments. But the arguments of "tools/call" are called "params" and the arguments of "get_weather" are called "arguments".

I realize this is a common pattern when you have to shell out, e.g. in python's subprocess.run().

But it also seems like there could be a cleaner API with better types.

[keithwhor]

I don’t disagree. I fought this battle for a long time — ran a company where I tried to simplify SDK development by making every endpoint POST and JSON params; sorta like SOAP / just simple RPC. Why do you need all the HTTP methods when most SDKs simplify everything to .retrieve etc, why not name the endpoints that?

What I realized was that these specs are valuable because they’re stable over long periods of time and handle many sorts of edge cases. Also from a systems integration perspective, everybody already knows and is trained in them. Over many years I accepted the wisdom of commons.

A lot of tooling already exists to make development of these sorts of systems easy to implement and debug. Hence why I think for Remote MCP servers, HTTP as it exists is a great choice.

[mattmanser]

I don't feel that's really true, it's easy to forget how fast things have moved.

For a long time lots of servers didn't really support PUT or DELETE, and it was only the early 2010s that it became common.

It's still a problem sometimes that you have to explicitly enable them (I'm looking at you IIS + WebDAV).

PATCH wasn't even added till 2010 and you still don't see it commonly used.

Perhaps we have different understandings of 'stable' and 'many years'.

I also agree with you on RPC, it's pretty ridiculous that some guys tried to boil every single API down to essentially 4 verbs. I remember when Google went all crazy on implementing pure REST and their APIs were atrocious.

And everyone still goes along with it even though it clearly doesn't work, so you always end up with a mix of REST and RPC in any non-trivial API.

But pure RPC doesn't really work as then you have to change every call to a POST, as you mention. Which is also confusing as everyone is now used to using the really restricted REST CRUD interface.

So now pure REST sucks and pure RPC sucks. Great job HTTP standards team!

To be fair to them, I know it's hard and at some point you can't fix your mistakes. These days I guess I've just accepted that almost all standards are going to suck a bit.