After recently learning about MCP from HN, I started working on some demos. I jotted down my thoughts about my developer experience and potential room for improvement.
I think OpenAPI callback would certainly work but the client application must support this. For e.g. I don’t think ChatGPT supports callbacks (I might be wrong).
Broadly speaking I am agreed with you that OpenAPI can replicate much of the functionality of MCP, but what’s missing is the opinionated contract between client and server (similar to LSPs)
That makes it more of a DSL on a protocol (json-rpc) than a protocol itself
If you want to implement notifications without callbacks, you either (1) use an always connected session and pass messages or (2) have the client poll an endpoint
Really appreciate the write up. I am one of the authors of MCP and this helps a great deal giving a good overview of where we need to do better.
I was a bit under the water over the last few weeks with talking to people about MCP and just generally a bit overwhelmed about how well it has been received.
I'll take a look at issue88 this week. Thanks so much
How is the community doing authentication & authorization? We're considering how to support in louie.ai, anticipating a large ecosystem of sites supporting it, yet the original spec had essentially TODO for how to do authentication & authorization bindings...
It seems that maybe the direction things are heading in is having desktop apps that can take over the computer, and prompt you to sign in yourself when auth is needed. Which would limit the usefulness of something like MCP as the interface becomes the UI, not APIs. But I'd be curious what other approaches to auth seem to be promising.
> what other approaches to auth seem to be promising
Speaking on behalf of a regulated enterprise, more SaaS (who may be interested to support MCP so AIs can use their SaaS, not just people), should — for both people and agentic tools — be OIDC first, without charging an "SSO Tax".
"Sign in with" is now effectively ubiquitous, gets you out of the business of user credentials liability and password management flows, and for businesses ticks the same boxes as SAML SSO if you build in (extra work, granted) a DNS validation and domain name match.
In the USA, for B2B, some 85% of SMB are able to "Sign in with Microsoft" (HN tends to ignore this customer base), a majority of the rest can "Sign in with Google". By "wallet share" for B2C, you need "Sign in with Apple" and the rest are again "Sign in with Google".
I am not with, nor using, WorkOS, but appreciate this paragraph in their OIDC vs. SAML explainer:
Use OIDC to: add enterprise SSO to your app in a dramatically easier way, most IdPs support it. It’s also an obvious choice if you’re already using OAuth 2.0 to access users' data (for example, to access a user’s Google files or Facebook profile data).
Once you've done this, as WorkOS mentions you can use this from browser perspective to access other APIs such as social sites, but for things like MCP (we're all building TRON!) if you're building from services perspective, you can build to let agents leverage “OAuth 2.0 Device Authorization Grant” or similar, and for bonus points “OAuth 2.0 Token Exchange”.
14 comments
[ 1.6 ms ] story [ 40.9 ms ] threadDo you have a link to the spec where they cover this use case?
Why is callback in OpenAPI not sufficient for this?
https://swagger.io/docs/specification/v3_0/callbacks/
I think OpenAPI callback would certainly work but the client application must support this. For e.g. I don’t think ChatGPT supports callbacks (I might be wrong).
Broadly speaking I am agreed with you that OpenAPI can replicate much of the functionality of MCP, but what’s missing is the opinionated contract between client and server (similar to LSPs)
That makes it more of a DSL on a protocol (json-rpc) than a protocol itself
If you want to implement notifications without callbacks, you either (1) use an always connected session and pass messages or (2) have the client poll an endpoint
As an MCP fan, am curious! Care to share. Link maybe? Or even just a comment would be great!
I was a bit under the water over the last few weeks with talking to people about MCP and just generally a bit overwhelmed about how well it has been received.
I'll take a look at issue88 this week. Thanks so much
Hope you get some time to rest!
Speaking on behalf of a regulated enterprise, more SaaS (who may be interested to support MCP so AIs can use their SaaS, not just people), should — for both people and agentic tools — be OIDC first, without charging an "SSO Tax".
"Sign in with" is now effectively ubiquitous, gets you out of the business of user credentials liability and password management flows, and for businesses ticks the same boxes as SAML SSO if you build in (extra work, granted) a DNS validation and domain name match.
In the USA, for B2B, some 85% of SMB are able to "Sign in with Microsoft" (HN tends to ignore this customer base), a majority of the rest can "Sign in with Google". By "wallet share" for B2C, you need "Sign in with Apple" and the rest are again "Sign in with Google".
I am not with, nor using, WorkOS, but appreciate this paragraph in their OIDC vs. SAML explainer:
Use OIDC to: add enterprise SSO to your app in a dramatically easier way, most IdPs support it. It’s also an obvious choice if you’re already using OAuth 2.0 to access users' data (for example, to access a user’s Google files or Facebook profile data).
https://workos.com/blog/oidc-vs-saml
Once you've done this, as WorkOS mentions you can use this from browser perspective to access other APIs such as social sites, but for things like MCP (we're all building TRON!) if you're building from services perspective, you can build to let agents leverage “OAuth 2.0 Device Authorization Grant” or similar, and for bonus points “OAuth 2.0 Token Exchange”.
https://www.rfc-editor.org/rfc/rfc8628
https://datatracker.ietf.org/doc/html/rfc8693
Even consumer users understand these device login flows by now since they use SaaS from TV sets:
https://www.netflix.com/tv8
https://myaccount.microsoft.com/devicelogin