Cómo funciona MCP paso a paso: sesión e Introducing MCP

En noviembre de 2024 Anthropic publicó Introducing the Model Context Protocol. El anuncio no vendía un producto: proponía un estándar abierto para que cualquier modelo se conecte a archivos, bases de datos o APIs sin una integración a medida por cada par cliente–herramienta.

Si llegaste acá buscando “Introducing MCP”, esto es lo que importa del anuncio cuando ya pasaste la definición: el protocolo existe para que un cliente descubra capacidades al vuelo. No hace falta actualizar el cliente cada vez que alguien publica un servidor nuevo. El resto de esta guía es cómo se ve eso, paso a paso. El mapa conceptual está en qué es MCP.

Una sesión MCP es la conversación viva entre un cliente y un servidor mientras están conectados. No es un chat con el usuario: es el canal del protocolo. Mientras la sesión está abierta, el cliente puede listar tools, invocar una, leer un resource o pedir un prompt plantilla.

La sesión tiene tres momentos claros:

1. Initialize: el cliente dice qué versión del protocolo habla y qué capabilities ofrece. El servidor responde con las suyas.
2. Initialized: el cliente confirma. A partir de ahí la sesión está lista para pedidos reales.
3. Uso y cierre: se listan e invocan primitives. La sesión termina cuando se cierra el proceso (stdio) o la conexión HTTP.

Si el initialize falla (versión incompatible, servidor que no arranca, permisos), no hay sesión. Todo lo que ves después —tools que “no aparecen”, timeouts, un cliente que “no ve” el servidor— casi siempre se diagnostica acá.

La pregunta “mcp can / qué puede hacer MCP” se responde con tres primitives. Un servidor no tiene que exponer las tres:

MCP no reemplaza a function calling ni a RAG: es el cable con el que el cliente descubre y usa esas capacidades. La comparativa está en MCP vs function calling vs RAG.

1. Elige un cliente MCP. Claude Desktop, Cursor, Cline o un agente propio que hable el protocolo. Sin cliente no hay quién abra la sesión.
2. Elige un servidor. Uno local (lee archivos de tu máquina) o uno remoto (GitHub, Slack, una API). En stdio el cliente lanza el proceso; en HTTP se conecta a una URL.
3. Configura la conexión. En Claude Desktop es un bloque en claude_desktop_config.json (comando + args, o URL). En Cursor, la pantalla de MCP servers. El detalle cambia; la idea no: el cliente tiene que saber cómo arrancar o a dónde hablar.
4. Abre la sesión. El cliente envía initialize, recibe capabilities y manda notifications/initialized. Si ves el servidor “conectado” o “ready”, esa ronda ya ocurrió.
5. Descubre qué puede hacer. El cliente pide la lista de tools, resources y prompts. Eso es lo que el modelo “ve” cuando le pides algo.
6. Invoca un tool o lee un resource. Un pedido real: “lista mis issues abiertos”, “lee este archivo”. Si esto falla y el initialize no, el problema está en permisos, argumentos o el propio servidor — no en la sesión.

El usuario ve un asistente que “puede” leer un repo o crear una tarea. Por debajo, el cliente está traduciendo eso a mensajes MCP. Tres matices que evitan expectativas rotas:

• El modelo no “es” MCP. El modelo decide qué tool pedir; el cliente habla el protocolo; el servidor ejecuta. Si el modelo alucina un tool que no existe, la sesión está bien — el inventario no.
• Una sesión ≠ una conversación eterna. Reiniciar el cliente o el servidor abre otra sesión. El estado (archivos abiertos, auth) vive en el servidor o en tu disco, no en el protocolo.
• Local no significa invisible. Un servidor stdio corre en tu máquina, pero si el tool llama a una API externa, esos datos salen. El protocolo no es un firewall.

• El servidor no arranca. Path mal puesto, Node/Python que el cliente no encuentra, o un comando que funciona en tu terminal y no en el proceso que lanza Claude o Cursor.
• Initialize incompatible. Cliente y servidor no acuerdan versión del protocolo. Actualiza el SDK del servidor o el cliente.
• La sesión abre y no hay tools. El servidor está conectado pero no expone primitives, o el cliente no las pidió. Revisa los logs del servidor, no solo el semáforo verde del cliente.
• Funciona en un cliente y no en otro. Misma config, distinto transporte o distinto soporte de capabilities. MCP es estándar; las implementaciones no son idénticas.

Introducing MCP prometió un USB-C para la IA. En la práctica eso es una sesión: initialize, descubrir primitives, invocar. Si entiendes esos tres momentos, el resto (JSON de config, logs, un segundo servidor) es mecánica.

Si quieres ver un gestor de proyectos que combina function calling adentro, RAG local para contexto y un servidor MCP hacia afuera, prueba Hito. Sin cuenta y con tu propia API key.