osFoundry / Platform
Conectores
Um catálogo de cada integração que a plataforma suporta — first-party e da comunidade.
O que é
Conectores é o catálogo único do osFoundry com todas as integrações que o espaço de trabalho consegue alcançar, abrangendo dois tipos de coisa: conectores de API (uma API HTTP externa por trás de OAuth, chave de API, bearer ou autenticação básica) e servidores MCP (ferramentas do Model Context Protocol que rodam localmente no seu dispositivo ou são hospedadas por HTTP). Em vez de espalhar as integrações por páginas de configuração separadas, a tela de navegação agrupa tudo por categoria: provedores de IA, produtividade, comunicação, ferramentas de desenvolvimento, armazenamento, redes sociais e MCP, com uma busca ao vivo sobre nomes, descrições e tags para que você encontre uma capacidade do jeito que realmente a procuraria.
Dentro do osFoundry, o catálogo não é uma lista estática. O painel Descobrir busca no MCP Registry oficial de dentro do app, de modo que "o que eu poderia adicionar" fica logo ao lado de "o que eu já tenho". Você pode digitar uma consulta ou colar a URL de um repositório do GitHub, e o osFoundry a resolve em um servidor estruturado e instalável (comando, argumentos e variáveis de ambiente necessárias), em vez de adivinhar a partir de um README. Como a publicação no registro não exige permissão, cada resultado mostra sua procedência: um selo de namespace verificado indica que o publicador provou quem é (OAuth do GitHub para namespaces io.github.*, ou prova DNS/HTTP para um domínio), que é exatamente o sinal de que você precisa para distinguir um servidor legítimo de um typosquat antes de instalá-lo. Os cartões indicam se um servidor roda no seu dispositivo (stdio) ou é hospedado (HTTP), e se já foi adicionado.
Isso importa porque o osFoundry é BYOK (você traz sua própria chave) e local-first. Você conecta suas próprias contas com suas próprias credenciais, sem sobretaxa de revenda, e os segredos ficam no keychain do sistema operacional, nunca dentro da definição do conector nem no contexto enviado a um modelo. Uma vez que um conector esteja no lugar, agentes e apps do espaço de trabalho o usam por meio de um proxy auditável e controlado pelo administrador: os apps rodam sem acesso direto à rede e chamam connector.call(), de modo que cada requisição de saída é verificada contra o manifesto do app e registrada. A detecção de atualizações avisa quando um servidor do registro já instalado tem uma versão mais nova, e nunca reexecuta código novo em silêncio: um comando ou URL de servidor que muda pede o mesmo consentimento explícito que a primeira instalação.
Principais recursos
- Explore todas as integrações em um só catálogo: conectores de API e servidores MCP, agrupados por categoria (provedores de IA, produtividade, comunicação, ferramentas de dev, armazenamento e mais) com busca sobre nomes, descrições e tags
- Descubra servidores da comunidade do MCP Registry oficial (registry.modelcontextprotocol.io) direto no app, ou cole a URL de um repositório do GitHub para resolvê-la em um servidor instalável
- Veja quem publicou um servidor antes de instalar: um selo de verificação marca namespaces verificados no registro (OAuth do GitHub ou prova DNS/HTTP) e distingue o que é próprio das entradas de comunidade sem permissão
- Instale servidores locais (stdio no dispositivo) que rodam como processo filho na sua própria máquina, ou servidores hospedados (HTTP) mediados pela plataforma: as credenciais ficam no keychain do sistema, nunca na definição do conector
- Conecte suas próprias contas com suas próprias chaves (OAuth, chave de API, bearer ou básica), sem sobretaxa de revenda, e deixe agentes e apps chamarem essas ferramentas por um proxy de conectores auditável e controlado pelo administrador
Casos de uso
- Administrador do espaço de trabalho: configura uma vez um conector de API do Twitter/X ou Salesforce (URL base, escopos de OAuth) para que todo app e agente do espaço possa chamá-lo pelo proxy sem cada usuário ligar credenciais
- Desenvolvedor ou usuário avançado: cola a URL do GitHub de um servidor MCP, vê que é um namespace io.github verificado, instala como servidor stdio local e já chama suas ferramentas no chat
- Equipe atenta à privacidade: mantém as chaves de API no keychain do sistema e roda servidores MCP locais no dispositivo para que dados e credenciais nunca saiam da máquina, enquanto navega pelas integrações da comunidade em um só catálogo
Perguntas frequentes
Qual a diferença entre um conector de API e um servidor MCP aqui?
Um conector de API envolve uma API HTTP externa específica por trás de um método de autenticação (OAuth, chave de API, bearer ou básica) e normalmente é criado uma vez por um administrador do espaço de trabalho, para depois ser chamado por apps e agentes através do proxy de conectores. Um servidor MCP expõe ferramentas via Model Context Protocol: roda localmente como processo filho no seu dispositivo (stdio) ou é alcançado por HTTP (hospedado). Ambos aparecem no mesmo catálogo, marcados como API ou MCP, então você os navega juntos.
De onde vêm os conectores da comunidade e são seguros?
O painel Descobrir busca no MCP Registry oficial (registry.modelcontextprotocol.io), onde qualquer um pode publicar. O osFoundry mostra um selo de verificação quando o namespace do publicador é verificado: OAuth do GitHub para nomes io.github.* ou prova DNS/HTTP para um domínio. Isso prova quem publicou um servidor, não que o código dele seja seguro, então espera-se que você confira o publicador antes de instalar. Servidores locais rodam na sua própria máquina e suas variáveis de ambiente necessárias são mostradas de antemão.
Onde ficam guardadas minhas credenciais?
Os segredos nunca ficam na definição do conector nem são enviados ao modelo: o catálogo carrega apenas nomes de variáveis e cabeçalhos, não seus valores. Para servidores MCP locais, as credenciais ficam no keychain do sistema operacional. As credenciais de conectores de API só são descriptografadas no servidor para montar cabeçalhos de autenticação quando o proxy faz uma requisição em nome de um app, e essa requisição é verificada contra o manifesto do app e é auditável. Isso é coerente com o osFoundry ser BYOK e local-first.