Val Town: демо с 3613 OAuth-коннекторами через MCP

Val Town, платформа для «вайб-кодинга» (написания приложений с помощью ИИ), в своём блоге разобрала классическую проблему n²: чтобы связать каждое приложение с каждым другим, нужно столько же интеграций, сколько пар приложений, и у Zapier это решено огромной ручной библиотекой коннекторов. OAuth почти решает задачу аутентификации и авторизации между приложениями, но не до конца: каждое приложение всё равно должно вручную зарегистрироваться как OAuth-клиент в каждом другом сервисе. В лучшем случае это 5 минут в панели разработчика, в худшем, формы, демо-видео, бумажная волокита или созвон с менеджером, и так для каждого нового сервиса.

По изложению автора поста, эту проблему заранее увидели Anthropic и OpenAI: им нужно было подключаться к приложениям всех своих пользователей, но заводить OAuth-клиента отдельно под каждое такое приложение было нереально. Поэтому в спецификацию протокола MCP добавили малоизвестное расширение OAuth, Dynamic Client Registration (DCR). DCR автоматизирует регистрацию клиента: вместо человека, вручную получающего OAuth-клиента, приложение само динамически создаёт его и сразу начинает OAuth-flow с сервисом, о котором раньше ничего не знало. В Val Town об DCR узнали, делая собственный MCP-сервер, именно он позволяет подключать аккаунт Val Town через Claude и ChatGPT. Но DCR работает не только с этими двумя ассистентами: любое приложение может динамически зарегистрировать OAuth-клиента у Val Town и подключиться к аккаунту пользователя. На этой основе в Val Town сделали библиотеку-middleware std/oauth: она добавляет кнопку «Войти через Val Town» всего в две строки кода поверх фреймворка Hono, и никакой отдельной настройки не требуется, если скопировать приложение через функцию «remix» на Val Town, вход тут же заработает, а OAuth-клиент к Val Town создастся автоматически при первом входе пользователя.

CIMD (Client ID Metadata Documents) идёт ещё дальше и вовсе убирает шаг предварительной регистрации: приложение публикует данные о своём OAuth-клиенте по обычному URL и сразу же может начинать OAuth-flow с любым сервисом, поддерживающим CIMD. Пример из поста, эндпоинт Notion (mcp.notion.com/.well-known/oauth-authorization-server), который отдаёт JSON с адресами авторизации, токена, регистрации и другими параметрами; любое CIMD-совместимое приложение может подключиться к Notion, никогда раньше о нём не «слышав». По словам автора, DCR сейчас поддерживают тысячи приложений, а CIMD, сотни, и оба протокола распространились очень быстро как побочный эффект того, что множество компаний массово делают MCP-серверы для интеграции с Claude и ChatGPT.

Чтобы показать масштаб, автор собрал живое демо-приложение с 3613 коннекторами (список собран из реестра mcpservers.org) и выложил его по адресу oauth-demos.val.run. Ключевой момент: если развернуть копию этого приложения на Val Town через «remix», все коннекторы сразу заработают, получать собственного OAuth-клиента для каждого сервиса не нужно.

Автор честно перечисляет нерешённые проблемы. Во-первых, не все «динамические» эндпоинты регистрации на самом деле динамические: попытка подключиться к Google Ads в демо-приложении выдаёт ошибку «redirect host not in platform catalog», сервис всё равно требует, чтобы вызывающее приложение было заранее внесено в его каталог. Во-вторых, DCR/CIMD могут работать только для вызовов через MCP и не давать доступа к обычному REST API того же сервиса: например, дашборд Stripe через DCR можно подключить к MCP-серверу Stripe, но не к его REST API. По мнению автора, ключевое различие REST API и MCP, в обещании стабильности: REST-провайдеры вроде Stripe гарантируют, что вызовы не сломаются, потому что код хрупок, а в MCP предполагается, что по обе стороны вызова есть «рассуждающая» сторона (LLM), которая может заметить ошибку или изменение поведения и подстроиться на лету, по этой метафоре MCP-сервер ближе к пользовательскому интерфейсу, чем к API. В самой Val Town эту границу стёрли: любой токен, полученный через DCR, работает и с MCP-сервером компании, и с её REST API. В-третьих, пока нет ни открытого публичного реестра всех таких коннекторов (свой список автор просто собрал парсингом с mcpservers.org), ни open-source инструментов уровня Zapier SDK, Pipedream Connect или Nango, которые бы упростили работу с DCR/CIMD.

В перспективе автор связывает DCR/CIMD с протоколом x402, который должен решить вторую половину задачи, оплату эпизодического доступа к платным API без привязки банковской карты и без создания отдельного аккаунта. Вместе эти два протокола, по мысли автора, ведут к будущему, где вайб-кодинговым приложениям вообще не нужны API-ключи в переменных окружения: получать и вставлять ключ вручную не придётся. Отдельно в посте упомянуто, что более полный разбор технических сложностей внедрения DCR написал Пол Карлтон (Paul Carleton) из команды MCP.

Ключевые факты

Val Town построила и опубликовала демо-приложение с 3613 OAuth-коннекторами, собрав список сервисов из реестра mcpservers.org.
Dynamic Client Registration (DCR), расширение OAuth в спецификации MCP: приложение само динамически регистрирует OAuth-клиента и сразу начинает авторизацию с сервисом, которого раньше не знало, без ручной регистрации в панели разработчика.
Client ID Metadata Documents (CIMD) идёт дальше: приложение публикует метаданные OAuth-клиента по URL и вовсе не регистрируется заранее, так, например, устроен эндпоинт Notion.
По словам автора, DCR сейчас поддерживают тысячи приложений, CIMD, сотни; в Val Town собственная библиотека std/oauth добавляет вход через Val Town в две строки кода.
Остаются проблемы: не все площадки (пример, Google Ads) на самом деле поддерживают динамическую регистрацию; DCR/CIMD может авторизовать только MCP-вызовы, а не обычный REST API; открытого реестра коннекторов и готовых open-source инструментов пока нет.

Почему это важно

Проблема n², связать каждое приложение с каждым другим, раньше решалась только вручную, как в библиотеке коннекторов Zapier. DCR и CIMD, добавленные в спецификацию MCP изначально для того, чтобы Anthropic и OpenAI могли подключаться к приложениям своих пользователей, оказались побочным эффектом, который решает и общую задачу: тысячи компаний, делавшие MCP-серверы для Claude и ChatGPT, заодно сделали свои приложения совместимыми друг с другом напрямую, без Zapier-подобного посредника.

Кому это важно

Разработчикам интеграций, платформам вайб-кодинга и no-code/low-code-инструментам, которым раньше приходилось вручную регистрировать OAuth-клиента под каждый внешний сервис; инфраструктурным инженерам, проектирующим авторизацию для собственных MCP-серверов; и авторам будущих open-source инструментов для работы с DCR/CIMD по аналогии с Zapier SDK, Pipedream Connect или Nango.

Как это применить

На Val Town можно скопировать приложение через «remix» и получить рабочую OAuth-авторизацию сразу, без отдельной настройки, OAuth-клиент создаётся автоматически при первом входе пользователя; библиотека std/oauth добавляет вход через Val Town в две строки кода поверх Hono. К любому CIMD-совместимому сервису (пример из поста, Notion) можно подключиться, просто прочитав его метаданные по адресу вида /.well-known/oauth-authorization-server, без предварительной регистрации клиента. Список готовых коннекторов и живой пример собраны в демо-приложении на oauth-demos.val.run.

Можно ли доверять

Материал, блог самой компании Val Town о её собственном продукте и демо, поэтому это не независимая проверка, а изложение с точки зрения вендора. При этом автор не только хвалит подход, но и подробно перечисляет его слабые места на конкретном примере (ошибка при попытке подключить Google Ads), что скорее повышает доверие к разбору. Точных цифр по числу поддерживающих DCR и CIMD сервисов источник не даёт, только оценки «тысячи» и «сотни»; имя автора поста в тексте не указано.

Риски и подводные камни

Часть сервисов заявляет поддержку динамической регистрации, но на деле всё равно требует предварительного внесения в закрытый каталог, так ведёт себя Google Ads в демо-приложении. DCR/CIMD может авторизовать только вызовы через MCP и не давать доступа к обычному REST API того же сервиса: в Val Town это решили тем, что один токен работает и там, и там, но это решение самой компании, а не гарантия протокола. Открытого публичного реестра коннекторов пока нет, автор собирал список парсингом из mcpservers.org, и нет готовых open-source библиотек для работы с этим подходом. Идея избавиться от API-ключей вовсе за счёт протокола x402 упомянута как перспектива, а не как работающее решение.