Pular para o conteúdo principal

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

  1. O cliente (AI Cockpit Reasoning) gera um servidor MCP como um processo filho
  2. A comunicação acontece através de fluxos de processo: o cliente 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 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

  1. O cliente (AI Cockpit Reasoning) se conecta ao endpoint SSE do servidor através de uma solicitação HTTP GET
  2. Isso estabelece uma conexão persistente onde o servidor pode enviar eventos para o cliente
  3. Para a comunicação do cliente para o servidor, o cliente faz solicitações HTTP POST para um endpoint separado
  4. 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:

  1. STDIO com Acesso à Rede: Um servidor STDIO local que atua como um proxy para serviços remotos
  2. SSE com Comandos Locais: Um servidor SSE 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 SSE para funções especializadas

Escolhendo Entre STDIO e SSE

ConsideraçãoSTDIOSSE
LocalizaçãoApenas na máquina localLocal ou remoto
ClientesCliente únicoMúltiplos clientes
DesempenhoMenor latênciaMaior latência (sobrecarga de rede)
Complexidade da ConfiguraçãoMais simplesMais complexo (requer servidor HTTP)
SegurançaIntrinsecamente 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

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.