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.
3. Pergunta a esse autorizador como ele quer receber o pedido.
4. Se apresenta como aplicativo — a maioria dos serviços aceita isso na hora. Quando não aceita, 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.

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