> Further, one of the issues with remote servers is tenancy
Excellent write-up and understanding of the current state of MCP
I’ve been waiting for someone to point it out. This is in my opinion the biggest limitation of the current spec.
What is needed is a tool invocation context that is provided at tool invocation time.
Such tool invocation context allows passing information that would allow authorizing, authentication but also tracing the original “requester”: think of it as “tool invoked on behalf of user identity”
This of course implies an upstream authnz that feeds these details and more.
If you’re interested in this topic, my email is in my bio: I’m of the architect of our multi-tenant tool calling implementation that we’ve been running in production for the past year with enterprise customers where authnz and auditability are key requirements.
The way we've solved this in our MCP gateway (OSS) is that the user first needs to authenticate against our gateway, e.g. by creating a valid JWT with their identity provider, which will be validated using JWKS. Now when they use a tool, they must send their JWT, so the LLM always acts in their behalf. This supports multiple tenants out of the box. (https://wundergraph.com/mcp-gateway)
I mean, converting a tool-less LLM into a tool-using LLM is a few hundred lines of code, and then you can plug all your tools, with whichever context you want.
My point is about the need for a spec of this mechanism: without a spec, every company / org will roll out their own and result in 500 flavors of the same concept.
That’s where MCP shines: tool calling and tool discovery is already 1.5 years old (an eternity in ai land).
The MCP spec ensures that we can all focus on solving problems with tool calling rather than wasting time in cobbling together services that re not interoperable (because developed without a common spec / standard)
Excellent write-up and understanding of the current state of MCP
I’ve been waiting for someone to point it out. This is in my opinion the biggest limitation of the current spec.
What is needed is a tool invocation context that is provided at tool invocation time.
Such tool invocation context allows passing information that would allow authorizing, authentication but also tracing the original “requester”: think of it as “tool invoked on behalf of user identity”
This of course implies an upstream authnz that feeds these details and more.
If you’re interested in this topic, my email is in my bio: I’m of the architect of our multi-tenant tool calling implementation that we’ve been running in production for the past year with enterprise customers where authnz and auditability are key requirements.