Llevo 4 meses con 6 agentes de IA funcionando en mi negocio. Publican en el blog, gestionan la newsletter, analizan métricas de SEO, despliegan en Vercel, hacen commit en GitHub. Todo en automático. Y la pregunta que más me hacen cuando cuento esto es siempre la misma: ¿cómo conectas un agente de IA con herramientas reales?
La respuesta corta: MCP. Model Context Protocol. Es el protocolo que lo hace posible, y probablemente la pieza más infravalorada del stack de agentes de IA en 2026.
Este post va de qué es MCP, cómo funciona, y cómo lo uso en mi día a día con ejemplos concretos. Sin teoría abstracta — con configuración real.
Qué es MCP (Model Context Protocol) y por qué debería importarte
- MCP (Model Context Protocol)
- Protocolo abierto creado por Anthropic que estandariza cómo los agentes de IA se conectan con herramientas externas, bases de datos y APIs. Funciona con una arquitectura cliente-servidor donde el agente (cliente MCP) solicita acciones a servidores MCP que traducen esas peticiones en operaciones reales sobre servicios como GitHub, Slack, bases de datos o sistemas de archivos.
MCP es un protocolo abierto creado por Anthropic que estandariza cómo un agente de IA se comunica con herramientas externas. Bases de datos, APIs, servicios web, sistemas de archivos — todo lo que un agente necesita para pasar de "hablar" a "hacer".
La analogía que mejor lo explica es el USB. Antes del USB, cada dispositivo tenía su propio conector. Un ratón usaba PS/2, una impresora usaba puerto paralelo, una cámara usaba FireWire. Un desastre. USB estandarizó la conexión: un puerto, cualquier dispositivo. MCP hace lo mismo pero para agentes de IA: un protocolo, cualquier herramienta.
Antes de MCP, si querías que Claude Code interactuara con GitHub, tenías que escribir una integración personalizada. Si luego querías añadir Slack, otra integración distinta. Y Google Drive, otra más. Cada conexión era artesanal, frágil y difícil de mantener. Según datos de Anthropic, más de 10.000 MCP servers comunitarios se crearon en los primeros 6 meses tras el lanzamiento del protocolo. Eso da una idea de la demanda que había de estandarizar estas conexiones.
Con MCP, cualquier servicio puede crear un "servidor MCP" — un adaptador estándar — y cualquier agente compatible puede conectarse a él sin escribir una sola línea de código de integración. Tú como emprendedor solo configuras qué servidores quieres usar, y el agente se conecta.
Cómo funciona MCP: la arquitectura en 3 piezas
MCP usa una arquitectura cliente-servidor que es elegante en su simplicidad. Tiene tres componentes que trabajan juntos.
El host es la aplicación donde vive el agente — en mi caso, Claude Code corriendo en terminal. El host gestiona la conversación, el contexto y las herramientas disponibles. Es el cerebro de la operación.
El cliente MCP es la capa que vive dentro del host y se encarga de hablar con los servidores. Cada cliente mantiene una conexión 1:1 con un servidor específico. Si tu agente usa 5 herramientas, tiene 5 clientes MCP corriendo en paralelo. El cliente traduce lo que el agente quiere hacer al lenguaje que el servidor entiende.
El servidor MCP es la pieza que conecta con el servicio real — GitHub, una base de datos, un sistema de archivos, Google Search Console. El servidor expone tres tipos de capacidades: herramientas (acciones que el agente puede ejecutar), recursos (datos que el agente puede leer) y prompts (plantillas de instrucciones predefinidas). Lo bueno es que cada servidor es independiente: puedes añadir o quitar servidores sin tocar nada más del sistema.
Esta separación es lo que hace que MCP escale tan bien. Cada servidor es una pieza modular. Si mañana necesito conectar un agente a Notion, no reescribo nada — instalo el servidor MCP de Notion, lo configuro, y mi agente ya tiene acceso. Según Google Cloud, la inversión global en IA alcanza los 185.000 millones de dólares en 2026, y protocolos como MCP son parte fundamental de esa infraestructura.
Los servidores MCP que uso en mi stack real
Aquí es donde la teoría se vuelve práctica. Estos son los MCP servers que tengo configurados en mi sistema de 6 agentes, qué hace cada uno, y por qué lo elegí.
GitHub MCP Server. Mis agentes hacen commit, crean ramas, abren PRs y hacen push directamente. Rafiki — el agente que escribe este blog — genera el post, hace commit y push a main, y Vercel despliega automáticamente. Sin que yo toque nada. Es probablemente el MCP server que más uso.
Filesystem MCP Server. Acceso al sistema de archivos local. Parece básico, pero es fundamental. Mis agentes leen archivos de configuración, escriben posts en markdown, crean SVGs, y manipulan directorios. Sin este servidor, un agente no puede ni leer el CLAUDE.md que define su propio comportamiento.
Google Search Console. FBS, mi agente de analítica, usa este servidor para tirar datos de impresiones, clics, CTR y posiciones. Con esos datos decide qué posts optimizar y cuáles crear nuevos. Es la conexión que alimenta toda mi estrategia SEO con datos reales, no con suposiciones.
Fetch / Web MCP Server. Permite a los agentes hacer peticiones HTTP a cualquier URL. Remy, mi agente de research, lo usa para consultar APIs, scraping ligero de datos públicos y verificación de fuentes. Es el servidor que convierte a un agente en un investigador con acceso a internet.
Lo que tienen en común todos estos servidores es que son estables, mantenidos por la comunidad o por las propias empresas detrás del servicio, y llevan meses funcionando en producción real. No estoy experimentando — estoy usando MCP en un negocio que depende de ello cada día.
El coste adicional de usar MCP servers: cero. Son parte de la infraestructura de Claude Code. No pagas por servidor ni por conexión. Mi coste total sigue siendo 142€/mes por todo el stack.
MCP vs API tradicional: cuándo usar cada una
Aquí es donde la mayoría de la gente se confunde. MCP no reemplaza las APIs — las hace accesibles sin que tú tengas que escribir la integración. Son capas distintas que hacen cosas distintas.
Cuando usas una API tradicional, tú escribes el código. Defines los endpoints, manejas la autenticación, parseas las respuestas, gestionas los errores. Es potente pero requiere conocimiento técnico y mantenimiento constante. Si la API cambia, tu código se rompe.
Cuando usas MCP, el servidor se encarga de toda esa complejidad. Tú le dices al agente "haz commit de estos cambios" y el MCP server de GitHub se encarga de traducir eso en las llamadas API correctas, con la autenticación correcta, manejando errores y reintentos. El agente no sabe ni necesita saber cómo funciona la API de GitHub por debajo.
| Aspecto | API tradicional | MCP |
|---|---|---|
| Quién escribe la integración | Tú (o tu equipo) | El servidor MCP (ya hecho) |
| Autenticación | Manual por cada servicio | Configurada una vez en el servidor |
| Manejo de errores | Código personalizado | Incluido en el servidor |
| Actualizaciones de API | Rompen tu código | Las absorbe el servidor |
| Tiempo de setup | Horas/días por integración | Minutos por servidor |
| Flexibilidad | Total (tú controlas todo) | Limitada a lo que expone el servidor |
| Requiere programar | Sí, siempre | No para usar; sí para crear servers |
La regla que sigo yo: si existe un MCP server para lo que necesito, lo uso. Si no existe y es algo muy específico de mi negocio, lo creo con ayuda de Claude Code — que irónicamente usa MCP para ayudarme a crear el servidor. Es meta, lo sé.
La excepción: si necesito control total sobre la integración — timing exacto, lógica de negocio compleja, transformaciones de datos específicas — voy directo a la API. MCP es perfecto para el 80% de los casos. Para el otro 20%, las APIs siguen siendo imprescindibles.
¿Quieres montar tu propio equipo de agentes de IA?
Cada semana comparto lo que funciona (y lo que no) montando agentes reales para mi negocio. Sin teoría, sin humo.
🎁 Al suscribirte recibes mi guía: cómo llegué a 500 subs en <1 mes con agentes IA.
Cómo configurar tu primer MCP server en Claude Code
Configurar un servidor MCP en Claude Code es más sencillo de lo que parece. Voy a mostrarte el proceso real, sin edulcorar, con el servidor de filesystem como ejemplo — porque es el más universal y el que todo el mundo necesita.
Toda la configuración de MCP servers vive en un archivo JSON. En Claude Code, puedes tenerlo a nivel de proyecto (en .claude/settings.json) o a nivel global (~/.claude/settings.json). Yo prefiero por proyecto porque cada agente tiene sus propios servidores.
La estructura es directa. Dentro del archivo de settings defines un bloque mcpServers con el nombre del servidor, el comando para lanzarlo, y los argumentos que necesita. Para el filesystem server, le dices qué directorios puede acceder. Para GitHub, le pasas el token. Para Google, las credenciales de service account.
El primer arranque suele ser el más lento — el servidor se descarga, se instala la dependencia, y Claude Code verifica la conexión. A partir de ahí, cada vez que abres Claude Code en ese proyecto, los servidores se levantan automáticamente en segundo plano. El agente ya tiene acceso desde la primera interacción.
Un error típico de principiante: configurar demasiados servidores a la vez. Yo empecé solo con filesystem y GitHub. Cuando los tenía estables, añadí los demás uno a uno. Cada servidor nuevo es un punto de fallo potencial durante el setup. Mejor ir paso a paso.
El equivalente en herramientas tradicionales — sin MCP — sería escribir scripts personalizados para cada integración, mantenerlos tú, y rezar para que no se rompan cuando el servicio actualiza su API. Con MCP, la comunidad mantiene los servidores y tú solo los configuras. Es el mismo principio que hizo que npm triunfara: no reinventes la rueda, usa la que ya funciona.
Qué puedes hacer con MCP que antes era imposible (o carísimo)
La pregunta real no es "qué es MCP" sino "qué cambia en mi negocio". Y la respuesta, después de 4 meses usándolo, es: más de lo que pensaba cuando empecé.
Publicación automática end-to-end. Rafiki escribe un post, crea los SVGs, hace build, commit, push, y solicita indexación en Google. Todo en una cadena. Sin MCP, necesitaría un humano en al menos 3 de esos pasos — subir los archivos, hacer el deploy, solicitar la indexación manualmente. Con MCP conectado a filesystem + GitHub + fetch, el agente ejecuta los 6 pasos solo.
Analítica que se convierte en acción. FBS tira datos de Search Console vía MCP, detecta que un post tiene impresiones pero 0 clics, y puede directamente modificar el title y la meta description del post. El ciclo "dato → decisión → acción" que normalmente requiere un analista + un editor, lo hace un agente con dos MCP servers.
Research con fuentes verificadas. Remy no inventa datos. Usa el MCP server de fetch para consultar fuentes reales, verificar estadísticas y traer datos actualizados. Cuando lee que el 40% de apps empresariales integrarán agentes de IA antes de que acabe 2026 (fuente: Gartner), va a verificar el dato antes de incluirlo en un brief. Eso es algo que un chatbot sin MCP simplemente no puede hacer.
Lo que todas estas situaciones tienen en común es que eliminan el paso intermedio humano para tareas que no requieren juicio creativo. No es que yo no pueda hacer commit manualmente o consultar Search Console. Es que cada minuto que gasto en esas tareas operativas es un minuto que no dedico a pensar en estrategia, producto o relaciones. Y esos minutos, multiplicados por 6 agentes, son horas al día.
Un dato para poner esto en perspectiva: 5,6 millones de solopreneurs globales ya superan los 100.000 dólares al año. La diferencia entre los que escalan y los que no suele estar en si consiguen liberarse de las tareas operativas. MCP es la infraestructura que hace posible esa liberación.
Los límites reales de MCP (lo que nadie te cuenta)
No todo es perfecto. MCP tiene limitaciones reales que conviene conocer antes de construir tu sistema alrededor de él.
Dependencia de servidores comunitarios. La mayoría de MCP servers los mantiene la comunidad open source. Eso significa que si el mantenedor abandona el proyecto o lo rompe en una actualización, tu agente se queda sin esa conexión hasta que alguien lo arregle. Me ha pasado una vez en 4 meses — no es frecuente, pero es real. La solución: tener siempre un plan B manual para cada función crítica.
Latencia en cadenas largas. Cuando un agente encadena 4-5 operaciones MCP en secuencia (leer archivo → modificar → commit → push → verificar), cada paso añade latencia. No es mucho — estamos hablando de segundos, no minutos — pero en flujos complejos se nota. La diferencia entre ejecutar algo en 30 segundos o en 2 minutos es real cuando lo haces 20 veces al día.
Seguridad y permisos. Cada MCP server tiene acceso a un servicio real con permisos reales. Si configuras mal el token de GitHub, tu agente podría hacer push a un repo que no debe. Si le das acceso a filesystem sin restricciones de directorio, puede leer archivos que no debería. La regla: principio de mínimo privilegio, siempre. Dale a cada servidor solo los permisos que necesita y nada más.
No sustituye la arquitectura. MCP conecta herramientas, no diseña flujos. Si tu sistema de agentes está mal pensado — roles confusos, contextos mal definidos, CLAUDE.md mal escritos — MCP no lo arregla. Solo hace que la conexión entre piezas sea más fácil. La calidad del sistema sigue dependiendo de ti.
MCP y el futuro del emprendimiento con agentes
MCP no es solo un protocolo técnico. Es un cambio de paradigma en cómo los emprendedores construyen equipos. Cada MCP server es como contratar a un "especialista" que sabe interactuar con un servicio concreto, pero que le cuesta cero al mes y está disponible 24/7.
Cofundé GuruWalk con un equipo de 15 personas. Cada persona necesitaba acceso a herramientas — GitHub, analytics, CMS, herramientas de marketing. Configurar esos accesos, mantener los permisos, coordinar quién hacía qué en cada herramienta... era un trabajo a tiempo completo solo gestionar la gestión.
Ahora tengo 6 agentes conectados a las herramientas que necesitan vía MCP. No hay onboarding. No hay rotación. No hay "espera que te doy acceso al repo". Configuro el servidor una vez, y el agente tiene acceso desde el minuto uno. El equivalente humano de este setup — 4-5 personas con acceso a las mismas herramientas — costaría entre 12.000 y 16.000€ al mes contando sueldo bruto más Seguridad Social.
¿Es MCP perfecto? No. ¿Es el futuro de cómo se conectan los agentes con el mundo real? Sin ninguna duda. El 90% de startups de IA que fracasarán en 2026 lo harán por no tener modelo de negocio, no por falta de tecnología. MCP es la tecnología. El modelo de negocio lo pones tú.
Si estás empezando con agentes de IA, mi consejo es: configura MCP primero. Antes de escribir CLAUDE.md, antes de definir roles, antes de nada. Un agente sin acceso a herramientas reales es solo un chatbot con buen marketing. Un agente con MCP es un trabajador.
Y la diferencia entre uno y otro, tío, es la diferencia entre hablar de escalar y realmente escalar.
MCP es lo que separa un agente que habla de un agente que trabaja. Antes de configurar MCP, Claude era un asistente inteligente. Después de MCP, se convirtió en mi equipo. La diferencia no es de grado — es de naturaleza.