Transportes de servidor MCP

Visão geral

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

• Transporte STDIO (servidores locais)
• Transporte HTTP Streamable (padrão moderno para servidores remotos)
• Transporte SSE (opção remota legada)

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

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

Clientes e servidores podem manter compatibilidade retroativa com o transporte HTTP+SSE obsoleto.

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

Transporte SSE (legado)

O transporte Server-Sent Events (SSE) é executado em um servidor remoto e se comunica sobre HTTP/HTTPS. Para novos servidores remotos, use o transporte HTTP Streamable em vez disso.

Como o transporte SSE funciona

1. Bob conecta-se ao endpoint SSE do servidor via solicitação HTTP GET
2. Isso estabelece uma conexão persistente onde o servidor pode enviar eventos ao Bob
3. Para comunicação cliente-servidor, Bob faz solicitações HTTP POST para um endpoint separado
4. A comunicação acontece em dois canais:
   • Stream de eventos (GET): Atualizações servidor-cliente
   • Endpoint de mensagem (POST): Solicitações cliente-servidor

Cliente                            Servidor
  |                                  |
  |---- HTTP GET /events ----------->| (estabelecer conexão SSE)
  |<---- stream de eventos SSE ------| (conexão persistente)
  |                                  |
  |---- HTTP POST /message --------->| (solicitação do cliente)
  |<---- evento SSE com resposta ----| (resposta do servidor)
  |                                  |

Características do SSE

• 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 padrão (sem protocolos especiais necessários)
• Persistência: Mantém uma conexão persistente para mensagens servidor-cliente
• Autenticação: Pode usar mecanismos de autenticação HTTP padrão

Quando usar SSE

O transporte SSE é adequado para:

• Acesso remoto através de redes
• Cenários multi-cliente
• Serviços públicos
• Ferramentas centralizadas que muitos usuários precisam acessar
• Integração com serviços web

Exemplo de implementação SSE

import express from 'express';

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

// Usar transporte SSE
const transport = new SSEServerTransport(server);
app.use('/mcp', transport.requestHandler());
app.listen(3000, () => {
  console.log('Servidor MCP ouvindo na porta 3000');
});

Considerações de implantação

A escolha entre STDIO e transportes remotos (HTTP Streamable ou SSE) 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 ou SSE) 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

Configurar transportes no Bob

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