I recently watched Andrej Karpathy deliver a talk on Software 3.0, where he talked about coding in English, and notably expressed frustration with setting up authentication 😖. Inspired to address this issue (and to try out coding in English), I began experimenting with the Model Context Protocol (MCP) to enable the creation and management of Hellō apps directly from VS Code, Cursor, Claude, or other LLM clients.

It is now available as a beta! Installation directions are in the documentation and its open source. We are still learning (with the rest of the world) how to provide the right context to LLMs. Feedback and PRs welcome! Note that most of the code, docs, and tests are generated by Cursor and Claude Sonnet 4.

Security Considerations

Dynamic Client Registration

MCP Authorization uses OAuth 2.1 👍 and also Dynamic Client Registration (DCR) 👎. I’ve never been a fan of DCR — never had a need for it — but given the way MCP was using OAuth, DCR support is required. DCR enables an OAuth client to register its redirect_uri, and gets back a client_id. This happens for each install of the client, so each developer gets their own client_id. There is no guidance on the lifecycle of a client (do we keep them forever?) and given the low friction, I was not keen on a malicious actor generating millions of client records for fun. We ended up creating a registration endpoint just for MCP clients that always gives back the same client_id and supports any redirect_uri passed. Not what DCR intended, but let’s see how that works.

Destructive Operations

Unlike our web UI where we require the user to enter DELETE to delete their app, there are no confirmation flows in MCP. We want developers to be able to do more that just create an app, which is what our quickstart scope allows, but we did not want to enable destruction actions that are enabled with the console scope, so we created the mcp scope that allows creating and updating apps, but not deleting them. To lower the friction for the user to delete or do other management in the console, we provide a third party initiated login link in the results to the LLM:
https://console.hello.coop/
?iss=https%3A%2F%2Fissuer.hello.coop
&client_id={client_id}
&login_hint={user_id}

Bearer Tokens

As MPC does not require DPoP to prove possession of a key, the access tokens are bearer tokens, and with the rapid pace of MCP development, there are likely MCP Clients that are not careful with their tokens, and a malicious actor could obtain them and have access to the developers applications — another reason to limit to enable destructive operations. We decided not to support refresh tokens — which would be long lived bearer tokens — and require the developer to reauthorize the client if whenever they want to manage their Hellō app, which is likely an infrequent operation once created and configured.

Lessons Learned

Coding in english is eye opening. It is like guiding an eager junior programming who has lots of knowledge but not much expertise and gets carried away trying to help, and can type 100x faster than I can.

OAuth between the client and server is not a good fit in my opinion. The client is general purpose and great at learning about the functionality the server is offering — but despite the dream of some members of the OAuth community, it is not well suited to this use case. Perhaps some extensions can resolve the challenges of DCR and fine grained access — but in my opinion resource authorization should be pushed down to the MCP Server, which can use OAuth for existing APIs, or it can use any other authorization mechanism that an organization has deployed such as fine grained access control. I wrote an MCP Specification Enhancement Proposal (SEP) for HTTP message signing between MCP Client and Server, and a mechanism for the server to request a direct interaction with the server. Let’s see what others think!

Say "Hellō" to AI