Val Town demos 3,613 app-to-app OAuth connectors via MCP
Val Town's blog post describes a way around the classic "n squared" problem of connecting every app to every other app: instead of each app manually registering as an OAuth client with every other app it wants to talk to, two OAuth extensions built for the Model Context Protocol (MCP) let that registration happen automatically. The first, Dynamic Client Registration (DCR), lets an app dynamically provision its own OAuth client and immediately start the OAuth flow with an app it has never talked to before, instead of requiring a person to click through a developer portal, fill out forms, or get on a call. The post's author writes that Anthropic and OpenAI anticipated this problem because they needed a way to connect to all of their customers' apps without registering a separate OAuth client for each one, so they put DCR into the MCP specification. Val Town, described in the post as "a vibe coding platform," learned about DCR while building its own MCP server and plugin, the mechanism that lets users OAuth into Val Town from Claude and ChatGPT; the company then built std/oauth on top of it, a middleware library that adds "Login with Val Town" OAuth to a Val Town app in two lines of code, with no separate setup step because Val Town runs both the authorization server and the app's own infrastructure.
The second extension, Client ID Metadata Documents (CIMD), goes further: instead of registering a client at all, an app self-hosts its OAuth client data at a URL and can start an OAuth flow immediately. The post gives Notion's CIMD endpoint, https://mcp.notion.com/.well-known/oauth-authorization-server, as a working example, showing the JSON metadata document that any CIMD-aware app can read to authorize with Notion on the spot. The author reports that thousands of apps now support DCR and hundreds support CIMD, a pace of adoption he says he cannot recall another software protocol matching, and credits it to developers inadvertently making their apps connectable to each other while building MCP servers for ChatGPT and Claude. To demonstrate the idea, he built a live demo app at oauth-demos.val.run wired up with 3,613 connectors scraped from the registry mcpservers.org; remixing (copying) the app on Val Town makes every one of those connectors work immediately, without the person doing the remix needing to obtain a single OAuth client of their own.
The post is candid that the dream is not fully realized yet, even at Val Town, and lists three open problems. First, many "dynamic" registration endpoints are not actually dynamic: trying to connect the demo app to Google Ads returns the error "redirect host not in platform catalog: oauth-demos.val.run", meaning the caller still has to be pre-registered in Google's own catalog. Second, DCR and CIMD may only work for MCP rather than an app's normal REST API; Val Town's own workaround is that any token obtained through DCR works against both its MCP server and its REST API, given the right permissions. The author argues the deeper issue is conceptual, not just technical: a REST API like Stripe's promises stability because code is brittle and cannot adapt when an interface changes, while an MCP server behaves more like a user interface, since there is inference, an LLM reading the toolset and error-correcting, on both sides of the call. Third, there is no public registry of these connectors yet (his own list came from scraping mcpservers.org), and the ecosystem still lacks open-source tooling to manage them, comparable to the Zapier SDK, Pipedream Connect, or Nango.
The post closes by pointing at a separate, unsolved half of the problem: paying for a pay-per-use API you have no account with at all. The author suggests a payment protocol called x402 could handle that side, so that DCR/CIMD together with x402 point toward apps that need no API keys stored as environment variables, which he frames as a real reduction in manual setup work for "vibe coding," where a whole app can be generated in minutes. The post ends with a one-line note that Val Town is hiring infrastructure engineers.
Key facts
- Val Town built a live demo app at oauth-demos.val.run wired up with 3,613 OAuth connectors, scraped from the mcpservers.org registry.
- Two OAuth extensions originally built for MCP, Dynamic Client Registration (DCR) and Client ID Metadata Documents (CIMD), let one app connect to another app's OAuth without manual client registration.
- The author says Anthropic and OpenAI put DCR into the MCP spec because they needed to connect to all their customers' apps without registering a separate OAuth client for each one.
- Thousands of apps now support DCR and hundreds support CIMD, according to the author's own count.
- Not all "dynamic" registration is truly dynamic: connecting the demo app to Google Ads fails with a "redirect host not in platform catalog" error because Google Ads still requires pre-registration in its own catalog.
Why it matters
Connecting every app to every other app is normally an n squared problem: each pair of apps needs its own manual OAuth registration, a process the author describes as anything from five minutes of clicking to forms, demo videos and video calls. DCR and CIMD, both built as extensions to MCP's OAuth flow so that Claude and ChatGPT could connect to customers' apps without Anthropic or OpenAI registering a client for each one, turn out to solve that same problem for any two ordinary apps, not just AI assistants. The post frames this as a side effect nobody quite planned: everyone building MCP servers to plug into ChatGPT and Claude ended up making their apps connectable to each other as well.
Who it affects
Application developers who currently maintain manual OAuth integrations one app at a time, and platforms like Val Town that want "Login with X" flows without asking every partner app to pre-register. It also touches Anthropic and OpenAI directly, credited in the post as the ones who pushed DCR into the MCP spec in the first place, and any service such as Notion or Google Ads that exposes (or, in Google Ads' case, only partly exposes) a DCR or CIMD endpoint for others to connect to.
How to use it
Val Town's own implementation is std/oauth, a middleware library that adds "Login with Val Town" OAuth to a Val Town app in two lines of code; remixing the example app on Val Town gets working OAuth immediately, with the app's own OAuth client created automatically the first time a user logs in. CIMD works the other way: an app self-hosts its OAuth client metadata at a URL, such as Notion's https://mcp.notion.com/.well-known/oauth-authorization-server, and any CIMD-aware caller can read that document and start an OAuth flow without registering anything in advance. The post's live demo, oauth-demos.val.run, lets anyone try connecting to any of its 3,613 listed connectors directly. No pricing or paid tier is mentioned anywhere in the post.
How solid is it
The account comes from a single source: a blog post by Val Town, the company that built the demo, describing its own product and its own numbers. The 3,613 connector count and the demo app are concrete and independently checkable by visiting oauth-demos.val.run, but the broader adoption figures, "thousands" of apps supporting DCR and "hundreds" supporting CIMD, are given only as rounded, unsourced estimates from the author rather than measured totals. The failure case cited against Google Ads is the author's own first-hand test result, reproduced as an exact error message, which lends it more weight than an unverified claim.
Risks and caveats
The post itself is upfront that this is not yet the finished picture. Several endpoints billed as supporting dynamic registration, Google Ads among them, still require pre-registration in a private catalog, so DCR is not uniformly "dynamic" in practice. DCR and CIMD may only authorize MCP calls and not an app's ordinary REST API, a gap Val Town says it papers over for its own users but that is not solved generally. There is also no public registry of connectors yet, the author's own list came from scraping a third-party site (mcpservers.org), and no mature open-source tooling exists to manage these connections at scale.
“I believe, this is the single core difference between REST API vs MCP: the promise of stability.”
— Val Town blog post