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:
- Transporte STDIO (servidores locais)
- Transporte HTTP Streamable (padrão moderno para servidores remotos)
- Transporte SSE (removido)
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
- Bob gera um servidor MCP como um processo filho
- A comunicação acontece através de fluxos de processo: Bob escreve no STDIN do servidor, o servidor responde no STDOUT
- Cada mensagem é delimitada por um caractere de nova linha
- 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
- O servidor fornece um único endpoint HTTP (endpoint MCP) que suporta métodos POST e GET
- Bob envia solicitações para este endpoint MCP usando HTTP POST
- O servidor processa a solicitação e envia de volta uma resposta
- 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".
| Valor | Descriçã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.
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:
- STDIO com acesso à rede: Um servidor STDIO local que atua como proxy para serviços remotos
- Remoto com comandos locais: Um servidor remoto que pode acionar operações na máquina cliente através de callbacks
- 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ção | STDIO | HTTP Streamable |
|---|---|---|
| Localização | Apenas máquina local | Local ou remoto |
| Clientes | Cliente único | Múltiplos clientes |
| Desempenho | Menor latência | Maior latência (sobrecarga de rede) |
| Complexidade de configuração | Mais simples | Mais complexo (requer servidor HTTP) |
| Segurança | Inerentemente seguro | Requer medidas de segurança explícitas |
| Acesso à rede | Não necessário | Obrigatório |
| Escalabilidade | Limitado à máquina local | Pode distribuir pela rede |
| Implantação | Instalação por usuário | Instalação centralizada |
| Atualizações | Atualizações distribuídas | Atualizações centralizadas |
| Uso de recursos | Usa recursos do cliente | Usa recursos do servidor |
| Dependências | Dependências do lado do cliente | Dependê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.
Entendendo MCP
O Model Context Protocol (MCP) é um protocolo de comunicação padronizado que permite que sistemas de IA interajam com ferramentas e serviços externos.
Usando MCP no Bob
O Model Context Protocol (MCP) estende as capacidades do Bob conectando-se a ferramentas e serviços externos. Este guia mostra como configurar, gerenciar e usar servidores MCP com Bob.