Reflections on building with Model Context Protocol
outlore.dev
outlore.dev
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:
Do you have a link to the spec where they cover this use case?
Why is callback in OpenAPI not sufficient for this?
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!