Coordinator of the authorization RFC linked in this post[1].

The protocol is in very, very early stages and there are a lot of things that still need to be figured out. That being said, I can commend Anthropic on being very open to listening to the community and acting on the feedback. The authorization spec RFC, for example, is a coordinated effort between security experts at Microsoft (my employer), Arcade, Hellō, Auth0/Okta, Stytch, Descope, and quite a few others. The folks at Anthropic set the foundation and welcomed others to help build on it. It will mature and get better.

[1]: https://github.com/modelcontextprotocol/modelcontextprotocol...

Awesome! Thanks for your work on this.

I have read 30 MCP articles now and I still don’t understand why we not just use API?

Obviously the API can implement your functions, but this is completely decentralized and the ecology is split. MCP is a standard protocol that can obviously promote the development of Agent. This is true. You can take a look here.

https://www.claudemcp.com/blog/mcp-vs-api

I played around with MCP this weekend and I agree. I just want to get a users X and then send X to my endpoint so I can do something with it. I don't need any higher level abstraction than that.

MCP is a dead end for chatbots. Building valuable workflows requires more than tool calling, most importantly, understanding the context of a conversation to adjust the tools dynamically.

What does that have to do with MCP? Those sound like things you would build on a separate layer from MCP.

MCP tools are completely static. If you have to expose some APIs bypassing MCP, then you don't need MCP in the first place, because you don't have the tools abstracted anymore.

I believe it is possible to build nuanced workflows with well abstracted / reusable / pluggable tools, it's just not as simple as implementing a static discovery / call dispatch layer.

Yeah, I don't feel comfortable downloading tiny server programs from random devs on the internet to give my LLM client apps extra "tools". I can LuLu or LittleSnitch regular apps but not these ones.

"Authentication is tricky and so it was very fair that the designers chose not to include it in the first version of the protocol."

No, it's not fair at all. You can't add security afterwards like spreading icing on baked cake. If you forgot to add sugar to the cake batter, there's not enough buttercream in the world to fix it.

I made a MCP server to access remote storage using any kind of protocols (S3, SFTP, FTP, .... ), and authentication was not as much of a problem that most people would make you think. Is it technically pure and beautiful? No. Does it work? Yes and you can check by yourself by pointing the mcp inspector to "https://demo.filestash.app/sse" and play around

I haven't read a good justification from them on this but it did seem reasonable to me that if the protocol allows auth to be added on top then it's less critical to be in the spec v1 itself.

It's not no security vs security but not standardized vs standardized.

Agree though that's it's not ideal and there will definitely be non zero harm from that decision.

great analogy

I’ll admit I’m a total dunce with respect to using MCP but given it uses TLS why not just use mutual TLS and validate the client certificate for authentication? You don’t need to use higher level protocols for authentication if your transport protocol supports it already.

I would think authZ is the trickier unhandled part of MCP as I don’t remember any primitives for authorization denial or granularity, but, again, HTTP provides a coarse authZ exchange protocol.

isnt langchain doing the exact same thing? (sorry ai noob here)

Langchain is one of many frameworks that implement the "tool calling" pattern, where LLM applications can request that a tool is run (eg "search the web for X" or "execute this Python code") and see the result of that.

MCP is a standard for describing and exposing tools to LLM applications.

So they're not the same category of thing. Langchain could implement aspects of the MCP specification, in fact it looks like they're doing that already: https://github.com/langchain-ai/langchain-mcp-adapters

So, is MCP a spec for tool calling API?

There's a MCP "server" spec for writing code that exposes tool definitions and the ability to execute them, and an MCP "client" spec for building systems that can make use of those servers.

It's a common question!

Related: > Tool-Calling - If you’re like me, when you first saw MCP you were wondering “isn’t that just tool-calling?”...

Not everyone uses langchain nor does langchain cover some of the lower level aspects of actually connecting things up. MCP just helps standardize some of those details so any assistant/integration combo is compatible.

Edit: +1 simonw above

Did you read the spec ? Everything you said is already a recommendation.

I think recommendation != being enforceably part of it or being implemented.

There are a lot of great recs in the docs but I wrote this based on what I actually saw in the wild. I definitely don't think it's all on the spec to solve these.