Qué es MCP: el protocolo que conecta agentes IA con herramientas
MCP (Model Context Protocol) estandariza cómo los agentes de IA se conectan a herramientas externas. Explicación con ejemplos en Python comentados línea a línea.
Colaboradores: Ivan Garcia Villar, Esther Aznar
Llevas años usando el mismo cable USB para el teléfono, el teclado y el disco duro externo. Nunca tuviste que pensar en compatibilidades. Antes de USB, cada fabricante usaba su propio conector. El caos era total. MCP es, para los agentes de IA, exactamente lo que USB fue para los periféricos: un estándar que elimina el caos de las integraciones a medida.
El problema que MCP viene a resolver
Imagina que quieres construir un asistente de IA que pueda hacer tres cosas:
-
Buscar información en GitHub (donde tienes el código de tu proyecto)
-
Revisar apuntes en Notion (tu gestor de tareas personal)
-
Hacer preguntas a una base de datos (donde guardas datos de clientes)
El problema: Sin un estándar, tendrías que crear un “puente de comunicación” diferente para cada conexión. Uno para GitHub, otro para Notion, otro para la base de datos. Estos puentes son códigos complicados y personalizados.
Y aquí viene lo peor: Si cambias de asistente de IA (usas otro modelo en lugar del anterior), tienes que reescribir todos esos puentes desde cero. Es como si tuvieras que redecorar tu casa cada vez que cambias de muebles.
Antes de MCP (antes de noviembre de 2024): Cada programador que construía un asistente de IA escribía sus propios puentes personalizados. Nadie podía compartir el código, porque cada puente era único. El resultado era un desorden: código que se rompía fácilmente, difícil de arreglarlo si algo fallaba, y que nadie más podía reutilizar.
| Antes de MCP (Caos) | Con MCP (Orden) |
|---|---|
| 🔴 Crear un puente diferente para GitHub, Notion, y base de datos | 🟢 Un puente para GitHub que funciona en todas partes, uno para Notion, uno para la base de datos |
| 🔴 Si usas Claude, escribes puentes X. Si usas otro modelo, escribes puentes Y completamente diferentes | 🟢 Escribes los puentes una sola vez. Funcionan con Claude, Cursor, tu propio programa, lo que sea |
| 🔴 Si algo se rompe, tienes que revisar y arreglarlo en múltiples lugares | 🟢 Arreglas el puente una sola vez y todos los que lo usan se benefician automáticamente |
| 🔴 Código confuso que solo entienden sus creadores | 🟢 Un formato estándar: todos entendemos el mismo lenguaje |
Eso es lo que MCP resuelve. En lugar de que cada programador cree sus propios puentes, MCP establece un “lenguaje universal” que entienden todos los asistentes de IA. Así, creas el puente una sola vez y funciona con cualquier asistente que hable MCP. No es solo una idea, es un protocolo concreto y específico que puedes usar hoy mismo.
¿Qué es el Model Context Protocol?
MCP es un protocolo abierto creado por Anthropic y publicado como estándar abierto en noviembre de 2024 [1].
Dicho de forma simple: MCP es un “idioma” común que utilizan los agentes de IA para hablar con las herramientas. Es como si una herramienta “habla MCP” y un agente también “habla MCP”, entonces se entienden sin problemas.
Un protocolo es simplemente un conjunto de reglas que dos programas acuerdan seguir para comunicarse. Por ejemplo, HTTP es el protocolo que usa tu navegador para pedir páginas web a internet.
Lo importante de MCP: si escribes una herramienta en MCP hoy, cualquier agente (Claude, Cursor, o tu propio script) que también entienda MCP podrá usarla sin que tengas que cambiar nada.
Es como tener un enchufe universal: una vez que lo tienes, funciona con cualquier dispositivo que también use ese enchufe.
¿Cómo funciona MCP? La arquitectura cliente-servidor
Imagina que MCP es una conversación entre dos personajes:
El cliente MCP es quien hace la pregunta. Puede ser Claude, Cursor, o un programa que hayas escrito tú.
El servidor MCP es quien responde. Es la herramienta que has construido. Escrita una sola vez, pero capaz de responder a cualquier cliente que entienda MCP.
Ejemplo de cómo funciona paso a paso:
- El usuario pregunta: “¿Cuál es el clima en Madrid?”
- El agente de IA piensa: “Necesito información del clima”
- El cliente MCP pregunta: “Servidor, ¿tienes el clima de Madrid?”
- El servidor MCP responde: “Sí, el clima es soleado, 22°C”
- El agente contesta: “En Madrid hace sol y hay 22 grados”
La analogía del USB: El servidor MCP es como tener un aparato universal que funciona en cualquier toma de corriente compatible. No importa en qué ciudad estés (qué cliente uses), el aparato funciona igual.
Tu primer servidor MCP en Python
Lo que necesitas antes de empezar:
-
Python 3.10 o superior (si no lo tienes, descárgalo de python.org)
-
Ejecuta
pip install mcpen tu terminal -
Saber qué es una función en Python (una función es un conjunto de instrucciones que hace algo)
¿Cómo creamos un servidor MCP? Usamos FastMCP, que es una herramienta que viene en la librería mcp. Lo bueno de FastMCP es que es muy simple: solo tienes que escribir una función normal en Python, y FastMCP automáticamente la convierte en una herramienta que los agentes de IA pueden usar.
from mcp.server.fastmcp import FastMCP
mcp = FastMCP("weather-server")
@mcp.tool()
def get_weather(city: str) -> str:
"""Obtiene el clima actual de una ciudad"""
return f"El clima en {city} es soleado, 22°C"
if __name__ == "__main__":
mcp.run(transport="stdio")
Guarda este archivo como weather_server.py. No necesitas ejecutarlo tú directamente. El cliente lo arrancará automáticamente.
El cliente que llama a esa herramienta
Ahora escribiremos el programa que usa esa herramienta. Normalmente sería Claude o Cursor quien lo hiciera, pero lo escribimos nosotros para que entiendas cómo funciona.
Nota importante: El código usa palabras como async y await. No te asustes: son solo palabras clave de Python para esperar respuestas. No es necesario que entiendas los detalles. Solo copia el código y ejecútalo.
from mcp import ClientSession, StdioServerParameters
from mcp.client.stdio import stdio_client
import asyncio
async def main():
server_params = StdioServerParameters(
command="python",
args=["weather_server.py"],
)
async with stdio_client(server_params) as (read, write):
async with ClientSession(read, write) as session:
await session.initialize()
response = await session.list_tools()
print("Herramientas disponibles:")
for tool in response.tools:
print(f" - {tool.name}: {tool.description}")
result = await session.call_tool("get_weather", arguments={"city": "Madrid"})
print("\nResultado:")
for content in result.content:
print(content.text)
if __name__ == "__main__":
asyncio.run(main())
Flujo de comunicación entre cliente y servidor
Pasos para probar el ejemplo
Paso 1: Crea una carpeta nueva en tu ordenador (por ejemplo, mi-mcp)
Paso 2: Abre tu editor de código favorito (VS Code, Notepad, lo que sea) y copia el primer código (el servidor). Guárdalo como weather_server.py en esa carpeta.
Paso 3: Copia el segundo código (el cliente). Guárdalo como weather_client.py en la misma carpeta.
Paso 4: Abre una terminal en esa carpeta y escribe:
python weather_client.py
Si no funciona, intenta:
python3 weather_client.py
Paso 5: Si todo va bien, verás esto en la pantalla:
Herramientas disponibles:
- get_weather: Obtiene el clima actual de una ciudad
Resultado:
El clima en Madrid es soleado, 22°C
Si no funciona:
-
Comprueba que ambos archivos están en la misma carpeta
-
Comprueba que tienes Python 3.10 o superior: escribe
python --versionen la terminal -
Comprueba que instalaste MCP: escribe
pip install mcpen la terminal
¿Por qué importa MCP ahora?
Hace poco menos de un año, en noviembre de 2024, MCP era una idea nueva. Hoy, casi un año después, el protocolo ya está integrado en herramientas que usas a diario:
-
Cursor y Zed (editores de código) lo soportan de forma nativa
-
Continue (plugin de IA para editores) también lo usa
-
Claude Desktop lo incluye
-
El repositorio oficial tiene servidores listos para usar: GitHub, Slack, sistemas de archivos, bases de datos
Lo importante: si construyes un servidor MCP hoy, funciona con cualquiera de estos clientes sin que tengas que cambiar nada. No necesitas reescribir nada. No necesitas crear versiones diferentes.
Eso es lo que explica por qué los equipos de ingeniería están usando MCP: la estandarización es lo que permite que los agentes pasen de ser un experimento interesante a ser una herramienta productiva en tu empresa. Sin MCP, cada nueva herramienta te cuesta reescribir integraciones. Con MCP, la escribes una vez y funciona en todas partes.
Lo que MCP no es
Antes de seguir, vale la pena aclarar algunos malentendidos habituales.
MCP no es un agente
MCP es el protocolo que conecta agentes con herramientas. El agente es el modelo que decide qué preguntar y qué hacer con la respuesta. El servidor MCP no toma decisiones: simplemente ejecuta lo que le piden y devuelve el resultado.
¿Hace MCP tu agente más inteligente?
No. Tener un servidor MCP perfecto no hace que tu agente sea más inteligente. La calidad de las respuestas depende del modelo, del prompt y de cómo está diseñado el sistema. MCP solo estandariza la parte de la comunicación.
MCP no es exclusivo de Claude ni requiere la nube
Es un estándar abierto que funciona con cualquier cliente compatible. Y puede correr completamente en local: no necesitas ningún servicio externo para desarrollar y probar tu servidor.
MCP no siempre es necesario
Si estás construyendo una herramienta que solo tú vas a usar en un script propio, una llamada directa a una API es más que suficiente. MCP tiene sentido cuando quieres que tu herramienta sea reutilizable por múltiples agentes o clientes distintos. La complejidad añadida del protocolo se justifica cuando el servidor se usa en más de un contexto.
¿Por dónde seguir?
Construye tu primer servidor MCP con el código de los ejemplos anteriores adaptado a una herramienta que uses de verdad: una API, una base de datos local, un script que ejecutas frecuentemente.
Si quieres entender qué ocurre cuando un modelo llama a una herramienta sin MCP, lee tool calling paso a paso. MCP es la versión estandarizada del mismo mecanismo.
Cuando tengas tu agente funcionando con MCP, usa cómo evaluar agentes en producción para medir si hace lo que debe hacer.
Igual que USB hizo que cualquier periférico funcionara con cualquier ordenador, MCP hace que cualquier herramienta funcione con cualquier agente.
Checklist para empezar con MCP
-
Python 3.10+ instalado y
pip install mcpejecutado -
Servidor creado con
FastMCPy al menos una herramienta registrada con@mcp.tool() -
Servidor probado con el cliente de ejemplo (
weather_client.py) -
La herramienta devuelve un resultado legible en texto plano
-
El cliente puede listar las herramientas disponibles con
session.list_tools() -
El cliente puede llamar a la herramienta con
session.call_tool()y obtener respuesta -
Identificado un caso de uso real donde MCP tiene sentido (herramienta reutilizable por más de un cliente)
Fuentes
- Model Context Protocol — Announcement (Anthropic, noviembre 2024) — fecha de publicación como estándar abierto y descripción del protocolo.
- MCP Servers Repository — modelcontextprotocol/servers (GitHub) — implementaciones de referencia oficiales de servidores MCP para las integraciones más comunes (GitHub, Slack, sistemas de archivos, bases de datos).
- Documentación oficial MCP — modelcontextprotocol.io — especificación del protocolo, arquitectura cliente-servidor y guías de implementación.
- Python SDK oficial MCP — modelcontextprotocol/python-sdk (GitHub) — código fuente y documentación de la librería
mcp, incluyendo FastMCP yClientSession.
Preguntas Frecuentes
¿Qué diferencia hay entre MCP y simplemente llamar a una API directamente?
Llamar a una API directamente funciona bien cuando tú controlas el código cliente y el código que hace la llamada. MCP añade una capa de estandarización útil cuando quieres que tu herramienta sea accesible por múltiples agentes o clientes distintos sin tener que adaptar nada. Si tu herramienta la usan solo tus propios scripts, una llamada directa es más simple. Si quieres que Claude Desktop, Cursor y tu propio agente la usen sin cambiar nada, MCP tiene sentido.
¿Necesito saber qué es un agente de IA para usar MCP?
No para empezar. Puedes construir un servidor MCP con los ejemplos de este post sin haber construido nunca un agente. El servidor es simplemente una función Python que responde a peticiones con un formato estándar. El agente es quien decide cuándo llamarla, pero eso no es tu responsabilidad al escribir el servidor.
¿Por qué el código del cliente usa async y await?
Porque el cliente espera respuestas del servidor sin bloquear el programa. Es un patrón estándar en Python. No necesitas entender los detalles: solo copia el patrón async def main() / asyncio.run(main()).
¿Puedo usar MCP con un modelo que no sea Claude?
Sí. MCP es un estándar abierto y varios clientes lo implementan: Cursor, Zed, Continue, y otros. El servidor MCP que construyas funcionará con cualquier cliente que soporte el protocolo, independientemente del modelo de IA que use por debajo.
¿Qué pasa si el servidor MCP devuelve un error?
El protocolo MCP incluye un mecanismo de manejo de errores: el servidor puede devolver un resultado de error en lugar de un resultado válido. En producción, el agente que recibe ese error decide qué hacer (reintentar, informar al usuario, usar otra herramienta). En los ejemplos de este post, si hay un error en el servidor verás una excepción en la terminal del cliente con el mensaje correspondiente.
Dos escenarios concretos que aparecen al ejecutar el ejemplo por primera vez: si el valor de args en StdioServerParameters apunta a un archivo inexistente o con la ruta incorrecta, el proceso del servidor no arranca y el cliente lanza una excepción de subprocess (normalmente FileNotFoundError) antes de llegar a initialize(). Si el decorador @mcp.tool() está mal aplicado —por ejemplo, puesto sobre una clase en lugar de sobre una función— la herramienta no se registra y list_tools() devuelve una lista vacía en lugar de mostrar get_weather.