ConfiguraçãoMCP

Transportes de servidor MCP

MCP suporta mecanismos de transporte para comunicação entre Bob e servidores MCP.

Visão geral

MCP oferece três opções de transporte, cada uma adequada para diferentes cenários de implantação:

Cada transporte tem características, vantagens e casos de uso distintos.

Transporte STDIO

O transporte STDIO é executado localmente na sua máquina e se comunica via fluxos de entrada/saída padrão.

Como o transporte STDIO funciona

  1. Bob gera um servidor MCP como um processo filho
  2. A comunicação acontece através de fluxos de processo: Bob escreve no STDIN do servidor, o servidor responde no STDOUT
  3. Cada mensagem é delimitada por um caractere de nova linha
  4. As mensagens são formatadas como JSON-RPC 2.0
Cliente                   Servidor
  |                         |
  |---- mensagem JSON ----->| (via STDIN)
  |                         | (processa solicitação)
  |<---- mensagem JSON -----| (via STDOUT)
  |                         |

Características do STDIO

  • Localidade: Executa na mesma máquina que Bob
  • Desempenho: Latência e sobrecarga muito baixas (sem pilha de rede envolvida)
  • Simplicidade: Comunicação direta de processo sem configuração de rede
  • Relacionamento: Relacionamento um-para-um entre cliente e servidor
  • Segurança: Inerentemente mais seguro sem exposição de rede

Quando usar STDIO

O transporte STDIO é ideal para:

  • Integrações locais e ferramentas executando na mesma máquina
  • Operações sensíveis à segurança
  • Requisitos de baixa latência
  • Cenários de cliente único (uma instância Bob por servidor)
  • Ferramentas de linha de comando ou extensões de IDE

Exemplo de implementação STDIO


const server = new Server({name: 'local-server', version: '1.0.0'});
// Registrar ferramentas...

// Usar transporte STDIO
const transport = new StdioServerTransport(server);
transport.listen();

Transporte HTTP Streamable

O transporte HTTP Streamable é o padrão moderno para comunicação de servidor MCP remoto, substituindo o transporte HTTP+SSE mais antigo. Ele opera sobre HTTP/HTTPS e permite implementações de servidor mais flexíveis.

Como o transporte HTTP Streamable funciona

  1. O servidor fornece um único endpoint HTTP (endpoint MCP) que suporta métodos POST e GET
  2. Bob envia solicitações para este endpoint MCP usando HTTP POST
  3. O servidor processa a solicitação e envia de volta uma resposta
  4. Opcionalmente, o servidor pode usar Server-Sent Events (SSE) sobre a mesma conexão para transmitir múltiplas mensagens ou notificações ao Bob

Isso permite interações básicas de solicitação-resposta, bem como streaming mais avançado e comunicação iniciada pelo servidor.

Cliente                            Servidor
  |                                  |
  |---- HTTP POST /mcp_endpoint ---->| (solicitação do cliente)
  |                                  | (processa solicitação)
  |<--- Resposta HTTP / Stream SSE --| (resposta do servidor / stream)
  |                                  |

Características do HTTP Streamable

  • Padrão moderno: Método preferido para novas implementações de servidor MCP remoto
  • Acesso remoto: Pode ser hospedado em uma máquina diferente do Bob
  • Escalabilidade: Pode lidar com múltiplas conexões de cliente simultaneamente
  • Protocolo: Funciona sobre HTTP/HTTPS padrão
  • Flexibilidade: Suporta solicitação-resposta simples e streaming avançado
  • Endpoint único: Usa um único caminho de URL para toda comunicação MCP
  • Autenticação: Pode usar mecanismos de autenticação HTTP padrão
  • Compatibilidade retroativa: Servidores podem manter compatibilidade com clientes HTTP+SSE mais antigos

Quando usar HTTP Streamable

O transporte HTTP Streamable é ideal para:

  • Todos os novos desenvolvimentos de servidor MCP remoto
  • Servidores que requerem comunicação robusta, escalável e flexível
  • Integrações que podem envolver streaming de dados ou notificações enviadas pelo servidor
  • Serviços públicos ou ferramentas centralizadas
  • Substituição de implementações de transporte SSE legado

Negociação de protocolo

Quando o Bob se liga a um servidor HTTP Streamable, usa a opção protocolNegotiation para determinar como acordar uma versão de protocolo. Os servidores HTTP têm como padrão "auto".

ValorDescrição
"auto"O Bob envia uma sonda server/discover antes de initialize para negociar a versão de protocolo mutuamente suportada mais alta. Padrão para servidores HTTP.
"legacy"O Bob ignora a sonda e liga-se diretamente usando o handshake initialize, que é compatível com todos os servidores MCP.
{ "pin": "<version>" }O Bob liga-se usando uma versão de protocolo específica (por exemplo, { "pin": "2024-11-05" }).

Se um servidor HTTP expirar com MCP connection timed out after 10000ms, o servidor pode não responder à sonda server/discover. Define "protocolNegotiation": "legacy" para ignorar a sonda:

{
  "mcpServers": {
    "my-server": {
      "url": "https://your-server-url.com/mcp",
      "protocolNegotiation": "legacy"
    }
  }
}

Para mais detalhes, consulte Negociação de protocolo em "Usando MCP no Bob".

Exemplo de implementação HTTP Streamable

Configuração em settings.json:

{
  "mcpServers": {
    "StreamableHTTPMCPName": {
      "type": "streamable-http",
      "url": "http://localhost:8080/mcp"
    }
  }
}

Para implementação do lado do servidor, consulte a documentação do SDK MCP para StreamableHTTPClientTransport.

Compatibilidade retroativa com HTTP+SSE

O cliente MCP do Bob não faz fallback para o transporte HTTP+SSE. A orientação abaixo destina-se a autores de servidores que querem que o seu servidor HTTP Streamable permaneça acessível a clientes mais antigos que ainda não suportam HTTP Streamable.

Servidores que precisem de suportar clientes mais antigos devem continuar a hospedar os endpoints SSE (/events) e POST (/message) do transporte antigo, juntamente com o novo endpoint MCP definido para o transporte HTTP Streamable.

Transporte SSE (removido)

O cliente MCP do Bob já não suporta o transporte HTTP+SSE standalone (especificação MCP 2024-11-05). Servidores que usem apenas o transporte HTTP+SSE não conseguem ligar ao Bob.

Nota:

O SSE como canal de resposta dentro de uma conexão HTTP Streamable ainda é suportado. O Bob pode receber streams SSE de um servidor HTTP Streamable. Apenas o transporte HTTP+SSE standalone (com endpoints /events e /message separados) foi removido.

Migrar do transporte SSE

Se tens um servidor existente que usa o transporte HTTP+SSE, migra-o para o transporte HTTP Streamable ou STDIO:

  • HTTP Streamable: Expõe um único endpoint MCP que aceita pedidos HTTP POST. É o caminho recomendado para servidores remotos. Consulta Transporte HTTP Streamable.
  • STDIO: Se o servidor corre localmente na mesma máquina que o Bob, converte-o para um servidor STDIO. Consulta Transporte STDIO.

Considerações de implantação

A escolha entre STDIO e o transporte HTTP Streamable impacta diretamente como você implanta e gerencia seus servidores MCP.

STDIO: Implantação local

Servidores STDIO são executados localmente na mesma máquina que Bob:

  • Instalação: O executável do servidor deve ser instalado na máquina de cada usuário
  • Distribuição: Você precisa fornecer pacotes de instalação para diferentes sistemas operacionais
  • Atualizações: Cada instância deve ser atualizada separadamente
  • Recursos: Usa CPU, memória e disco da máquina local
  • Controle de acesso: Depende das permissões do sistema de arquivos da máquina local
  • Integração: Fácil integração com recursos do sistema local (arquivos, processos)
  • Execução: Inicia e para com Bob (ciclo de vida de processo filho)
  • Dependências: Quaisquer dependências devem ser instaladas na máquina do usuário

Exemplo de caso de uso:

Uma ferramenta de busca de arquivo local usando STDIO:

  • Executa na máquina do usuário
  • Tem acesso direto ao sistema de arquivos local
  • Inicia quando necessário pelo Bob
  • Não requer configuração de rede
  • Precisa ser instalada junto com Bob ou via gerenciador de pacotes

Remoto: Implantação hospedada

Servidores remotos (HTTP Streamable) podem ser implantados em servidores remotos e acessados pela rede:

  • Instalação: Instalado uma vez em um servidor, acessado por muitos usuários
  • Distribuição: Implantação única serve múltiplos clientes
  • Atualizações: Atualizações centralizadas afetam todos os usuários imediatamente
  • Recursos: Usa recursos do servidor, não recursos da máquina local
  • Controle de acesso: Gerenciado através de sistemas de autenticação e autorização
  • Integração: Integração mais complexa com recursos específicos do usuário
  • Execução: Executa como um serviço independente (frequentemente continuamente)
  • Dependências: Gerenciadas no servidor, não nas máquinas dos usuários

Exemplo de caso de uso:

Uma ferramenta de consulta de banco de dados usando transporte remoto:

  • Executa em um servidor central
  • Conecta-se a bancos de dados com credenciais do lado do servidor
  • Está continuamente disponível para múltiplos usuários
  • Requer configuração adequada de segurança de rede
  • É implantada usando tecnologias de contêiner ou nuvem

Abordagens híbridas

Alguns cenários se beneficiam de uma abordagem híbrida:

  1. STDIO com acesso à rede: Um servidor STDIO local que atua como proxy para serviços remotos
  2. Remoto com comandos locais: Um servidor remoto que pode acionar operações na máquina cliente através de callbacks
  3. Padrão de gateway: Servidores STDIO para operações locais que se conectam a servidores remotos para funções especializadas

Comparação de transportes

ConsideraçãoSTDIOHTTP Streamable
LocalizaçãoApenas máquina localLocal ou remoto
ClientesCliente únicoMúltiplos clientes
DesempenhoMenor latênciaMaior latência (sobrecarga de rede)
Complexidade de configuraçãoMais simplesMais complexo (requer servidor HTTP)
SegurançaInerentemente seguroRequer medidas de segurança explícitas
Acesso à redeNão necessárioObrigatório
EscalabilidadeLimitado à máquina localPode distribuir pela rede
ImplantaçãoInstalação por usuárioInstalação centralizada
AtualizaçõesAtualizações distribuídasAtualizações centralizadas
Uso de recursosUsa recursos do clienteUsa recursos do servidor
DependênciasDependências do lado do clienteDependências do lado do servidor

Configurar transportes no Bob

Para informações detalhadas sobre configuração de transportes no Bob, incluindo exemplos de configuração, consulte MCP no Bob.

Como está este tópico?