Qué es MCP y para qué lo necesita tu ChatGPT App

1. Por qué hace falta un protocolo aparte

En este módulo por fin veremos qué es MCP (Model Context Protocol) y cómo encaja en la pila de ChatGPT App. Empecemos fijando el lugar de MCP en la arquitectura, comparándolo con «un REST típico» y repasando las entidades principales del protocolo: tools, resources y prompts.

Imagina que estás creando un servicio web normal. Siguiendo la buena costumbre, levantas un API REST: tienes /api/gifts, /api/users, /api/orders, cada uno con su formato de entrada y salida, sus códigos de error y su autorización. Es lo habitual, pero hay un matiz: a cada cliente tienes que explicarle qué y cómo has implementado. Documentación, OpenAPI, ejemplos, SDK: todo eso hace falta porque el formato del API lo has diseñado tú.

Con ChatGPT App la situación se complica. Tu cliente no es solo el frontend, sino también el propio modelo. Este necesita:

• saber qué operaciones hay disponibles;
• entender qué argumentos requiere cada operación;
• invocar esas operaciones durante el diálogo, a veces varias veces, a veces con parámetros distintos;
• interpretar la respuesta estructurada y decidir qué mostrar al usuario y qué usar solo como contexto para la siguiente réplica.

Si cada desarrollador inventa su propio formato de API, el modelo acabará en un infierno de integraciones: para cada App hará falta un cliente a medida, un montón de «envoltorio» y lógica frágil. La idea de un protocolo resuelve este problema.

MCP (Model Context Protocol) es una especificación abierta de un modo estándar en que un cliente LLM (ChatGPT, un plugin de IDE, un agente, etc.) se comunica con tu servidor de herramientas y datos. Define un lenguaje común en el que el servidor declara sus herramientas, recursos y prompts, y el cliente los invoca y recibe resultados.

De forma intuitiva, MCP es como un puerto USB‑C para el mundo de la IA: si haces una «memoria USB» (servicio, base de datos, CRM, motor de búsqueda), necesitas implementar un único conector estándar. Entonces cualquier «portátil» (ChatGPT, otro agente, una IDE) puede conectarse sin un cable personalizado.

2. Vista desde arriba: dónde está MCP en la arquitectura de ChatGPT App

Para fijar la imagen, recordemos la arquitectura ya conocida, ahora con una capa de MCP explícita.

La imagen mental actual ya la has visto: el usuario conversa con ChatGPT, dentro del diálogo se renderiza un widget (Apps SDK) y en algún lugar externo vive tu backend. Ahora añadimos MCP y lo descomponemos por capas.

He aquí un esquema simplificado:

Usuario
   ↓ (lenguaje natural)
ChatGPT (modelo + UI)
   ↓ (llamadas a herramientas vía MCP)
Cliente MCP dentro de ChatGPT
   ↓ (JSON-RPC, MCP)
Tu servidor MCP (backend)
   ↓
Tu BD / APIs externas / colas

Por «cliente MCP dentro de ChatGPT» entendemos aquí la parte interna de la plataforma que habla con tu servidor MCP mediante el protocolo: hace discovery, invoca herramientas y lee recursos.

Desde el punto de vista de Apps SDK, un ChatGPT App mínimo consta de tres componentes. Primero: el servidor MCP, que declara herramientas y entrega datos estructurados. Segundo: el bundle de UI (widget), que se renderiza dentro de ChatGPT y lee esos datos a través de window.openai. Tercero: el propio modelo, que decide cuándo invocar qué herramienta y cómo responder al usuario.

Es importante ver lo siguiente. En módulos anteriores trabajaste mucho a nivel de Apps SDK y del widget, es decir, en la parte superior del esquema. Ahora bajamos al nivel del servidor MCP: es tu «lenguaje oficial» de comunicación con ChatGPT y con cualquier otro cliente que decida usar tu App.

3. MCP frente a «un REST típico»: en qué se diferencian

En el esquema anterior fijamos dónde se sitúa MCP en la arquitectura de ChatGPT App. Ahora toca comparar con cuidado los enfoques «REST propio» y MCP, para entender por qué, en el contexto de ChatGPT Apps, el segundo gana casi siempre.

En el enfoque REST diseñas endpoints, formatos de solicitudes y respuestas como te resulte cómodo a ti. Para que el cliente trabaje contigo, tiene que conocer URLs, métodos, esquemas y códigos de error. A veces ayuda OpenAPI, a veces simplemente pones un ejemplo de petición en el README. El modelo, por sí mismo, no entiende nada de eso: necesita una capa de código que convierta «encuentra un regalo para mi madre por su 50 cumpleaños» en una petición HTTP concreta y, después, de vuelta: la respuesta JSON en datos útiles para el diálogo.

Con MCP es distinto. El propio protocolo define:

• cómo puede el cliente conocer la lista de tus herramientas;
• cómo describir argumentos y resultados mediante JSON Schema;
• cómo describir recursos y prompts;
• cómo se ve la invocación de una herramienta y su respuesta.

Gracias a esto, ChatGPT y otros clientes MCP pueden, de forma automática:

• ejecutar discovery: saber qué tools/resources/prompts tienes;
• construir el esquema interno de parámetros para cada herramienta;
• invocarlas sin lógica de cliente personalizada y rígida;
• caché de metadatos y usarlos para búsqueda y ranking de aplicaciones.

Podemos resumir la diferencia en una pequeña tabla.

Dicho de forma emocional: REST es «cada uno a lo suyo»; MCP es «un acuerdo entre todos los participantes del ecosistema sobre cómo comunicarse con el modelo y los datos».

4. Entidades principales de MCP: tools, resources, prompts

Ahora pongamos nombre a los tres protagonistas de MCP: herramientas, recursos y prompts.

Tools: acciones a las que ya estás acostumbrado

Ya te has encontrado con las tools en el Módulo 4: allí describíamos una herramienta, le dábamos un nombre, una descripción y un JSON Schema de argumentos, y luego el modelo la invocaba mediante callTool. A nivel de MCP, una herramienta es una operación de servidor con un contrato claro:

• nombre y descripción (para el modelo y para UX/discovery);
• JSON Schema para los argumentos;
• JSON Schema o una descripción de la estructura del resultado;
• metainformación adicional (por ejemplo, la vinculación a un componente de UI concreto en Apps SDK).

Un servidor MCP debe ser capaz, como mínimo, de responder a «petición de lista de herramientas» y de procesar «invocación de herramienta», devolviendo un resultado estructurado.

En nuestra aplicación didáctica del asistente de regalos ya existe, por ejemplo, la herramienta suggest_gifts, que recibe la edad, el parentesco, el presupuesto y un par de preferencias, y devuelve una lista de regalos recomendados.

Un boceto condicional en TypeScript de esa herramienta en el código del servidor MCP podría verse, por ejemplo, así (pseudocódigo/plantilla):

// Pseudocódigo; no es el API definitivo del SDK
const suggestGiftsTool = defineTool({
  name: "suggest_gifts",
  description: "Propone ideas de regalos según los parámetros del destinatario",
  inputSchema: z.object({
    age: z.number(),
    relation: z.enum(["friend", "partner", "parent"]),
    budgetUsd: z.number(),
  }),
  handler: async (input) => {
    // TODO: tu lógica de negocio
    return { items: [] };
  },
});

Las firmas reales las veremos en próximas lecciones; aquí importa la idea: una herramienta no es simplemente un endpoint REST, es un elemento del protocolo con un esquema declarado.

Recursos (resources): datos accesibles por ID/URI

Los recursos (resources) en MCP son una forma de describir los datos disponibles: archivos, directorios, registros de BD, páginas de wiki, incluso resultados de índices de búsqueda. El cliente puede:

• obtener la lista de recursos;
• leer un recurso concreto por ID/URI;
• a veces, realizar búsquedas sobre ellos.

A diferencia de las tools, que «hacen algo», los resources suelen «guardar algo». Por ejemplo, en el Gift‑App puedes representar el catálogo de productos como el recurso gift_catalog, al que el modelo acude para conocer las categorías disponibles, filtros, rangos de precios, etc.

En código puede verse conceptualmente así:

const giftCatalogResource = defineResource({
  uri: "catalog://gifts",
  description: "Catálogo de regalos disponibles para recomendación",
  read: async () => {
    // Devolvemos la estructura del catálogo
    return { categories: [], priceRanges: [] };
  },
});

Aún no entramos en el formato de los mensajes MCP, pero ten presente: los recursos son entidades direccionables a las que el servidor MCP puede referirse y que el cliente puede leer para usarlas como parte del contexto.

Prompts: indicaciones predefinidas

Los prompts en el contexto de MCP son plantillas de solicitudes o instrucciones que el servidor puede proporcionar al cliente. Por ejemplo, puedes declarar el prompt gift_followup, que describe cómo debe el modelo solicitar al usuario detalles sobre el destinatario del regalo antes de invocar la herramienta.

Un ejemplo típico propio del protocolo: el servidor proporciona el nombre del prompt, su propósito y, a veces, parámetros. El cliente puede pedir la lista de prompts, elegir el que necesite e insertarlo en la solicitud al modelo.

¿Por qué lo necesita un ChatGPT App? Primero, es una forma unificada de reutilizar prompts complejos entre clientes. Segundo, MCP hace que esos prompts sean explícitos y «bajo contrato», y no algo escondido en sitios aleatorios del código.

Capabilities: declaración de lo que soportas en general

Por último, hay un cuarto elemento: capabilities. Es simplemente una declaración: el servidor indica qué entidades soporta (tools, resources, prompts, notificaciones, etc.) y qué métodos implementa. Para el cliente es una forma de no adivinar qué se puede hacer y qué no, y adaptar con cuidado su comportamiento a las capacidades del servidor.

En la práctica, ChatGPT, al conectarse a tu servidor MCP, primero realiza un «handshake», obtiene la lista de capabilities y solo después pregunta: «Vale, muéstrame tus herramientas y recursos».

5. Cómo se integra MCP en tu App actual

Todo esto suena un poco abstracto, pero en realidad ya te has encontrado con MCP a través del Apps SDK. Creo que conviene empezar por entender cómo encaja con lo que ya has escrito usando Apps SDK. Relacionemos las entidades que acabamos de introducir con cómo está montada ahora tu plantilla de App.

Recordemos la cadena que ya implementaste en la plantilla:

1. El widget, a través de window.openai o hooks listos, invoca callTool con el nombre de la herramienta y los argumentos.
2. Apps SDK dentro de ChatGPT lo convierte en una llamada a la parte de servidor de la App.
3. El servidor ejecuta la herramienta y devuelve un ToolOutput, que incluye structuredContent, content y _meta.
4. El widget recibe el ToolOutput y dibuja el UI.

El secreto es que los pasos 2–3 se realizan como un diálogo vía MCP. Tu plantilla de Next.js contiene un endpoint (normalmente app/mcp/route.ts o similar) que es precisamente el servidor MCP. Este:

• registra tus herramientas;
• las describe mediante JSON Schema;
• implementa handlers;
• responde a ChatGPT a las solicitudes MCP list tools y call tool.

Es decir, de hecho, incluso ahora, usando la plantilla, ya trabajas con MCP, solo que «automáticamente»: gran parte de la magia del protocolo está oculta en el SDK.

El Módulo 6 es necesario para dejar de tratar MCP como «una caja negra mágica» y empezar a diseñarlo de forma consciente:

• añadir y versionar herramientas;
• usar resources y prompts, no solo tools;
• leer y entender logs de MCP;
• si hace falta, levantar servidores MCP aparte fuera de la plantilla de Next.js (por ejemplo, un servicio en Python para trabajar con un modelo de ML o un servicio separado de acceso a una base corporativa).

6. MCP desde distintas funciones: product vs. desarrollador

Es útil formular por separado qué aporta MCP a un product manager y qué a un ingeniero.

MCP para product

Desde el punto de vista de producto, MCP es una forma de convertir tu servicio en un «módulo conectable» para todo un zoo de clientes: ChatGPT, otros clientes LLM, plugins de IDE, tus propios agentes. Al describir de una vez las capacidades del servidor como un conjunto de tools/resources/prompts, permites a cualquier cliente:

• descubrir automáticamente tu servicio;
• entender qué problemas resuelve;
• invocar con seguridad las operaciones necesarias.

En el caso de ChatGPT App, además, aumenta la probabilidad de que se elija tu aplicación: el modelo utiliza metadatos sobre tus herramientas para decidir cuándo proponer tu App al usuario y cómo presentarla correctamente.

En resumen: MCP convierte tu servicio en un «ladrillo» estándar del ecosistema, y no en una integración personalizada para uno o dos clientes.

MCP para desarrollador

Desde el punto de vista del ingeniero, MCP es un contrato y un protocolo. Responde a las preguntas:

• ¿En qué formato debo declarar una herramienta?
• ¿Cómo describir argumentos y devolver el resultado?
• ¿Cómo sabrá el cliente que soporte recursos y prompts?
• ¿Qué JSON circulará por la red?

Cuando tienes un protocolo así, es más sencillo:

• escribir servidores en distintos lenguajes (hay SDK oficiales para TypeScript y Python);
• depurar la aplicación con MCP Inspector u otras herramientas similares;
• dividir la responsabilidad entre equipos: un equipo hace el servidor MCP con datos y herramientas, otro el widget en Apps SDK, un tercero puede construir sus agentes sobre ese mismo servidor MCP.

7. Una pequeña perspectiva práctica: nuestro primer servidor MCP

En esta lección evitamos a propósito entrar en detalles del formato de mensajes y la implementación del servidor: eso será materia de los siguientes temas. Pero, para que sepas adónde vamos, es útil ver la estructura general de un servidor MCP mínimo en TypeScript.

En la realidad, la biblioteca oficial de TypeScript de MCP te da primitivos para crear un servidor, registrar tools/resources/prompts y lanzar el transporte (normalmente HTTP o SSE).

Un pseudoejemplo condicional podría verse así:

// Es un ejemplo conceptual; veremos el API del SDK más adelante
import { createServer } from "@modelcontextprotocol/sdk";

const server = createServer({
  name: "gift-genius",
  version: "1.0.0",
});

// Registramos la herramienta
server.tool("suggest_gifts", {
  description: "Elige regalos según las preferencias del destinatario",
  inputSchema: {/* ... */},
  handler: async (input) => {
    // tu lógica
    return { items: [] };
  },
});

// Lanzamos el transporte (por ejemplo, HTTP)
server.listen(3001);

Un punto importante: aquí no se menciona en ninguna parte ChatGPT, Apps SDK ni tu frontend concreto. El servidor MCP es autosuficiente. Simplemente sabe responder a solicitudes MCP. ChatGPT App es solo uno de los tipos de clientes que pueden usar ese servidor.

En el curso nos mantendremos en la plantilla de Next.js, donde el servidor MCP vive como parte del proyecto, pero no es la única opción posible.

8. MCP en el ecosistema: Apps SDK, Agents SDK y ACP

Para no percibir MCP como «una función solo de Apps SDK», conviene verlo en una imagen más amplia.

En primer lugar, Apps SDK se apoya directamente en MCP como puente estándar entre ChatGPT y servicios externos. La documentación oficial subraya: Apps SDK funciona con cualquier servidor MCP. El propio protocolo permite describir herramientas, devolver datos estructurados e indicar el componente para renderizado en el UI.

En segundo lugar, Agents SDK, que verás en un módulo aparte, también sabe conectarse a servidores MCP. Esto significa que un mismo servidor MCP con lógica de negocio puede usarse:

• dentro de ChatGPT como parte de tu App;
• dentro de un agente autónomo que opere, por ejemplo, en segundo plano de tu producto o en modo batch.

En tercer lugar, ACP (Agentic Commerce Protocol), que necesitarás para compras e Instant Checkout, se construye lógicamente sobre el enfoque de MCP: el modelo y los agentes invocan herramientas de comercio que también están descritas mediante contratos estandarizados.

Así, MCP se convierte en el fundamento sobre el que ya se construyen el UI (Apps SDK), los escenarios de agentes (Agents SDK) y el comercio (ACP). Si dominas con confianza MCP, todo lo demás se vuelve más claro y predecible.

Nota: Formalmente, ACP no depende de MCP como especificación, pero en implementaciones reales es muy probable que las herramientas de ACP sean invocadas por el modelo precisamente a través de interfaces MCP. Un enfoque encaja muy bien con el otro, así que no queda mucho para verlo.

9. Pequeños ejercicios «mentales» antes de la práctica

Antes de sumergirnos en la siguiente lección en el formato de mensajes MCP, es útil hacer un par de ejercicios mentales. Ayudan a «cambiar el chip» de «un REST típico» a «protocolo + contrato».

Imagina que a tu Gift‑App quiere conectarse no solo ChatGPT, sino también un plugin de IDE para VS Code y un asistente corporativo interno en Slack. Describe en una frase qué necesitan saber todos ellos sobre tu servicio. Seguramente la respuesta será algo como: «Tenemos la herramienta suggest_gifts con tales parámetros, y un catálogo de regalos accesible mediante tal recurso». Eso es exactamente lo que MCP formaliza.

Intenta también formular en dos frases:

• qué es MCP para el product de tu App (pista: una forma estándar de “empaquetar” funcionalidad para distintos clientes);
• qué es MCP para el desarrollador (pista: un protocolo JSON‑RPC con primitivos claros de tools/resources/prompts).

Si puedes hacerlo sin dudar, ya estás a medio camino de trabajar con MCP con seguridad.

Si reducimos todo lo anterior a una tesis: MCP no es otra capa de API más, sino el contrato básico entre tu lógica y los clientes LLM. En las próximas lecciones miraremos dentro del propio protocolo: analizaremos el formato de los mensajes MCP, handshake/capabilities y aprenderemos a inspeccionar el tráfico con inspectores para que todos estos principios no sean una abstracción, sino una herramienta de trabajo.

10. Errores y malentendidos típicos en torno a MCP

Error n.º 1: considerar MCP «otra capa de API encima de mi REST».
A veces surge la tentación: «Ya tengo REST, haré un adaptador fino que convierta llamadas MCP en REST y viceversa, y me olvido». Formalmente puedes hacerlo, pero entonces a menudo empiezas a «arrastrar» peculiaridades del viejo API dentro de MCP: tipos extraños, respuestas no estructuradas, ausencia de esquemas explícitos. Con el tiempo, el adaptador crece y la ganancia de MCP se reduce. Es mejor tratar MCP como el contrato principal, y el viejo REST como un detalle interno de implementación si aún lo necesitas.

Error n.º 2: pensar que MCP «es solo para ChatGPT Apps».
MCP es un protocolo abierto y general para cualquier cliente LLM: ChatGPT, plugins de IDE, agentes autónomos. Si diseñas un servidor MCP pensando solo en una App, te limitas a futuro. Sale mucho más a cuenta pensar desde el principio: «este servidor también podrá ser usado por otros clientes», y diseñar herramientas y recursos algo más universales.

Error n.º 3: ignorar JSON Schema y describir los argumentos “de palabra”.
Incluso si el SDK te permite pasar «cualquier JSON», no te saltes describir los esquemas de argumentos y resultados. De ello dependen directamente la capacidad del modelo de invocar correctamente tu herramienta, la calidad del autocompletado y del discovery, y la comodidad de la depuración mediante inspectores. Argumentos no descritos o mal descritos conducen directamente a misteriosos errores de tool‑call.

Error n.º 4: percibir MCP como “transporte mágico” y no mirar los logs.
Mientras todo funciona, parece que MCP es algo invisible de lo que no hay que preocuparse. El problema es que, en cuanto algo falla, sin entender la estructura de MCP pasarás mucho tiempo adivinando: «¿es Apps SDK? ¿es el modelo? ¿es mi backend?». La costumbre de mirar mensajes y logs de MCP desde temprano te ahorrará horas de “magia” inútil.

Error n.º 5: intentar diseñar un flujo complejo solo con REST, ignorando los primitivos de MCP.
Cuando aparecen escenarios de varios pasos (buscar regalo → aclarar preferencias → elegir → tramitar pedido), apetece «hacer un único endpoint REST grande». En el contexto de ChatGPT Apps, esto a menudo empeora la gobernanza: el modelo entiende peor los pasos intermedios y el cliente MCP pierde la posibilidad de reutilizar recursos y prompts. Es mucho mejor dividir la funcionalidad en varias tools/resources bien descritas y enlazar la lógica con prompts del sistema y descripciones correctas.