Servidor remoto, conectado por endereço

Camada funcional

O caso comum: o serviço publica um endereço de MCP hospedado por ele, você cadastra esse endereço no agente, e as ferramentas de lá passam a estar à disposição dele. É a primeira opção na tela de conexão.

O que identifica esse servidor é o próprio endereço, único por agente. Ele roda no provedor, não aqui. E se autentica de três maneiras: cabeçalhos fixos que você informa, uma autorização feita numa janela do navegador, ou — quando o destino é um aplicativo publicado nesta mesma plataforma — a mesma autorização, com o agente certo já marcado para você.

Como o endereço é conferido antes de qualquer conexão

O endereço vem inteiro de você e é buscado pelo nosso servidor. É o cenário clássico em que alguém digita um endereço interno e usa a plataforma como ponte para alcançá-lo. Por isso ele passa pelo mesmo conferidor que o resto do produto usa: só endereços comuns da web, com o nome resolvido antes de sair, e recusa para tudo que aponte para dentro da própria infraestrutura.

O que essa proteção não pega, e está escrito de propósito: um endereço público que, ao ser acessado, redirecione para um endereço interno. Fechar isso exige um mecanismo de rede próprio, e está registrado como acompanhamento. A proteção existe, o buraco é conhecido e ninguém finge o contrário.

Quando o servidor pede autorização

Servidor que exige login não recebe uma senha sua: ele abre a janela de autorização dele, você aprova ali, e o VolundOS guarda o resultado. O caminho é o padrão da especificação do MCP, e vale a pena saber o que acontece porque é onde as coisas falham de forma visível:

1. O VolundOS toca o endereço e descobre que precisa de autorização.
2. Pergunta ao serviço quem autoriza por ele. Quando o endereço do servidor tem um caminho próprio (por exemplo, um serviço compartilhado que atende várias organizações, cada uma num endereço tipo .../<organização>/mcp), a busca por essa resposta respeita esse caminho em vez de olhar só a raiz do site — e confere se o documento encontrado realmente se declara dono daquele endereço antes de seguir. Sem essa conferência, uma raiz que também responde (mas fala por OUTRA organização do mesmo serviço) podia ser aceita em silêncio, levando você para o autorizador errado e terminando numa tela de erro do provedor sem pista do que houve.
3. Pergunta a esse autorizador como ele quer receber o pedido.
4. Se apresenta como aplicativo. Existem dois jeitos, e quem decide qual vale é o autorizador, não o VolundOS — o que manda é o que ele anuncia saber receber. Anunciando que aceita, o VolundOS se apresenta por um documento público e estável: o próprio autorizador busca esse documento no nosso endereço para saber quem somos, e não há cadastro nenhum a aprovar. Não anunciando, vale o caminho de sempre — se cadastrar na hora, que é o que a maioria dos serviços aceita. O documento passou a existir porque provedor grande fechou o cadastro na hora para aplicação hospedada, liberando só quem roda na própria máquina da pessoa. Antes de seguir pelo documento, o VolundOS confere na prática se o autorizador de fato o aceita — alguns anunciam que sim e, na hora, recusam; sem essa conferência, quem clicasse em Autorizar cairia numa tela de erro do provedor, em inglês, sem explicação nossa. Quando nenhum dos dois é aceito, você recebe uma mensagem dizendo exatamente isso, em vez de uma falha genérica.
5. Abre a janela de autorização para você.
6. Recebe a resposta e guarda a autorização. Se o autorizador recusar ou a sessão expirar antes disso, você volta para onde estava — a conversa de onde partiu a conexão, ou o agente, e só na ausência dessa informação a lista geral de agentes.

Conectar a um aplicativo da sua própria organização

Um aplicativo publicado pelos agentes da casa também oferece ferramentas por MCP. Até pouco tempo, conectar-se a um exigia saber o endereço de cor e digitá-lo à mão.

Hoje o diálogo de conexão tem uma terceira opção — "É um app da sua organização" —, que aparece primeiro quando existe algum aplicativo publicado. A lista traz todos eles, com quantas ferramentas cada um oferece e se você já tem acesso. Ao escolher, nome e endereço já vêm preenchidos e o teste de conexão dispara sozinho: o endereço nunca é montado pelo agente. O mesmo caminho existe na conversa — dá para pedir ao agente que liste os aplicativos e conecte a um deles pelo nome.

Três escolhas que valem ser explicadas:

• A lista mostra todos os aplicativos publicados, marcando aqueles a que você já tem acesso — nunca esconde os outros. Sem acesso, a conexão até se estabelece, só que sem poder fazer nada: quem recusa é o próprio aplicativo, na hora da ação. Esconder tiraria de quem não tem acesso o caminho de pedir.
• Aplicativo que ainda não dá para conectar continua na lista, com o motivo no lugar da descrição — ainda não publicado, versão antiga demais, endereço inválido. Sumir faz a pessoa procurar pelo nome, não achar e concluir que a tela quebrou.
• A autorização é sempre em nome de quem conecta. A tela de consentimento abre com o agente certo já marcado, mas ela marca — não autoriza. Você continua confirmando, e o que vale é a lista exibida na tela.

Isso não é um tipo novo de conexão: o aplicativo vira um servidor remoto comum. O que a lista resolve é a origem do endereço, não o protocolo.

A ressalva continua valendo para todo o resto: quando o serviço já está no catálogo de integrações, o caminho preferido é conectá-lo por lá. Para provedores fora dele, a tela ainda pede o endereço.

O que dá para fazer, e onde