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/settings/mcp.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

El cliente MCP de Bob no recurre al transporte HTTP+SSE como fallback. La siguiente guía es para autores de servidores que desean que su servidor HTTP Streamable siga siendo accesible para clientes más antiguos que aún no admiten HTTP Streamable.

Los servidores que necesiten 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 Streamable.

Transporte SSE (eliminado)

El cliente MCP de Bob ya no admite el transporte independiente HTTP+SSE (especificación MCP 2024-11-05). Los servidores que utilicen únicamente el transporte HTTP+SSE no pueden conectarse a Bob.

Nota:

SSE como canal de respuesta dentro de una conexión HTTP Streamable sigue siendo compatible. Bob puede recibir transmisiones SSE desde un servidor HTTP Streamable. Solo se ha eliminado el transporte independiente HTTP+SSE (con endpoints /events y /message separados).

Migrar desde el transporte SSE

Si tienes un servidor existente que utiliza el transporte HTTP+SSE, mígralo al transporte HTTP Streamable o al transporte STDIO:

HTTP Streamable: Expón un único endpoint MCP que acepte solicitudes HTTP POST. Esta es la ruta recomendada para servidores remotos. Consulta Transporte HTTP Streamable.

STDIO: Si el servidor se ejecuta localmente en la misma máquina que Bob, conviértelo a un servidor STDIO. Consulta Transporte STDIO.

Consideraciones de despliegue

La elección entre el transporte STDIO y el transporte HTTP Streamable 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 Streamable) 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 Streamable
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