En mis últimas publicaciones, sobre llamadas a herramientas, exploré cómo los agentes de IA deciden qué herramienta usar y cómo usarla. Vimos cómo el modelo genera una llamada a una herramienta, nuestro código la ejecuta y el resultado se devuelve al modelo. Esto funciona bastante bien, pero hay un problema que pasamos por alto. Es decir, ¿de dónde vienen las herramientas?
En todos los ejemplos presentados anteriormente, definimos las herramientas nosotros mismos, a mano, en el mismo script de Python que el agente. Aparentemente, para un tutorial destinado a ayudarnos a comprender cómo funcionan todos estos, está bien, pero para una aplicación real, este enfoque se desmorona rápidamente. Y eso se debe a que cada herramienta necesita una integración personalizada, cada nuevo par de modelo-herramienta requiere su propio conector, etc. Piense, por ejemplo, que para una configuración que utiliza tres modelos de IA y diez herramientas, ya estamos manteniendo potencialmente treinta integraciones, y cada vez que uno de esos elementos cambia, algo puede romperse. En otras palabras, por muy bueno que este enfoque funcione para un modelo y una configuración de herramientas simples, no escala en absoluto.🤷♀️
Este no es un problema de nicho, sino más bien un desafío importante de la era de la IA agente. Y es exactamente para lo que se diseñó el Protocolo de contexto modelo (MCP).
Entonces, ¡echemos un vistazo!
🍨 DataCream es un boletín sobre inteligencia artificial, datos y tecnología. Si estás interesado en estos temas, ¡suscríbete aquí!
¿Qué pasa con el MCP?
Antes de MCP, conectar un modelo de IA a una herramienta externa (como una base de datos, un sistema de archivos, un espacio de trabajo de Slack o un repositorio de GitHub) significaba escribir una integración personalizada cada vez. El modelo necesitaba saber cómo llamar a la herramienta en su formato específico y, por otro lado, la herramienta necesitaba saber cómo responder en un formato que el modelo pudiera entender. Si el modelo cambiara, necesitaríamos reescribir la integración y, si hubiera una nueva herramienta, escribiríamos otra integración desde cero.
Esto a veces se denomina problema M×N, lo que significa que tenemos M modelos y N herramientas, lo que crea la necesidad de integraciones personalizadas M×N. Como puede imaginar, a medida que aumenta la cantidad de modelos y herramientas que deben usarse, esto no se escala muy bien.
Una metáfora útil para entender esto es la evolución y estandarización del hardware informático. En los primeros días de los periféricos de computadora, cada impresora, cada mouse, cada teclado tenía su propio conector propietario (por ejemplo, se compraba una impresora para una computadora específica y no funcionaba con otra). Finalmente, esto se resolvió mediante el uso de USB como conector único estándar, y cualquier dispositivo que lo admita funciona con cualquier computadora que lo admita.
Podemos imaginar a MCP como el USB para agentes de IA. Un protocolo estándar, y cualquier agente que lo admita puede conectarse a cualquier herramienta que lo admita, independientemente de qué empresa los haya creado.
Por lo tanto, el Model Context Protocol es un estándar abierto que permite a los desarrolladores crear conexiones bidireccionales seguras entre sus fuentes de datos y herramientas impulsadas por IA. Fue creado por Anthropic y lanzado como código abierto en noviembre de 2024. Básicamente, reemplaza las integraciones punto a punto personalizadas con un único protocolo cliente-servidor, lo que permite que cualquier host de IA compatible con MCP descubra y utilice herramientas y recursos de datos compatibles con MCP.
Más específicamente, la arquitectura MCP consta de tres participantes principales. Esos son:
El Host, que es la aplicación de IA con la que interactúa el usuario. Puede ser Claude Desktop, una extensión de VS Code o cualquier otra aplicación que incorpore un LLM. El anfitrión administra la ventana contextual del modelo, decide cuándo invocar las herramientas y enruta los resultados de las herramientas nuevamente a la conversación. El Cliente, que vive dentro del host y administra la conexión a uno o más servidores MCP. En otras palabras, el cliente es la parte de la aplicación que gestiona el protocolo MCP. El Servidor, que es donde residen las herramientas y los datos reales. Un servidor MCP expone capacidades (es decir, cosas que la IA puede hacer o leer) a través de una interfaz estandarizada. Una cosa importante a aclarar aquí es que el servidor nunca se comunica directamente con el LLM; toda interacción está mediada por el cliente.
En particular, en cuanto a las capacidades expuestas por el servidor MCP, estas pueden ser de tres tipos:
Herramientas: como ya hemos visto, las herramientas son operaciones ejecutables que devuelven su salida al modelo de IA. Estos pueden incluir consultar una base de datos, enviar un correo electrónico, llamar a una API meteorológica o cualquier otra cosa. Básicamente, podemos crear herramientas para cualquier operación imaginable, convirtiéndolas en el elemento poderoso facilitado por MCP, pero también en el más sensible a la seguridad. Recursos: los recursos son esencialmente acceso de solo lectura a los datos. Piense, por ejemplo, en el contenido de los archivos, los registros de la base de datos y las respuestas de la API. En otras palabras, los recursos pueden recuperar información pero nunca cambiar su estado. Avisos: Los avisos son plantillas de avisos reutilizables (¡claro!) que definen patrones de interacción estructurados. Por ejemplo, un flujo de trabajo de varios pasos para la revisión de código disponible en un servidor MCP es un mensaje.
Un servidor MCP simple en Python
Entonces, probemos todo esto en acción. Así es como se ve un servidor MCP mínimo en Python, utilizando el SDK de MCP oficial:
from mcp.server.fastmcp import FastMCP import request # crear un servidor MCP mcp = FastMCP(“weather-server”) @mcp.tool() def get_current_weather(city: str, unit: str = “celsius”) -> dict: “””Obtener el clima actual para una ciudad determinada usando Open-Meteo.””” # codificar geográficamente la ciudad geo = request.get( “https://geocoding-api.open-meteo.com/v1/search”, params={“nombre”: ciudad, “recuento”: 1} ).json() lat = geo[“results”][0][“latitude”]
lon = geo[“results”][0][“longitude”]
# buscar el clima clima = request.get( “https://api.open-meteo.com/v1/forecast”, params={ “latitud”: lat, “longitud”: lon, “current”: “temperature_2m,weather_code”, “temperature_unit”: unidad } ).json() return { “ciudad”: ciudad, “temperatura”: clima[“current”][“temperature_2m”]”unidad”: unidad } si __name__ == “__main__”: mcp.run()
Y esto es todo; Ahora hemos configurado un servidor MCP completo.
Observe cómo registramos nuestra función get_current_weather existente como una herramienta MCP usando @mcp.tool(). Más específicamente, @mcp.tool() genera automáticamente el esquema JSON a partir de las sugerencias de tipo y lo hace reconocible por cualquier host compatible con MCP. Por lo tanto, ya no se necesitan códigos de integración personalizados ni adaptadores específicos del modelo. Cualquier agente que sea compatible con MCP ahora puede llamar a esta herramienta meteorológica conectándose a este servidor MCP.
Entonces, ahora echemos un vistazo al lado del cliente, donde podemos conectar un agente a este servidor:
de importación antrópica Antrópico de mcp importar ClientSession, StdioServerParameters de mcp.client.stdio importar stdio_client async def run_agent_with_mcp(): server_params = StdioServerParameters( command=”python”, args=[“weather_server.py”]
) async con stdio_client(server_params) como (lectura, escritura): async con ClientSession(lectura, escritura) como sesión: # descubre herramientas disponibles en las herramientas del servidor = espera session.list_tools() print(f”Herramientas disponibles: {[t.name for t in tools.tools]}”) # Herramientas disponibles: [‘get_current_weather’]
# el agente ahora puede llamar a esta herramienta como cualquier otro resultado = await session.call_tool( “get_current_weather”, arguments={“city”: “Athens”, “unit”: “celsius”} ) print(result.content) # {‘city’: ‘Athens’, ‘temperature’: 29.0, ‘unit’: ‘celsius’}
En tiempo de ejecución, el host descubre las herramientas disponibles en el servidor sin necesidad de saber de antemano cuáles son. Entonces, el cambio clave es que pasamos de integraciones codificadas (recuerde la herramienta meteorológica codificada) a capacidades dinámicas y detectables (la herramienta meteorológica ahora está disponible para cualquier aplicación a través del servidor MCP).
Qué significa esto en la práctica
Antes de MCP, la pregunta “¿puede este agente utilizar esta herramienta?” requería una respuesta de ingeniería personalizada cada vez. Después de MCP, se resuelve de manera trivial y la pregunta se reemplaza por la no tan técnica “¿a qué herramientas deberían tener acceso los agentes?”. Más específicamente, ¿cómo deberían los agentes decidir qué herramientas utilizar y cómo aseguramos y controlamos el acceso a las herramientas a escala?
Pero la parte de ingeniería del problema está bastante resuelta, y esto también se ve subrayado por la impresionante adopción de MCP. MCP se lanzó en noviembre de 2024 con alrededor de 100.000 descargas mensuales de SDK. En marzo de 2025, OpenAI lo adoptó oficialmente. El mes siguiente, Google confirmó el soporte de MCP para Gemini y lo describió como “convirtiéndose rápidamente en un estándar abierto para la era de la inteligencia artificial”. En marzo de 2026, los SDK combinados de Python y TypeScript habían alcanzado 97 millones de descargas mensuales.
En diciembre de 2025, Anthropic donó MCP a la Agentic AI Foundation (AAIF), un fondo dirigido por la Linux Foundation, cofundado por Anthropic, Block y OpenAI. Este es el movimiento que consolidó la viabilidad a largo plazo de MCP, ya que ya no es un proyecto de un solo proveedor, sino que ahora se encuentra junto a Kubernetes y PyTorch en la cartera de infraestructura abierta de la Fundación Linux.
La consecuencia práctica es que estamos viendo el surgimiento de un ecosistema MCP: un mercado de servidores MCP prediseñados para herramientas y servicios populares. Existen servidores MCP para GitHub, Slack, PostgreSQL, Docker, Kubernetes y varios cientos de otras herramientas, todas ellas navegables a través del Registro MCP. En la mayoría de los casos, conectar su agente a uno de estos es ahora un paso de configuración, no un proyecto de ingeniería.
Para los desarrolladores que crean aplicaciones agentes, esto cambia significativamente el cálculo de compilación versus integración. Antes de MCP, conectar un agente a la base de conocimientos interna, CRM y sistema de emisión de tickets de su empresa requería tres integraciones personalizadas independientes. Con MCP, si existen servidores para esos sistemas (y cada vez más existen), es una cuestión de configuración. Si aún no existen, escribir un servidor MCP una vez significa que cualquier agente (no solo el que está creando hoy) puede usarlo.
También vale la pena saber qué no hace MCP. MCP no reemplazará las API REST. MCP es un protocolo para el acceso a herramientas de IA, no un estándar API de uso general. Sus API REST y GraphQL aún prestan servicios a clientes humanos y servicios tradicionales. La única adición es que MCP envuelve esas API para que sean accesibles para los LLM.
MCP es poderoso, y ese poder conlleva una verdadera responsabilidad de seguridad 🕸 que vale la pena señalar explícitamente. Más concretamente, los riesgos más comunes son:
Inyección rápida a través de la salida de la herramienta: esto se refiere a la posibilidad de que una fuente de datos maliciosa pueda devolver contenido diseñado para manipular el modelo para que llame a otras herramientas. Si su servidor MCP devuelve contenido generado por el usuario (tickets de soporte, notas de CRM, etc.), el modelo lo ve como un contexto confiable. Envenenamiento de herramientas: esto se refiere a la posibilidad de que un servidor MCP fraudulento pueda registrar herramientas con nombres que imiten a los confiables. De esta forma, el modelo puede elegir las herramientas equivocadas. Acceso con permisos excesivos: esto se refiere a la posibilidad de que un servidor MCP que expone herramientas de lectura y escritura a un agente que solo necesita acceso de lectura cree un riesgo innecesario.
La especificación oficial de MCP aborda esto: los hosts deben obtener el consentimiento explícito del usuario antes de invocar cualquier herramienta, y los implementadores deben crear flujos de autorización sólidos en sus aplicaciones. Para implementaciones de producción, trate el acceso a la herramienta MCP con el mismo rigor que aplicaría a cualquier API externa: permisos con privilegios mínimos, validación de entradas y manejo cuidadoso de las salidas de las herramientas antes de que vuelvan a ingresar al contexto del modelo.
en mi mente
Lo que encuentro más interesante de MCP no son los detalles técnicos, sino que representa un hito tecnológico importante para la IA. Todo ecosistema tecnológico pasa por una fase en la que la plomería se estandariza, y ese es siempre el momento en el que comienza la verdadera innovación. Esto permite a los usuarios y desarrolladores dejar de perder el tiempo intentando resolver problemas de conexión y empezar a dedicarlo a los problemas de las aplicaciones.
Estamos en ese momento de la IA agente. La cuestión de cómo se conectan los agentes a las herramientas está en gran medida resuelta. Las preguntas mucho más interesantes que surgen ahora son qué se les debería permitir hacer a los agentes, cómo deberíamos evaluar si lo están haciendo bien, cómo mantenemos la supervisión humana cuando los agentes asumen tareas más largas y complejas, etc. MCP es la base y lo que se construye sobre ella es la parte interesante.
✨ ¡Gracias por leer! ✨
Si llegó hasta aquí, es posible que le resulten útiles los pialgoritmos: una plataforma que hemos estado creando y que ayuda a los equipos a gestionar de forma segura el conocimiento organizacional en un solo lugar.
¿Te encantó esta publicación? Únase a mí en 💌 Substack y 💼 LinkedIn
Todas las imágenes del autor, salvo que se indique lo contrario.