Qué es un MCP

MCP (Model Context Protocol) es un protocolo abierto para conectar un modelo de IA (ChatGPT, Cursor, Claude…) con tus tools y tus datos, sin montar un invento distinto por cada producto.

La analogía que usa todo el mundo —y la docs oficial también— es esta: MCP es el USB-C de las apps de IA. Un puerto estándar. Menos cables raros.

En este post te cuento qué es de verdad, cómo se monta en la cabeza (host / client / server), qué son tools, resources y prompts, cómo viajan los mensajes, y sobre todo cuándo te sirve y cuándo te estás complicando. Si luego quieres código, aquí tienes la serie: cómo crear un MCP y cómo llevarlo a una app visual en ChatGPT.

El problema que resuelve

Un LLM solo, por muy bueno que sea:

no conoce tus datos privados,
no llama a tu API de forma fiable,
y no tiene un contrato claro de “esto sí lo puedes hacer / esto no”.

Antes de MCP, cada integración iba a su bola: un plugin por aquí, un function calling por allá, un wrapper por otro lado. Si usabas varios hosts y varias tools, acababas con un espagueti de conectores.

Con MCP la cosa cambia:

El host (Cursor, ChatGPT, Claude…) habla MCP.
Tu server expone lo que quieras (con nombre, descripción y schema).
El modelo decide cuándo llamar a una tool mirando ese contrato.

Tú defines las tools una vez. Y varios hosts pueden reutilizarlas. Eso es el win.

Sin MCP cada integración es distinta; con MCP defines tools una vez

Anatomía rápida: host, client y server

En la spec hay tres roles. Suena formal, pero es bastante simple (y sí, se parecen un poco a la idea del Language Server Protocol):

Rol	En cristiano	Ejemplo
Host	La app donde tú chateas / programas	Cursor, Claude Desktop, ChatGPT
Client	El conector MCP dentro del host	Quien abre la sesión con tu server
Server	Tu código (o un servicio remoto)	Un MCP contra PokéAPI, un CRM, tickets…

El flujo, en plan napkin:

Usuario → Host (Cursor / ChatGPT / Claude)
              ↓  MCP (JSON-RPC 2.0)
         Tu MCP server
              ↓  HTTP / DB / APIs
         PokéAPI, CRM, tickets, ficheros…

Cuando te pones a construir, casi siempre te importan estas piezas:

Server — el proceso que registra tools / resources / prompts y las ejecuta.
Tools — las acciones de verdad (get_pokemon, create_ticket…).
Transport — por dónde viaja el mensaje (stdio en local, Streamable HTTP en remoto).
Schemas — tipado de inputs/outputs. En mis ejemplos uso Zod, para que el modelo no dispare basura.

Arquitectura MCP: host, cliente, servidor y tools

Por debajo habla JSON-RPC 2.0. No hace falta aprendértelo de memoria el día 1. Sí conviene pillar una cosa: no es magia del modelo. Es un contrato de integración.

Si quieres la versión “oficial” (en inglés): intro y architecture.

Las 3 piezas que expone un servidor MCP

Aquí la gente a veces se lía. Un MCP no es solo “ejecutar funciones”. Hay tres tipos de cosas que puede exponer:

Primitiva	Qué es	Quién la usa más	Ejemplo
Tools	Acciones (consultar o cambiar cosas)	El modelo (con permiso)	`get_hotel_occupancy`, `create_support_ticket`
Resources	Contexto, normalmente de solo lectura	Host / usuario / modelo como contexto	un `logs.txt`, el schema de una BD, docs internas
Prompts	Plantillas de instrucciones reutilizables	Sobre todo el usuario	“Analizar incidencias del sistema”

Tools

Esto es el 90% de lo que vas a montar al principio. Cada tool lleva:

un nombre que no cambies cada dos días,
una descripción (el modelo la lee para decidir si la usa),
un schema de argumentos.

Si pones de descripción “hace cosas con hoteles”, prepárate: o no la llama, o la llama mal. Si pones “Devuelve la ocupación del hotel por hotelId y fecha ISO”, de pronto la tool sirve de verdad.

Esto lo vemos más en cómo crear un MCP. Spoiler: la descripción importa más de lo que parece.

Resources

Para meter contexto sin convertirlo en una acción. Docs, ficheros, un snapshot… cosas que el agente tiene que conocer, no “pulsar”.

Prompts

No es “el system prompt mágico del universo”. Son plantillas que el server ofrece para arrancar un flujo concreto. Útiles cuando quieres repetir el mismo ritual una y otra vez sin reescribir el mensaje.

Ojo con el naming de internet: verás mucho lo de skills. En la spec base del server las tres primitivas son tools, resources y prompts. Si hablas ese idioma, te entiendes mejor con la docs.

Cómo viajan los mensajes: stdio vs Streamable HTTP

MCP no te obliga a un cable concreto, pero en la práctica usas dos:

Transport	Cuándo	Idea rápida
stdio	Local (Cursor, Claude Desktop…)	El host lanza tu server como proceso y habla por stdin/stdout
Streamable HTTP	Remoto (ChatGPT, servers en la nube…)	HTTP POST a un endpoint; respuesta JSON o stream

Truco que funciona:

¿Lo uso yo en el IDE, en mi máquina? stdio y listo.
¿Lo quiero colgar para un host remoto o meterlo en ChatGPT? Streamable HTTP, y ya te toca pensar en auth.

Transports MCP: stdio local y Streamable HTTP remoto

Si te pica la curiosidad: spec de transports. En la serie: stdio cuando creas el MCP; el salto a UI dentro del chat en MCP → app en ChatGPT.

MCP vs API vs function calling

Hay mucha confusión con esto. Tres capas distintas:

Idea	Qué es	Cuándo te vale
API REST/GraphQL	Contrato entre sistemas	Un backend, un cron, otra app (sin LLM)
Function / tool calling	El modelo pide “ejecuta esta función”	Tools pegadas a una app
MCP	Cómo descubrir y reutilizar tools/contexto entre hosts	Quieres lo mismo en Cursor, Claude y ChatGPT

Y la frase que te ahorra discusiones: MCP no mata al function calling. El host sigue ofreciendo tools al modelo. MCP ordena dónde viven y cómo se descubren. Tú montas el server una vez; varios clientes lo enchufan.

Si tu mundo es “un script mío llama a OpenAI con dos funciones internas”, igual te basta function calling. Si tu mundo es “quiero que Cursor y ChatGPT usen las mismas tools sobre mi dominio”, ahí MCP empieza a tener sentido.

Ejemplo práctico

Imagina una app de reservas de hotel.

Le preguntas al LLM: “¿Qué ocupación tiene el hotel 42 el viernes?”

Sin acceso a tu sistema: inventa, se corta, o te suelta una respuesta genérica.
Con un MCP que expone get_hotel_occupancy({ hotelId, date }) contra tu API: el modelo puede llamar la tool, coger datos reales y responder con números reales.

El valor no es “el modelo se ha vuelto más listo”. El valor es darle un canal estándar (y tipado) hacia tus datos.

En mis tutoriales uso ejemplos más de juguete —PokéAPI y similares— para que lo puedas tocar sin montar un hotel. La idea es la misma.

¿Qué provecho sacamos como developers?

Menos pegamento por producto. Un server, varios hosts (Cursor, Claude, ChatGPT).
Contrato explícito. Nombre + descripción + schema gana a prompts eternos del estilo “si te pido X, llama a Y, porfa”.
Tú decides la superficie. El modelo no “tiene tu base de datos”. Tiene las acciones que tú publicas.
A veces ni escribes el tuyo. Hay servers listos en sitios como mcp.so. Figma y compañía ya van por ahí.

Cuándo NO necesitas un MCP

Montar MCP “porque mola” también es deuda técnica. Lo digo en serio.

Puede que no te haga falta si:

solo tienes 1 host y 2–3 tools muy pegadas a esa app,
la acción no la decide un LLM (cron, webhook, form de toda la vida),
todavía no tienes el dominio claro: primero una API estable; el MCP puede ser un wrapper fino después,
vas a dejar tools que escriben en prod sin auth / sin que el usuario confirme… mal plan.

La propia spec insiste en consentimiento, privacidad y en tratar las tools como “código que ejecuta cosas” hasta que el usuario las autorice. Merece la pena leer la sección de seguridad de la spec sin saltársela.

Errores típicos al empezar

Descripciones vagas → el modelo pasa de la tool o la usa mal.
Veinte tools de golpe → el contexto se llena de schemas y el modelo se vuelve tonto.
Meter un resource como tool → estás convirtiendo “leer docs” en una acción innecesaria.
Elegir mal el transport → HTTP remoto sin auth, o stdio cuando necesitabas algo en la nube.
Creer que tu server manda → tú expones; el usuario y el host autorizan.

Servidores MCP que ya puedes usar hoy

No siempre tienes que programar el tuyo desde cero. La comunidad (y bastantes productos) ya publican servers. Mira mcp.so y la docs del host que uses para ver cómo se enganchan.

Cuando quieras el tuyo: cómo crear un MCP.
Cuando quieras llevarlo a una app dentro del chat: de MCP a app en ChatGPT.

Preguntas frecuentes

¿MCP es lo mismo que una API?

No. La API es el contrato hacia tu sistema. MCP es el protocolo con el que una app de IA descubre y usa tools / resources / prompts. En la práctica, el server MCP casi siempre llama a tu API por detrás.

¿MCP sustituye el function calling?

No. Lo ordena. El modelo sigue eligiendo tools; tú evitas redefinirlas en cada producto.

¿Puedo usar el mismo MCP en Cursor y en ChatGPT?

Esa es la promesa. En local suele sobrar stdio. Para hosts remotos entras en Streamable HTTP y auth. El camino práctico está en los dos posts siguientes.

¿Hace falta saber JSON-RPC?

Para usar un server ya hecho, no. Para montar uno con cabeza, ayuda pillar request/response y errores. Los SDK oficiales te ahorran tiempo.

Siguiente paso

Si esto te encaja, el siguiente movimiento es ensuciarse las manos:

Cómo crear un MCP — tools, server y conexión a Cursor/Claude
Cómo crear una app visual en ChatGPT con MCP — de protocolo a UI dentro del chat

Y si quieres la definición canónica ve a la docs de Model Context Protocol.