MCP admite mecanismos de transporte para la comunicación entre Bob Shell y los servidores MCP.

Descripción general

MCP ofrece tres opciones de transporte, cada una adecuada para diferentes escenarios de despliegue:

Transporte STDIO (servidores locales)

Transporte HTTP con streaming (estándar moderno para servidores remotos)

Transporte SSE (opción remota heredada)

Cada transporte tiene características, ventajas y casos de uso distintos.

Transporte STDIO

El transporte STDIO se ejecuta localmente en tu máquina y se comunica a través de flujos de entrada/salida estándar.

Cómo funciona el transporte STDIO

Bob lanza un servidor MCP como proceso hijo

La comunicación ocurre a través de flujos de proceso: Bob escribe en el STDIN del servidor, el servidor responde al STDOUT

Cada mensaje está delimitado por un carácter de nueva línea

Los mensajes tienen formato JSON-RPC 2.0

Cliente                   Servidor
  |                         |
  |---- mensaje JSON ------->| (vía STDIN)
  |                         | (procesa la solicitud)
  |<---- mensaje JSON -------| (vía STDOUT)
  |                         |

Características de STDIO

Localidad: Se ejecuta en la misma máquina que Bob

Rendimiento: Latencia y sobrecarga muy bajas (sin stack de red)

Simplicidad: Comunicación directa entre procesos sin configuración de red

Relación: Relación uno a uno entre cliente y servidor

Seguridad: Inherentemente más seguro sin exposición a la red

Cuándo usar STDIO

El transporte STDIO es ideal para:

Integraciones y herramientas locales que se ejecutan en la misma máquina

Operaciones sensibles a la seguridad

Requisitos de baja latencia

Escenarios de cliente único (una instancia de Bob por servidor)

Herramientas de línea de comandos y scripts

Ejemplo de implementación STDIO

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

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

El transporte HTTP con streaming es el estándar moderno para la comunicación con servidores MCP remotos, reemplazando al antiguo transporte HTTP+SSE. Opera sobre HTTP/HTTPS y permite implementaciones de servidor más flexibles.

Cómo funciona el transporte HTTP con streaming

El servidor proporciona un único endpoint HTTP (endpoint MCP) que admite tanto métodos POST como GET

Bob envía solicitudes a este endpoint MCP usando HTTP POST

El servidor procesa la solicitud y envía una respuesta

Opcionalmente, el servidor puede usar Server-Sent Events (SSE) sobre la misma conexión para transmitir múltiples mensajes o notificaciones a Bob

Esto permite interacciones básicas de solicitud-respuesta, así como streaming avanzado y comunicación iniciada por el servidor.

Cliente                            Servidor
  |                                  |
  |---- HTTP POST /mcp_endpoint ---->| (solicitud del cliente)
  |                                  | (procesa la solicitud)
  |<--- Respuesta HTTP / SSE Stream --| (respuesta / stream del servidor)
  |                                  |

Características del HTTP con streaming

Estándar moderno: Método preferido para nuevas implementaciones de servidores MCP remotos

Acceso remoto: Puede alojarse en una máquina diferente a la de Bob

Escalabilidad: Puede manejar múltiples conexiones de clientes simultáneamente

Protocolo: Funciona sobre HTTP/HTTPS estándar

Flexibilidad: Admite solicitud-respuesta simple y streaming avanzado

Endpoint único: Usa una sola ruta URL para toda la comunicación MCP

Autenticación: Puede usar mecanismos de autenticación HTTP estándar

Compatibilidad hacia atrás: Los servidores pueden mantener compatibilidad con clientes HTTP+SSE más antiguos

Cuándo usar HTTP con streaming

El transporte HTTP con streaming es ideal para:

Todos los nuevos desarrollos de servidores MCP remotos

Servidores que requieren comunicación robusta, escalable y flexible

Integraciones que puedan involucrar streaming de datos o notificaciones enviadas por el servidor

Servicios públicos o herramientas centralizadas

Reemplazar implementaciones de transporte SSE heredadas

Ejemplo de implementación de HTTP con streaming

Configuración en ~/.bob/mcp_settings.json (global) o .bob/mcp.json (proyecto):

{
  "mcpServers": {
    "StreamableHTTPMCPName": {
      "httpURL": "http://localhost:8080/mcp"
    }
  }
}

Para la implementación del lado del servidor, consulta la documentación del SDK de MCP para StreamableHTTPClientTransport.

Compatibilidad hacia atrás con HTTP+SSE

Los clientes y servidores pueden mantener compatibilidad hacia atrás con el transporte HTTP+SSE obsoleto.

Los servidores que quieran admitir clientes más antiguos deben continuar alojando tanto los endpoints SSE (/events) como POST (/message) del transporte antiguo, junto con el nuevo endpoint MCP definido para el transporte HTTP con streaming.

Transporte SSE (legacy)

El transporte Server-Sent Events (SSE) se ejecuta en un servidor remoto y se comunica a través de HTTP/HTTPS. Para nuevos servidores remotos, usa el transporte HTTP con streaming en su lugar.

Cómo funciona el transporte SSE

Bob se conecta al endpoint SSE del servidor a través de una solicitud HTTP GET

Esto establece una conexión persistente donde el servidor puede enviar eventos a Bob

Para la comunicación del cliente al servidor, Bob realiza solicitudes HTTP POST a un endpoint separado

La comunicación ocurre a través de dos canales:

Flujo de eventos (GET): Actualizaciones del servidor al cliente
Endpoint de mensajes (POST): Solicitudes del cliente al servidor

Cliente                            Servidor
  |                                  |
  |---- HTTP GET /events ----------->| (establecer conexión SSE)
  |<---- flujo de eventos SSE --------| (conexión persistente)
  |                                  |
  |---- HTTP POST /message --------->| (solicitud del cliente)
  |<---- evento SSE con respuesta ----| (respuesta del servidor)
  |                                  |

Características de SSE

Acceso remoto: Puede alojarse en una máquina diferente a la de Bob

Escalabilidad: Puede manejar múltiples conexiones de clientes simultáneamente

Protocolo: Funciona sobre HTTP estándar (no se necesitan protocolos especiales)

Persistencia: Mantiene una conexión persistente para mensajes del servidor al cliente

Autenticación: Puede usar mecanismos de autenticación HTTP estándar

Cuándo usar SSE

El transporte SSE es adecuado para:

Acceso remoto a través de redes

Escenarios de múltiples clientes

Servicios públicos

Herramientas centralizadas a las que muchos usuarios necesitan acceder

Integración con servicios web

Ejemplo de implementación SSE

import express from 'express';

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

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

Consideraciones de despliegue

La elección entre STDIO y los transportes remotos (HTTP con streaming o SSE) afecta directamente cómo despliegas y gestionas tus servidores MCP.

STDIO: Despliegue local

Los servidores STDIO se ejecutan localmente en la misma máquina que Bob:

Instalación: El ejecutable del servidor debe instalarse en la máquina de cada usuario

Distribución: Debes proporcionar paquetes de instalación para diferentes sistemas operativos

Actualizaciones: Cada instancia debe actualizarse por separado

Recursos: Usa la CPU, memoria y disco de la máquina local

Control de acceso: Se basa en los permisos del sistema de archivos de la máquina local

Integración: Integración sencilla con recursos del sistema local (archivos, procesos)

Ejecución: Inicia y detiene con Bob (ciclo de vida del proceso hijo)

Dependencias: Cualquier dependencia debe instalarse en la máquina del usuario

Ejemplo de caso de uso:

Una herramienta de búsqueda de archivos local usando STDIO:

Se ejecutaría en tu máquina

Tendría acceso directo al sistema de archivos local

Se iniciaría cuando Bob lo necesite

No requeriría configuración de red

Necesitaría instalarse junto a Bob o a través de un gestor de paquetes

Remoto: Despliegue alojado

Los servidores remotos (HTTP con streaming o SSE) pueden desplegarse en servidores remotos y accederse a través de la red:

Instalación: Instalado una vez en un servidor, accesible por muchos usuarios

Distribución: Un solo despliegue sirve a múltiples clientes

Actualizaciones: Las actualizaciones centralizadas afectan a todos los usuarios de inmediato

Recursos: Usa recursos del servidor, no de la máquina local

Control de acceso: Gestionado a través de sistemas de autenticación y autorización

Integración: Integración más compleja con recursos específicos del usuario

Ejecución: Se ejecuta como un servicio independiente (a menudo de forma continua)

Dependencias: Gestionadas en el servidor, no en las máquinas de los usuarios

Ejemplo de caso de uso:

Una herramienta de consulta de base de datos usando transporte remoto:

Se ejecutaría en un servidor central

Se conectaría a bases de datos con credenciales del lado del servidor

Estaría disponible continuamente para múltiples usuarios

Requeriría configuración adecuada de seguridad de red

Se desplegaría usando tecnologías de contenedor o nube

Enfoques híbridos

Algunos escenarios se benefician de un enfoque híbrido:

STDIO con acceso a la red: Un servidor STDIO local que actúa como proxy para servicios remotos

Remoto con comandos locales: Un servidor remoto que puede activar operaciones en la máquina del cliente a través de callbacks

Patrón gateway: Servidores STDIO para operaciones locales que se conectan a servidores remotos para funciones especializadas

Comparación de transportes

Consideración	STDIO	HTTP con streaming / SSE
Ubicación	Solo máquina local	Local o remoto
Clientes	Cliente único	Múltiples clientes
Rendimiento	Menor latencia	Mayor latencia (sobrecarga de red)
Complejidad de configuración	Más simple	Más compleja (requiere servidor HTTP)
Seguridad	Inherentemente seguro	Requiere medidas de seguridad explícitas
Acceso a red	No necesario	Requerido
Escalabilidad	Limitada a la máquina local	Puede distribuirse a través de la red
Despliegue	Instalación por usuario	Instalación centralizada
Actualizaciones	Actualizaciones distribuidas	Actualizaciones centralizadas
Uso de recursos	Usa recursos del cliente	Usa recursos del servidor
Dependencias	Dependencias del lado del cliente	Dependencias del lado del servidor

Configurar transportes en Bob Shell

Para información detallada sobre la configuración de transportes en Bob Shell, incluidos ejemplos de configuración, consulta MCP en Bob Shell.

Transportes de servidor MCP