workers-oauth-provider VS modelcontextprotocol

> So it kinda worked, but I would not use that for anything "mission critical" (whatever this means).

It means projects like Cloudflare's new OAuth provider library. https://github.com/cloudflare/workers-oauth-provider

> This library (including the schema documentation) was largely written with the help of Claude, the AI model by Anthropic. Claude's output was thoroughly reviewed by Cloudflare engineers with careful attention paid to security and compliance with standards. Many improvements were made on the initial output, mostly again by prompting Claude (and reviewing the results). Check out the commit history to see how Claude was prompted and what code it produced.

I get that a lot of folks wouldn't want to keep a log, but it makes me so sad that the wonderful aider 'ai peer' recommends adding aider logs of all sorts to the gitignore on startup. This feels bad for humans, and bad for AI sense-making too. If you are having this dialog, of course you'd want to be able to reflect on that, I'd think.

It'd be neat to go further. Keeping the agent instructions alongside engineering docs feels like it makes sense. It'd be neat to see what one could do with Backstage like integration, to build out this existing wonderful corporate knowledge-base.

Are there MCP servers yet that can reflect on chat history? Now I want to see a Backstage MCP server even more, one that's extensible by the many Backstage plugins!

Shout out to Kenton Varda & cloudflare doing a nice job making a good commit history of AI use on this project where Kenton was testing the waters. I'm not sure what other good write ups we have for enshrining & promoting the agent instructions as good reference material. https://github.com/cloudflare/workers-oauth-provider/ https://news.ycombinator.com/item?id=44159166

To be fair, there was a pretty dumb CVE (which had already been found and fixed by the time the project made the rounds on HN):

https://github.com/cloudflare/workers-oauth-provider/securit...

You can certainly make the argument that this demonstrates risks of AI.

But I kind of feel like the same bug could very easily have been made by a human coder too, and this is why we have code reviews and security reviews. This exact bug was actually on my list of things to check for in review, I even feel like I remember checking for it, and yet, evidently, I did not, which is pretty embarrassing for me.

We'll have to see how it pans out for Cloudflare. They published an oauth thing and all the prompts used to create it.

https://github.com/cloudflare/workers-oauth-provider/

There's many examples of exactly what you're asking for, such as Kenton Varda's Cloudlfare oauth provider [1] and Simon Willison's tools [2]. I see a new blog post like this with detailed explanations of what they did pretty frequently, like Steve Klabnik's recent post [3], which while it isn't as detailed has a lot of very concrete facts. There's even more blog posts from prominent devs like antirez who talk about other things they're doing with AI like rubber ducking [4], if you're curious about how some people who say "I used Sonnet last week and it was great" are working, because not everyone uses it to write code - I personally don't because I care a lot about code style.

[1]: https://github.com/cloudflare/workers-oauth-provider/

[2]: https://tools.simonwillison.net/

[3]: https://steveklabnik.com/writing/a-tale-of-two-claudes/

[4]: https://antirez.com/news/153

> A very good piece that clearly illustrates one of the dangers with LLS's: responsibility for code quality is blindly offloaded on the automatic system

It does not illustrate that at all.

> Claude's output was thoroughly reviewed by Cloudflare engineers with careful attention paid to security and compliance with standards.

> To emphasize, *this is not "vibe coded"*. Every line was thoroughly reviewed and cross-referenced with relevant RFCs, by security experts with previous experience with those RFCs.

— https://github.com/cloudflare/workers-oauth-provider

The humans who worked on it very, very clearly took responsibility for code quality. That they didn’t get it 100% right does not mean that they “blindly offloaded responsibility”.

Perhaps you can level that accusation at other people doing different things, but Cloudflare explicitly placed the responsibility for this on the humans.

The author goes into great detail about how he looked at my commit log[0] where I used AI, and he found it "nauseating" and concluded he'd never want to work that way.

I'm certainly not going to tell anyone that they're wrong if they try AI and don't like it! But this guy... did not try it? He looked at a commit log, tried to imagine what my experience was like, and then decided he didn't like that? And then he wrote about it?

Folks, it's really not that hard to actually try it. There is no learning curve. You just run the terminal app in your repo and you ask it to do things. Please, I beg you, before you go write walls of text about how much you hate the thing, actually try it, so that you actually have some idea what you're talking about.

Six months ago, I myself imagined that I would hate AI-assisted coding! Then I tried it. I found out a lot of things that surprised me, and it turns out I don't hate it as much as I thought.

[0] https://github.com/cloudflare/workers-oauth-provider/commits... (link to oldest commits so you can browse in order; newer commits are not as interesting)

What exactly do you want to see put up?

I ask this because it reads like you have a specific challenge in mind when it comes to generative AI and it sounds like anything short of "proof of the unlimited powers" will fall short.

It's almost as if you've set the criteria find LLMs being useful to be proof of unlimited powers.

Here's the deal: Reasonable people aren't claiming this stuff is a panacea. It's useful when used by people who understand its limitations.

If you want to see how it's been used by someone who was happy with the results, and is willing to share their results, you can scroll down a few stories on the front-page and check the commit history of this project:

https://github.com/cloudflare/workers-oauth-provider/commits...

Now here's the deal: These people aren't trying to prove anything to you. They're just sharing the results of an experiment where a very talented developer used these tools to build something useful.

So let me ask you this: Did they put up? Or is it not magical enough for you to deem it useful?

> did he save any time though

Yes:

> It took me a few days to build the library with AI.

> I estimate it would have taken a few weeks, maybe months to write by hand.

– https://news.ycombinator.com/item?id=44160208

> or just tried to prove a point that if you actually already know all details of impl you can guide llm to do it?

No:

> I was an AI skeptic. I thoughts LLMs were glorified Markov chain generators that didn't actually understand code and couldn't produce anything novel. I started this project on a lark, fully expecting the AI to produce terrible code for me to laugh at. And then, uh... the code actually looked pretty good. Not perfect, but I just told the AI to fix things, and it did. I was shocked.

— https://github.com/cloudflare/workers-oauth-provider/?tab=re...

So it is, I stand corrected. I googled mcp host and the lmstudio link was the first result.

Some more discussion on the confusion here https://github.com/modelcontextprotocol/modelcontextprotocol... where they acknowledge that most people call it a client and that that's ok unless the distinction is important.

I think host is a bad term for it though as it makes more intuitive sense for the host to host the server and the client to connect to it, especially for remote MCP servers which are probably going to become the default way of using them.

Long-running tasks are an open topic of discussion, and I think MCP intends to address it in the future.

There are a few proposals floating around, but one issue is that you don't always know whether a task will be long-running, so having separate APIs for long-running tasks vs "regular" tool calls doesn't fully address the problem.

I've written a proposal to solve the problem in a more holistic way: https://github.com/modelcontextprotocol/modelcontextprotocol...

I hope you get the point till now. Since we can easily convert stdio to SSE and vice versa, we can actually deploy the service to any cloud provider and then use it in Claude easily. Obviously for this service, deploying it with authentication is fine as it only calls the AirBnB api. However, in many cases you have an API key or access more sensitive systems where you want the service to be secured, for example, via OAuth. MCP itself provides a specification for OAuth 2.1, however, this is still a draft and there a flaws with the implementation.

The Road to Streamable HTTP: Initially, MCP was a stateful protocol assuming long-lived connections. However, the difficulty of deploying in serverless environments led to a demand for more flexible communication methods. In GitHub Discussions, particularly "State, and long-lived vs. short-lived connections," developers from companies like Shopify and Automattic (WordPress.com) who were trying to use MCP discussed specific challenges (e.g., difficulties implementing SSE in PHP, serverless scaling issues) and proposed various solutions like session tokens, stateless/stateful protocol variants, and WebSocket usage. The current Streamable HTTP transport (HTTP POST + optional SSE) specification was adopted as a result of this active feedback loop, demonstrating MCP's evolution with the community.

This came up in a recent GitHub discussion, where the community debated how to manage scenarios in which:

Yes thank you! the newest MCP spec added the authentication part but it seems that people think it is still not perfect and are doing more modifications to the auth part. E.g. https://github.com/modelcontextprotocol/modelcontextprotocol.... We will also keep an eye on the spec development.

That github issue is closed because it's been mostly completed. As of https://github.com/modelcontextprotocol/modelcontextprotocol..., the latest draft specification does not require the resource server to act as or poxy to the IdP. It just hasn't made its way to a ratified spec yet, but SDKs are already implementing the draft.

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...