El cliente MCP funciona como el puente de comunicación entre tu servidor y los servidores MCP. Piénsalo como tu punto de acceso a todas las herramientas que proporciona un servidor MCP. Cuando necesitas usar funcionalidad externa, el cliente se encarga de todo el paso de mensajes y los detalles del protocolo por ti.
Comunicación agnóstica al transporte
Una de las fortalezas clave de MCP es ser agnóstico al transporte, una forma elegante de decir que el cliente y el servidor pueden comunicarse entre sí usando diferentes métodos de comunicación. La configuración más común ejecuta tanto el cliente como el servidor MCP en la misma máquina, donde se comunican a través de entrada/salida estándar.
Pero no estás limitado a ese enfoque. Los clientes y servidores MCP también pueden conectarse a través de:
- HTTP
- WebSockets
- Varios otros protocolos de red
Tipos de mensajes
Una vez conectados, el cliente y el servidor intercambian tipos de mensajes específicos definidos en la especificación de MCP. Los principales con los que trabajarás son:
ListToolsRequest/ListToolsResult: El cliente le pregunta al servidor "¿qué herramientas proporcionas?" y recibe una lista completa de la funcionalidad disponible.
CallToolRequest/CallToolResult: El cliente le dice al servidor "ejecuta esta herramienta específica con estos argumentos" y recibe los resultados de la ejecución.
Ejemplo de flujo completo
Así es como todas las piezas funcionan juntas en un escenario real. Supongamos que un usuario pregunta "¿Qué repositorios tengo?" - aquí está el flujo de comunicación completo:
El proceso comienza cuando un usuario envía su pregunta a tu servidor. Pero antes de que tu servidor pueda pedirle ayuda a Claude, necesita saber qué herramientas están disponibles.
Tu servidor le pide al cliente MCP una lista de herramientas. El cliente envía una ListToolsRequest al servidor MCP y recibe un ListToolsResult con todas las herramientas disponibles.
Ahora tu servidor tiene todo lo necesario para hacer la solicitud inicial a Claude: la pregunta del usuario más la lista de herramientas disponibles.
Claude analiza las herramientas y decide que necesita llamar a una para responder la pregunta. Responde con una solicitud de uso de herramientas.
Tu servidor reconoce que Claude quiere ejecutar una herramienta, pero tu servidor ya no ejecuta herramientas directamente - ese es el trabajo del servidor MCP. Así que le pide al cliente MCP que ejecute la herramienta con los argumentos especificados por Claude.
El cliente MCP envía una CallToolRequest al servidor MCP, que luego hace la solicitud real a GitHub para obtener los repositorios del usuario.
GitHub responde con los datos del repositorio, que el servidor MCP envuelve en un CallToolResult y envía de vuelta al cliente MCP.
El cliente MCP pasa el resultado de la herramienta de vuelta a tu servidor, que luego lo envía a Claude como parte de un mensaje de seguimiento.
Finalmente, Claude tiene toda la información que necesita y formula una respuesta como "Tus repositorios son..." que se envía de vuelta a través de tu servidor al usuario.
Sí, este flujo involucra muchos pasos, pero cada componente tiene una responsabilidad clara. El cliente MCP abstrae la complejidad de la comunicación con el servidor, permitiéndote enfocarte en construir la lógica de tu aplicación mientras sigues teniendo acceso a herramientas y servicios externos potentes.