Qué es un MCP (Model Context Protocol) y para qué sirve

Qué es un MCP (Model Context Protocol)
Ilustración: Digital Brain

Un MCP es la forma de conectar Claude a tus herramientas sin pelearte con una API ni contratar a nadie. Con una URL o un clic, Claude queda enchufado a tu newsletter, tu ERP o tu hoja de cálculo, y puede leer y usar esos datos por ti.

Suena técnico, pero el concepto es simple y lo vivo cada día. Aquí te lo explico como se lo contaría a un founder que no ha programado en su vida, con el primer MCP que nos cambió el juego en Digital Brain.

Qué es un MCP

MCP son las siglas de Model Context Protocol. En cristiano: una conexión estándar entre dos programas, en este caso entre Claude y cualquier herramienta que uses.

Antes, para conectar dos programas había que hacerlo vía API. Y la palabra API era la señal para salir corriendo. O no sabías hacerlo y era imposible, o tenías que contratar a un equipo de desarrolladores que te cobraba un dineral.

El MCP resuelve justo eso. Muchas herramientas ya traen conexión nativa con Claude, así que es un clic. Otras se conectan con una URL. Y ya lo tienes hablando con tus datos.

Cómo funciona

La gracia no es solo que Claude se conecte a una herramienta. Es que puedes triangular.

Coges la información de una herramienta (pongamos tu plataforma de newsletter), Claude la analiza, y de ahí la mandas a otro sitio: una Google Sheet, un Excel, un correo. Todo dentro de la misma conversación, sin exportar nada a mano.

Cada herramienta conectada le da a Claude una capacidad nueva. Con tu ERP puede mirar el stock. Con tu newsletter puede mirar las métricas. Con tu correo puede escribirte. Y las combina.

Qué es un MCP server (y cómo se crea)

Cuando dices que una herramienta "tiene MCP", por detrás hay lo que se llama un MCP server. Es la pieza que expone esa herramienta a Claude y le dice qué puede hacer con ella: leer datos, escribir, lanzar una acción.

La buena noticia es que muchos ya vienen hechos. Beehiiv, Google Drive, tu base de datos, un montón de servicios habituales ya traen el suyo. Ahí no tocas nada de código: los conectas y listo.

¿Y si tienes un programa a medida, algo interno de tu empresa? Entonces un desarrollador monta un MCP server para conectarlo, y ahí sí hay algo de programación de por medio. Pero es un trabajo que se hace una vez. Una vez montado, cualquiera del equipo lo usa desde Claude sin saber qué hay debajo.

Esa es la diferencia con la API de toda la vida: antes cada conexión era un proyecto. Con MCP, el estándar es el mismo para todo, así que lo que montas una vez sirve para siempre.

Cómo lo uso yo: los MCP que tengo conectados

El primero que nos cambió el juego fue el de Beehiiv, la plataforma de la newsletter.

Antes teníamos que entrar a mano a mirarlo y exportarlo todo: los posts, el open rate, el CTR, cuánta gente entraba, cuánta se iba, con qué newsletter se suscribían, con cuál se daban de baja, cuántas se compartían. Un rato cada día picando datos. Hoy todo eso lo tenemos en un dashboard matutino, bonito y útil, que se monta solo. Abro y lo veo.

Además del de Beehiiv, tengo conectados los de Gmail, Google Sheets y Canva, entre otros. Cada uno le da a Claude una capacidad: leer y redactar correos, escribir en una hoja, tocar diseños.

Y aquí entra la triangulación, que es donde está el valor de verdad. Un ejemplo real: cojo del Beehiiv los clics del enlace de un sponsor, Claude los cruza con la hoja del Sponsor Tracker y de ahí sale el correo de reporte al sponsor con sus números. Antes eso era mirar, copiar, pegar y redactar a mano. Ahora es una conversación. Solo en las métricas de la newsletter calculo un ahorro de unos 30 minutos al día, o más.

Te seré honesto: yo tiro bastante de conexión directa por API además de MCP, porque me da más control. Pero para empezar, el MCP es el camino sin fricción, y para la mayoría es más que suficiente.

Permisos y seguridad: ¿puede un MCP romper algo?

Es la pregunta lógica cuando dejas a Claude tocar tus datos reales. La respuesta corta: los MCP oficiales, los que hace la propia empresa de la herramienta, vienen bien capados para que no puedas cargarte nada.

Además puedes configurar el alcance desde la parte de personalización, y es sencillo. Con el del correo, por ejemplo, decides si solo puede leer, si puede redactar, si deja el correo en borrador o no. Tú marcas hasta dónde llega.

¿Dónde está el riesgo real entonces? Cuando te sales del MCP y te pones a tocar código con la API de un programa que no conoces. Ahí sí lo puedes petar. El MCP oficial es la vía segura.

¿Se equivoca un MCP?

Un MCP no se equivoca, porque no es más que una conexión. El que se equivoca eres tú, pidiéndole a Claude que haga algo a través de esa conexión que no le has explicado bien.

Para eso tienes dos redes. Una, el human in the loop: dejas los pasos importantes en borrador y revisas antes de que salga. Otra, el modo planificación de Claude Code, donde piensas bien qué va a hacer antes de que lo haga. Y cuando montas algo nuevo, lo ejecutas en directo la primera vez, ves dónde falla y corriges. Después ya lo dejas en rutina.

MCP y los automatizadores (Make, n8n, Zapier)

Aquí va mi opinión, que igual no gusta a todos.

Los automatizadores tipo Make, n8n o Zapier fueron el paso siguiente a la API. Te dejaban conectar programas sin escribir código, arrastrando cajitas. Un avance enorme en su momento.

Pero para muchos de los flujos que antes montaba ahí, hoy con un MCP y Claude ni los necesito. Coger datos de una herramienta, analizarlos y actuar en base a ellos es exactamente lo que un MCP resuelve, y de forma más directa.

No digo que los automatizadores hayan muerto para todo. Siguen teniendo su sitio en procesos que corren solos sin que nadie los pida. Pero cada vez que me sentaba a montar un flujo para "leer esto y mandar aquello", ahora me pregunto si no lo resuelve ya un MCP en dos frases.

Por dónde empezar

Si hoy vives de exports manuales, el primer MCP que yo conectaría es el del correo.

¿Por qué el correo y no tu herramienta estrella? Porque el correo es donde pasa todo, y conectarlo te deja empezar a construir una memoria de lo que ocurre en tu negocio, que Claude esté al día de todo. Con eso montado, la segunda conexión es la herramienta que más uses, que es donde vas a sacar el valor directo.

Empieza por ahí. Ese primer dashboard que aparece solo, o ese correo que se redacta con datos de verdad, es el que te hace clic. Igual que me pasó a mí con Beehiiv.

Cada día te cuento lo que se mueve en IA en la newsletter de Digital Brain, con una formación a fondo los miércoles: digitalbrain.email.


Relacionado