Val Town says OAuth's DCR and CIMD could let any app connect to any other

A protocol for one-click connections

Val Town, a coding platform, has made the case that two OAuth extensions popularised by the Model Context Protocol (MCP) ecosystem could let any app authenticate into any other app with no manual setup — solving the integration problem that connector marketplaces such as Zapier's exist to manage. The post, published on the Val Town blog and featured on the Hacker News front page, opens with a familiar frustration: envy of Zapier's connector library and a wish for one-click connections.

The n² problem behind every connector

The author frames app-to-app integration as a classic n² problem: for every app to talk to every other app, each one has to register as an OAuth client with every provider. According to the post, registration is at best a few minutes of clicking through a developer portal, but it can also mean forms, demo videos, signed paperwork or calls with a human — and every app must repeat the process for each service its users request. OAuth comes close to being the universal protocol the author wants, but the client registration step keeps the combinatorial cost intact.

Dynamic Client Registration

The post credits Anthropic and OpenAI with anticipating this: their assistants needed to reach customers' apps without holding OAuth clients for all of them, so the MCP specification incorporated a little-known OAuth extension, Dynamic Client Registration (DCR). With DCR, an app provisions an OAuth client on the fly and immediately starts an authorization flow against a service it had never encountered before.

Val Town ran into DCR while building its MCP server, which is what lets users log into Val Town from Claude and ChatGPT. On top of that primitive the company built std/oauth, a middleware library that adds "Login with Val Town" to an app in two lines of code, with the OAuth client created behind the scenes when the first user logs in. The author is careful to note this isn't magic — Val Town runs both the authorization server and the app's infrastructure — but argues the library could be adapted to other infrastructure and to any provider that supports DCR.

Client ID Metadata Documents

Because DCR itself can be painful to implement, the post also highlights Client ID Metadata Documents (CIMD). With CIMD there is no pre-registration at all: an app self-hosts its OAuth client data at a URL and can launch an OAuth flow right away. Notion serves as the example, publishing server metadata, including a registration endpoint, at a well-known location, so any CIMD-capable app can begin an authorization flow with Notion on demand, even having never heard of it before.

The author reports that thousands of apps now support DCR and hundreds support CIMD, and attributes the unusually fast spread to the industry-wide rush to build MCP servers compatible with ChatGPT and Claude — a race that inadvertently made those apps connectable to each other. As a demonstration, the author built a live demo app exposing 3,613 connectors, all of which work immediately when the app is copied on Val Town, without registering a single OAuth client.

What still doesn't work

The post is candid that the goal remains unmet, and lists three gaps.

First, many DCR endpoints are not truly dynamic. Attempting to connect to Google Ads from the demo fails with an error saying the redirect host is not in the provider's platform catalog, meaning pre-registration is still required in practice.

Second, DCR and CIMD tokens may only be valid for a provider's MCP server, not its REST API — a real constraint for a coding platform whose users might, for example, want to build a Stripe dashboard. The post draws a sharp distinction between the two surfaces: REST APIs promise stability because code breaks when contracts change, while MCP servers, like user interfaces, tolerate change because an LLM sits on both sides of each call and can adapt when something behaves differently. Val Town's own mitigation is to accept tokens obtained via DCR on both its MCP server and its REST API.

Third, tooling is missing. The author calls for a public registry of connectors, having assembled the demo's list by scraping a third-party source.

Why it matters

Integration between apps has historically been gated by developer portals, paperwork and per-provider negotiation, which is why middleware vendors could build businesses on connector libraries. If DCR and CIMD become standard practice beyond the AI assistants that drove their adoption, that cost collapses: a small app could gain the connective tissue that only large platforms could previously afford. The MCP boom may come to matter not just for AI tool access but for accidentally standardising app-to-app authentication. Whether that happens depends on two concessions the Val Town post shows are not yet universal: providers honouring genuinely dynamic registration, and letting tokens work across both MCP and REST surfaces.