Transportes de Servidor MCP: STDIO e SSE
O Protocolo de Contexto de Modelo (MCP) suporta dois mecanismos de transporte primários para comunicação entre o AI Cockpit Reasoning e os servidores MCP: Entrada/Saída Padrão (STDIO) e Eventos Enviados pelo Servidor (SSE). Cada um tem características, vantagens e casos de uso distintos.
Transporte STDIO
O transporte STDIO é executado localmente em sua máquina e se comunica através de fluxos de entrada/saída padrão.
Como Funciona o Transporte STDIO
- O cliente (AI Cockpit Reasoning) gera um servidor MCP como um processo filho
- A comunicação acontece através de fluxos de processo: o cliente 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 a solicitação)
|<---- mensagem JSON ------| (via STDOUT)
| |
Características do STDIO
- Localidade: Executa na mesma máquina que o AI Cockpit Reasoning
- 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: Intrinsecamente mais seguro, pois não há exposição à rede
Quando Usar o STDIO
O transporte STDIO é ideal para:
- Integrações e ferramentas locais executadas na mesma máquina
- Operações sensíveis à segurança
- Requisitos de baixa latência
- Cenários de cliente único (uma instância do AI Cockpit Reasoning por servidor)
- Ferramentas de linha de comando ou extensões de IDE
Exemplo de Implementação de STDIO
import { Server } from '@modelcontextprotocol/sdk/server/index.js';
import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js';
const server = new Server({name: 'local-server', version: '1.0.0'});
// Registrar ferramentas...
// Usar transporte STDIO
const transport = new StdioServerTransport(server);
transport.listen();
Transporte SSE
O transporte de Eventos Enviados pelo Servidor (SSE) é executado em um servidor remoto e se comunica por HTTP/HTTPS.
Como Funciona o Transporte SSE
- O cliente (AI Cockpit Reasoning) se conecta ao endpoint SSE do servidor através de uma solicitação HTTP GET
- Isso estabelece uma conexão persistente onde o servidor pode enviar eventos para o cliente
- Para a comunicação do cliente para o servidor, o cliente faz solicitações HTTP POST para um endpoint separado
- A comunicação acontece por dois canais:
- Fluxo de Eventos (GET): Atualizações do servidor para o cliente
- Endpoint de Mensagem (POST): Solicitações do cliente para o servidor
Cliente Servidor
| |
|---- HTTP GET /events ----------->| (estabelece conexão SSE)
|<---- fluxo 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 AI Cockpit Reasoning
- Escalabilidade: Pode lidar com várias conexões de clientes simultaneamente
- Protocolo: Funciona sobre HTTP padrão (não são necessários protocolos especiais)
- Persistência: Mantém uma conexão persistente para mensagens do servidor para o cliente
- Autenticação: Pode usar mecanismos de autenticação HTTP padrão
Quando Usar o SSE
O transporte SSE é melhor para:
- Acesso remoto através de redes
- Cenários com múltiplos clientes
- Serviços públicos
- Ferramentas centralizadas que muitos usuários precisam acessar
- Integração com serviços da web
Exemplo de Implementação de SSE
import { Server } from '@modelcontextprotocol/sdk/server/index.js';
import { SSEServerTransport } from '@modelcontextprotocol/sdk/server/sse.js';
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 escutando na porta 3000');
});
Local vs. Hospedado: Aspectos de Implantação
A escolha entre os transportes STDIO e SSE impacta diretamente como você implantará e gerenciará seus servidores MCP.
STDIO: Modelo de Implantação Local
Servidores STDIO são executados localmente na mesma máquina que o AI Cockpit Reasoning, o que tem várias implicações importantes:
- 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 a 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 o AI Cockpit Reasoning (ciclo de vida do processo filho)
- Dependências: Quaisquer dependências devem ser instaladas na máquina do usuário
Exemplo Prático
Uma ferramenta de busca de arquivos local usando STDIO iria:
- Rodar na máquina do usuário
- Ter acesso direto ao sistema de arquivos local
- Iniciar quando necessário pelo AI Cockpit Reasoning
- Não exigir configuração de rede
- Precisar ser instalada junto com o AI Cockpit Reasoning ou através de um gerenciador de pacotes
SSE: Modelo de Implantação Hospedado
Servidores 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: Uma única implantação atende a 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 (geralmente continuamente)
- Dependências: Gerenciadas no servidor, não nas máquinas dos usuários
Exemplo Prático
Uma ferramenta de consulta a banco de dados usando SSE iria:
- Rodar em um servidor central
- Conectar-se a bancos de dados com credenciais do lado do servidor
- Estar continuamente disponível para múltiplos usuários
- Exigir configuração adequada de segurança de rede
- Ser 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 um proxy para serviços remotos
- SSE com Comandos Locais: Um servidor SSE 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 SSE para funções especializadas
Escolhendo Entre STDIO e SSE
Consideração | STDIO | SSE |
---|---|---|
Localização | Apenas na máquina local | Local ou remoto |
Clientes | Cliente único | Múltiplos clientes |
Desempenho | Menor latência | Maior latência (sobrecarga de rede) |
Complexidade da Configuração | Mais simples | Mais complexo (requer servidor HTTP) |
Segurança | Intrinsecamente 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 |
Configurando Transportes no AI Cockpit Reasoning
Para informações detalhadas sobre a configuração de transportes STDIO e SSE no AI Cockpit Reasoning, incluindo exemplos de configurações, consulte a seção Entendendo os Tipos de Transporte no guia Usando o MCP no AI Cockpit Reasoning.