Módulo 1: Qué es MCP y por qué existe

Qué es MCP: un USB-C para aplicaciones de IA

Siguiente →

Descripción

La lección anterior te dejó sintiendo el problema —M×N adaptadores a medida— sin ponerle nombre a la solución. Esta lección se lo pone: el Model Context Protocol (MCP). No es una librería de Anthropic para usar con Claude y nada más: es un protocolo abierto, publicado por Anthropic en noviembre de 2024, que cualquier aplicación de IA —de cualquier fabricante— puede implementar para conectarse, de forma estándar, con herramientas, datos y prompts que viven en servidores externos.

Conexión con el módulo

Esta lección nombra formalmente lo que la lección 02 dejó sin nombre. La lección 04 toma esta definición y la convierte en arquitectura concreta (host, client, server); la lección 05 la contrasta con algo que ya conocías (tool_use/tool_result) para que no la confundas con eso. Todo lo que sigue en la guía —incluido el servidor y cliente que ejecutas en la lección 07— es una implementación concreta de lo que esta lección define.

Analogía: un puerto USB-C para aplicaciones de IA

La propia documentación oficial de MCP resume la idea con una imagen que vale la pena tomarse en serio, no solo como frase bonita: "Piensa en MCP como un puerto USB-C para aplicaciones de IA. Así como USB-C ofrece una manera estandarizada de conectar tus dispositivos a distintos periféricos y accesorios, MCP ofrece una manera estandarizada de conectar modelos de IA a distintas fuentes de datos y herramientas." (modelcontextprotocol.io/introduction).

Fíjate en lo que la analogía captura de verdad, no solo en la superficie:

  • Antes de USB-C, cada fabricante de laptop tenía su propio conector de carga, cada periférico (mouse, disco externo, monitor) su propio cable — el problema M×N de la lección 02, pero en hardware. Comprar un periférico nuevo no garantizaba que sirviera con tu laptop.
  • Con USB-C, un solo tipo de puerto sirve para cargar, para conectar un monitor, para transferir archivos. El fabricante del periférico diseña una vez contra el estándar; el fabricante de la laptop instala un puerto, no uno por cada tipo de periférico que exista.
  • MCP hace lo mismo, pero con software: un sistema como Reservo construye un servidor MCP que expone sus tools, resources y prompts según el estándar; una aplicación de IA como Claude Code implementa un cliente MCP que sabe hablar ese estándar. Ninguno de los dos necesita saber nada específico del otro de antemano — el protocolo es el "conector" que los hace compatibles.

La analogía tiene un límite, y vale nombrarlo: USB-C es un estándar de hardware físico (voltajes, pines, señales eléctricas); MCP es un estándar de mensajes (JSON-RPC 2.0 sobre stdio o HTTP). Pero el papel que cumplen —convertir "cada combinación necesita su propio adaptador" en "todos hablan el mismo idioma"— es idéntico, y es exactamente lo que la propia documentación de MCP eligió para presentarse.

Qué es MCP, con precisión

Con la analogía puesta, aquí va la definición formal, pieza por pieza:

MCP (Model Context Protocol)
├── QUÉ ES:     un protocolo ABIERTO — una especificación de mensajes,
│               no una librería cerrada ni un producto de un solo vendor.
├── QUIÉN LO PUBLICÓ:  Anthropic.
├── CUÁNDO:     noviembre de 2024.
├── QUÉ ESTANDARIZA:  cómo una aplicación de IA (el "host") se conecta a
│               fuentes de datos, herramientas y prompts, a través de
│               SERVIDORES reutilizables.
└── QUÉ NO ES:  no es el modelo, no es la Messages API de Claude, no es
                un producto exclusivo de Anthropic — es la CAPA DE CABLEADO
                entre una aplicación de IA y los sistemas externos que usa.

El punto que más se presta a confusión —y que vale remarcar ya, antes de que se te pegue una idea equivocada— es el de "quién puede usarlo". MCP no es una API privada que solo funciona con modelos de Anthropic. Es un protocolo abierto: cualquier aplicación de IA, sea o no de Anthropic, puede implementar un client MCP; cualquier sistema, tenga o no relación con Anthropic, puede implementar un server MCP. Que Anthropic lo haya publicado no lo vuelve propietario — lo vuelve, si el estándar se adopta ampliamente, más parecido a HTTP o a USB-C que a un SDK cerrado: una capa de compatibilidad de la que se benefician todos los que la adoptan, no un jardín cerrado de un solo fabricante.

Lo que MCP estandariza, en un vistazo

MCP define, con precisión de mensaje, tres cosas que hasta ahora vimos solo como problema:

  1. Cómo un servidor anuncia sus capacidades. Un servidor le dice a quien se conecta qué puede ofrecer: tools, resources, prompts, o alguna combinación. Lo ves ejecutado en la lección 07: capabilities: {"tools": {}} es, literalmente, un servidor diciendo "yo ofrezco tools, y nada más".
  2. Cómo un cliente descubre lo que hay disponible. Métodos como tools/list no son una convención informal entre Reservo y quien la use — son parte del protocolo mismo, con una forma exacta que cualquier cliente MCP sabe interpretar sin necesitar documentación específica de Reservo.
  3. Cómo se invoca y se lee el resultado. tools/call (que profundiza el Módulo 3), resources/read (Módulo 4), prompts/get (Módulo 5) — cada uno con una forma de respuesta fija, así el cliente no necesita saber nada de la implementación interna del servidor para usarlo.

Lo que MCP no estandariza —y esto importa tanto como lo que sí— es qué modelo de IA usa el host, ni cómo ese modelo decide qué tool llamar. Eso sigue siendo terreno de cada aplicación de IA y del protocolo propio de su modelo (para Claude, la Messages API con tool_use/tool_result, que ya conoces de agent-fundamentals). La lección 05 traza esa frontera con todo detalle.

El servidor MCP de Reservo, en estos términos

Con esta definición ya puedes ubicar el proyecto de la guía con precisión: reservo-mcp-server es un servidor que implementa el protocolo MCP para exponer las herramientas, políticas y plantillas de Reservo. No sabe —ni necesita saber— si quien se conecta es Claude Code, un script propio en Python, o cualquier otra aplicación que implemente un cliente MCP. Esa es exactamente la ganancia frente al patrón de agent-fundamentals: ahí, reservo_tools solo servía al agente que lo importaba directamente. Un servidor MCP de Reservo sirve a cualquier cliente compatible, sin que Reservo tenga que saber de antemano quién se va a conectar.

Errores comunes

  1. "MCP es una librería de Anthropic para hacer tool calling con Claude." No. MCP es un protocolo abierto; el hecho de que Anthropic lo haya publicado no lo hace exclusivo de sus productos. Cualquier aplicación de IA puede implementar un client, y cualquier sistema puede implementar un server, sin depender de Anthropic para nada de eso.

  2. "MCP es el modelo, o hace que el modelo sea más inteligente." No. MCP es la capa de cableado — resuelve cómo un agente consigue acceso a herramientas y datos externos. La inteligencia (qué tool llamar, con qué argumentos) sigue siendo del modelo, y ese proceso de decisión vive en otro protocolo (la lección 05 lo distingue).

  3. "USB-C es la analogía perfecta, sin matices." La analogía es útil pero no exacta: USB-C estandariza hardware físico; MCP estandariza mensajes JSON-RPC. Tenlo presente para no forzar el paralelo más allá de lo que sirve — que es explicar por qué un estándar común reemplaza a los adaptadores a medida.

  4. "MCP reemplaza a la API que ya usa mi aplicación." No necesariamente. MCP es una pieza más, no un reemplazo total: tu aplicación puede seguir llamando directamente a una API cuando le convenga, y usar MCP específicamente para las conexiones que se benefician de un protocolo compartido y reutilizable (como cuando varios hosts distintos quieren la misma herramienta).

  5. "Si mi sistema no lo publica Anthropic, no puede ser un servidor MCP de verdad." No. Cualquiera puede construir e implementar un servidor MCP — Reservo, en esta guía, es un ejemplo educativo, no un producto de Anthropic. El protocolo es abierto precisamente para eso: para que cualquier sistema, de cualquier organización, pueda exponerse de forma estándar.

Ejercicios

Ejercicio 1: Verdadero o falso (Fácil)

Decide si cada afirmación es verdadera o falsa, y por qué: (a) MCP es exclusivo de aplicaciones construidas por Anthropic; (b) MCP fue publicado en noviembre de 2024; (c) MCP estandariza cómo el modelo decide qué herramienta llamar; (d) un sistema que no tiene relación con Anthropic puede construir un servidor MCP.

Ver solución

(a) Falso. MCP es un protocolo abierto; cualquier aplicación de IA, sea o no de Anthropic, puede implementar un cliente que lo hable.

(b) Verdadero. Anthropic publicó MCP en noviembre de 2024.

(c) Falso. Esa decisión (qué tool llamar) es del modelo, dentro del protocolo tool_use/tool_result de la Messages API (u otro equivalente de cada vendor de modelos) — no de MCP. MCP estandariza cómo el agente consigue las herramientas para ofrecérselas al modelo, no cómo el modelo elige entre ellas.

(d) Verdadero. Cualquier sistema puede implementar un servidor MCP; ser un protocolo abierto significa exactamente eso — Reservo, en esta guía, es un caso educativo que no tiene ninguna relación con Anthropic.

Ejercicio 2: Completa la analogía (Medio)

En la analogía del USB-C: ¿qué papel juega Reservo (el servidor MCP), qué papel juega Claude Code (el host), y qué sería, en términos de hardware, el equivalente al "protocolo" mismo (ni el dispositivo ni el periférico, sino la regla que los hace compatibles)?

Ver solución

Reservo (el servidor) juega el papel del periférico: el disco externo, el monitor, el mouse — algo que ofrece una función (guardar archivos, mostrar imagen, mover el cursor) y que fue diseñado contra el estándar, sin saber de antemano a qué laptop específica se va a conectar.

Claude Code (el host) juega el papel de la laptop: la aplicación que tiene el puerto y que, al conectar el periférico, obtiene acceso a su función sin necesitar un driver especial escrito a mano para ese periférico en particular.

El equivalente al protocolo mismo no es ni la laptop ni el periférico: es la especificación del puerto USB-C — los voltajes, los pines, el orden de las señales — que ambos fabricantes (el de la laptop y el del periférico) acuerdan respetar sin haberse coordinado directamente entre sí. En MCP, ese papel lo juega la especificación (modelcontextprotocol.io/specification/2025-06-18): la forma exacta de los mensajes JSON-RPC que tanto Reservo como Claude Code aceptan implementar, sin que ninguno de los dos haya tenido que hablar con el otro para ponerse de acuerdo.

Ejercicio 3: Defiende o refuta (Difícil)

Un colega argumenta: "Si MCP es un protocolo abierto y no depende de Anthropic, entonces no importa qué modelo de IA use mi aplicación — con implementar un cliente MCP, cualquier modelo automáticamente sabrá usar las herramientas de cualquier servidor." ¿Es correcto? Justifica usando la distinción entre lo que MCP estandariza y lo que no.

Ver solución

Es parcialmente correcto, con una confusión importante. Es cierto que, al ser un protocolo abierto, cualquier aplicación de IA —independientemente del modelo que use por debajo— puede implementar un cliente MCP y conectarse a cualquier servidor MCP; eso es exactamente lo que hace que MCP resuelva el problema M×N sin importar el vendor.

Pero la afirmación se equivoca en el paso siguiente: implementar un cliente MCP no hace que "el modelo automáticamente sepa usar las herramientas". El cliente MCP se encarga de descubrir las herramientas (tools/list) y de ejecutarlas cuando se le pide (tools/call) — pero decidir cuál usar y con qué argumentos sigue siendo responsabilidad del modelo, a través de SU PROPIO protocolo de tool calling (para Claude, tool_use/tool_result; otros modelos podrían tener el suyo). MCP le entrega al agente el inputSchema de cada tool descubierta, y es tarea del agente traducir ese inputSchema de MCP a la forma que su modelo espera (por ejemplo, el input_schema de la Messages API) para que el modelo pueda decidir.

En otras palabras: MCP resuelve "cómo llegan las herramientas hasta el agente", de forma independiente del modelo. Pero "cómo el modelo decide usarlas" sigue siendo un protocolo aparte, específico de cada vendor de modelos — la frontera exacta que traza la lección 05.

Resumen y siguiente paso

  • MCP (Model Context Protocol) es un protocolo abierto, publicado por Anthropic en noviembre de 2024, que estandariza cómo una aplicación de IA se conecta a herramientas, datos y prompts a través de servidores reutilizables.
  • La analogía oficial: MCP es a las aplicaciones de IA lo que USB-C es a los dispositivos electrónicos — un conector común que reemplaza los adaptadores a medida de la lección 02.
  • MCP no es exclusivo de Anthropic ni de Claude: cualquier aplicación de IA puede implementar un cliente, y cualquier sistema puede implementar un servidor, sin que Anthropic esté en el medio.
  • MCP estandariza cómo se descubren y se invocan herramientas, resources y prompts — no estandariza cómo el modelo decide cuál usar. Esa decisión es un protocolo distinto (la Messages API para Claude), que la lección 05 contrasta en detalle.
  • El servidor MCP de Reservo que construye esta guía es exactamente eso: un servidor que expone las tools, resources y prompts de Reservo, sin necesitar saber de antemano qué cliente se va a conectar.

Siguiente lección: 04 — La arquitectura host, client, server. Ya sabes qué es MCP; ahora vemos cómo se organiza en la práctica: los tres roles que aparecen en cada conexión, y por qué un host crea un client distinto por cada server con el que habla.

Recursos adicionales

  1. Model Context Protocol — Introduction — La fuente de la analogía del USB-C y la descripción oficial de MCP que desarrolla esta lección.
  2. Model Context Protocol — Specification 2025-06-18 — La especificación exacta que define, mensaje por mensaje, lo que MCP estandariza.
  3. Anthropic — Model Context Protocol (anuncio) — El anuncio original de Anthropic sobre la publicación de MCP, noviembre de 2024.
  4. Anthropic — Tool use (function calling) overview — El protocolo que sigue siendo responsabilidad de cada vendor de modelos (no de MCP), y que la lección 05 contrasta.
← AnteriorEl problema de integración M×NSiguiente →La arquitectura host, client, server