osFoundry / Platform
Коннекторы
Каталог всех интеграций, которые поддерживает платформа — официальные и от сообщества.
Что это
Коннекторы — это единый каталог osFoundry со всеми интеграциями, до которых может дотянуться рабочее пространство, и он охватывает два вида объектов: API-коннекторы (внешний HTTP API за OAuth, API-ключом, bearer или basic-аутентификацией) и MCP-серверы (инструменты Model Context Protocol, которые либо работают локально на вашем устройстве, либо размещены по HTTP). Вместо того чтобы разбрасывать интеграции по отдельным страницам настроек, экран обзора группирует всё по категориям: провайдеры ИИ, продуктивность, коммуникации, инструменты разработчика, хранилища, соцсети и MCP, с живым поиском по именам, описаниям и тегам, чтобы вы находили нужную возможность так, как искали бы её на самом деле.
Внутри osFoundry каталог не является статичным списком. Панель Discover ищет в официальном MCP Registry прямо из приложения, поэтому «что я мог бы добавить» оказывается рядом с «что у меня уже есть». Вы можете ввести запрос или вставить URL репозитория GitHub, и osFoundry разрешает его в структурированный, готовый к установке сервер (команда, аргументы и требуемые переменные окружения), а не гадает по README. Поскольку публикация в реестре не требует разрешения, каждый результат показывает своё происхождение: значок проверенного пространства имён сообщает, что издатель подтвердил, кто он (GitHub OAuth для пространств io.github.* или DNS/HTTP-подтверждение для домена), и это именно тот сигнал, который нужен, чтобы отличить настоящий сервер от тайпсквота до установки. Карточки отмечают, работает ли сервер на вашем устройстве (stdio) или размещён (HTTP), и добавлен ли он уже.
Это важно, потому что osFoundry работает по принципу BYOK и local-first. Вы подключаете свои аккаунты со своими учётными данными, без наценки перепродавца, а секреты хранятся в связке ключей операционной системы и никогда не попадают ни в определение коннектора, ни в контекст, отправляемый модели. Когда коннектор настроен, агенты и приложения рабочего пространства используют его через контролируемый администратором, поддающийся аудиту прокси: приложения работают без прямого доступа к сети и вызывают connector.call(), поэтому каждый исходящий запрос сверяется с манифестом приложения и логируется. Обнаружение обновлений отмечает, когда у установленного сервера из реестра появляется новая версия, и никогда не запускает новый код молча: изменённая команда или URL сервера запрашивает то же явное согласие, что и первая установка.
Ключевые возможности
- Просматривайте все интеграции в одном каталоге: API-коннекторы и MCP-серверы, сгруппированные по категориям (провайдеры ИИ, продуктивность, коммуникации, инструменты разработчика, хранилища и другие), с поиском по именам, описаниям и тегам
- Находите серверы сообщества из официального MCP Registry (registry.modelcontextprotocol.io) прямо в приложении или вставьте URL репозитория GitHub, чтобы разрешить его в устанавливаемый сервер
- Смотрите, кто опубликовал сервер, до установки: значок проверки отмечает проверенные в реестре пространства имён (GitHub OAuth или DNS/HTTP-подтверждение) и отличает собственные записи от записей сообщества без разрешения
- Устанавливайте локальные (stdio на устройстве) серверы, работающие дочерним процессом на вашей машине, или размещённые (HTTP) серверы, опосредованные платформой: учётные данные остаются в связке ключей ОС и никогда не попадают в определение коннектора
- Подключайте свои аккаунты со своими ключами (OAuth, API-ключ, bearer или basic), без наценки перепродавца, и позволяйте агентам и приложениям вызывать эти инструменты через контролируемый администратором, поддающийся аудиту прокси коннекторов
Сценарии использования
- Администратор рабочего пространства: один раз настраивает API-коннектор для Twitter/X или Salesforce (базовый URL, области OAuth), чтобы каждое приложение и агент в пространстве могли вызывать его через прокси без того, чтобы каждый пользователь подключал учётные данные
- Разработчик или продвинутый пользователь: вставляет GitHub-URL MCP-сервера, видит, что это проверенное пространство имён io.github, устанавливает его как локальный stdio-сервер и сразу вызывает его инструменты из чата
- Команда, заботящаяся о приватности: держит API-ключи в связке ключей ОС и запускает локальные MCP-серверы на устройстве, чтобы данные и учётные данные никогда не покидали машину, при этом продолжая просматривать интеграции сообщества в одном каталоге
Часто задаваемые вопросы
В чём здесь разница между API-коннектором и MCP-сервером?
API-коннектор оборачивает конкретный внешний HTTP API за методом аутентификации (OAuth, API-ключ, bearer или basic) и обычно создаётся один раз администратором рабочего пространства, а затем вызывается приложениями и агентами через прокси коннекторов. MCP-сервер предоставляет инструменты через Model Context Protocol: он либо работает локально дочерним процессом на вашем устройстве (stdio), либо доступен по HTTP (размещённый). Оба появляются в одном каталоге с тегом API или MCP, так что вы просматриваете их вместе.
Откуда берутся коннекторы сообщества и безопасны ли они?
Панель Discover ищет в официальном MCP Registry (registry.modelcontextprotocol.io), куда может публиковать кто угодно. osFoundry показывает значок проверки, когда пространство имён издателя проверено: GitHub OAuth для имён io.github.* или DNS/HTTP-подтверждение для домена. Это доказывает, кто опубликовал сервер, а не то, что его код безопасен, поэтому вам следует проверить издателя перед установкой. Локальные серверы работают на вашей машине, и требуемые ими переменные окружения показываются заранее.
Где хранятся мои учётные данные?
Секреты никогда не хранятся в определении коннектора и не отправляются модели: каталог несёт только имена переменных и заголовков, но не их значения. Для локальных MCP-серверов учётные данные хранятся в связке ключей операционной системы. Учётные данные API-коннекторов расшифровываются только на стороне сервера, чтобы построить заголовки аутентификации, когда прокси делает запрос от имени приложения, и этот запрос сверяется с манифестом приложения и поддаётся аудиту. Это согласуется с тем, что osFoundry работает по принципу BYOK и local-first.