Servidores Ecosistema
En esta página
Básico Lección 2 de 17 ≈ 25 min de lectura
Especificación 2026-07-28
Arquitectura
Especificación MCP 2026-07-28 · revisada el 2 de octubre de 2026
Host, cliente y servidor MCP: quién envía cada mensaje JSON-RPC, por qué transporte viaja y dónde están los límites de confianza entre las tres piezas.
Qué aprenderás
- Asignar a host, cliente y servidor la responsabilidad que le corresponde a cada uno en un despliegue real
- Leer un mensaje JSON-RPC 2.0 de MCP y decir si es petición, respuesta o notificación y quién puede enviarlo
- Elegir entre stdio y Streamable HTTP para un servidor concreto y justificar la elección
- Situar los límites de confianza de una integración y decidir qué se valida a cada lado
Contenido de la lección
- 01 El problema
- 02 Tres papeles: host, cliente y servidor
- 03 El modelo nunca habla con el servidor
- 04 JSON-RPC 2.0: tres tipos de mensaje
- 05 Dos transportes: stdio y Streamable HTTP
- 06 Límites de confianza
- 07 En producción
Además: quiz de comprobación y desafío práctico.
Extracto
El equipo de plataforma de Nortia quiere que la consola de soporte incorpore un asistente capaz de consultar pedidos, buscar facturas y leer tickets. Antes de aprobarlo, seguridad hace cuatro preguntas: ¿el modelo se conecta a la base de datos de pedidos? ¿Quién guarda las credenciales de facturación? Si el servidor de tickets devuelve un texto malicioso, ¿puede acabar emitiéndose un abono? ¿Dónde queda registrado quién pidió qué?
Ninguna se contesta hablando de «la IA» en bloque. Se contestan sabiendo qué piezas hay, qué mensajes cruzan entre ellas y en qué dirección. MCP define tres papeles, un formato de mensaje y dos transportes. Esta lección los recorre en ese orden y termina en los límites de confianza, que son la respuesta a seguridad.
Fin del extracto · la lección sigue con 6 secciones más
Artículos relacionados
Preguntas frecuentes
¿Qué diferencia hay entre host, cliente y servidor en MCP?
El host es la aplicación con la que trabaja la persona y que integra el modelo, por ejemplo un editor de código o una consola de soporte; el cliente es la pieza dentro del host que mantiene la comunicación MCP con un único servidor; y el servidor es el programa que da acceso a un sistema concreto mediante tools, resources y prompts. Cliente y servidor van por parejas: si el host trabaja con tres servidores, crea tres clientes, cada uno con su credencial. Las credenciales del sistema las guarda el servidor, que además decide por su cuenta quién puede hacer qué.
¿Cuándo usar stdio y cuándo Streamable HTTP en un servidor MCP?
stdio es para servidores locales: el cliente arranca el servidor como subproceso, le escribe por stdin y lee por stdout un mensaje por línea, y solo atiende al usuario que lo lanzó. Streamable HTTP es para servidores remotos y compartidos: un único endpoint que recibe un POST por cada mensaje del cliente y, si hay autorización, un token OAuth de cada persona en cada petición. Si el servidor necesita ficheros o herramientas del equipo del usuario, encaja stdio; si lo van a usar muchas personas o varias aplicaciones y quieres que una corrección llegue a todo el mundo desplegando una sola vez, Streamable HTTP.
¿Puede un servidor MCP enviar peticiones al cliente?
No en la versión 2026-07-28: solo el cliente inicia peticiones, y el servidor se limita a responderlas y a enviar notificaciones asociadas a una petición que sigue abierta, como el avance de una operación. Si a mitad de una operación le falta un dato del usuario, responde a la petición que sigue abierta explicando en el resultado qué le falta, y el cliente la vuelve a enviar con ese dato. Gracias a eso cualquier réplica del servidor puede atender cualquier petición; en versiones anteriores el servidor sí podía enviar peticiones propias al cliente.