Introducción a MCP: de la fragmentación a los servidores de herramientas compartidos
Por qué falla el pegado de contexto, cómo ayudó la llamada a funciones, por qué perjudican las integraciones N×M, y cómo MCP lleva a la pila de LLM hacia servidores de herramientas compartidas reutilizables N+M.
Fuentes: Introduction To MCP: Connecting LLMs to the Real World
¿Qué pasaría si un modelo de lenguaje pudiera conectarse, comunicarse y actuar en el mundo real? MCP es el conector entre la inteligencia y la acción.
ChatGPT se lanzó el 30 de noviembre, a mediados o finales de 2022, y aceleró el uso generalizado de la IA en tareas de productividad, actividades cotidianas y resolución de problemas. Posteriormente, los proveedores integraron la IA en productos ya utilizados por las personas: suites de productividad, aplicaciones de chat, motores de búsqueda, entornos de desarrollo integrados y software empresarial. Los asistentes dejaron de ser únicamente chatbots independientes.
Luego surgió un problema más complejo. Los modelos pueden razonar y escribir, pero el trabajo significativo requiere el contexto adecuado, datos, herramientas y sistemas apropiados. Conectar esas partes solía implicar integraciones personalizadas, APIs, sistemas de autenticación y código específico para cada herramienta. Esa dispersión tiene un nombre: fragmentación.
El problema de la fragmentación
La fragmentación se manifiesta cuando los equipos adoptan muchos asistentes de IA, cada uno atrapado en su propio ecosistema.
Imagínese a un desarrollador en VS Code. El asistente integrado en el editor comprende el repositorio dentro de sus límites. En cuanto necesitan problemas de GitHub o páginas de Confluence fuera del IDE, abandonan al asistente, copian el texto, lo pegan de nuevo y esperan que el modelo obtenga suficiente contexto.
Ese cambio constante de herramientas y ese traslado manual de contexto constituyen fragmentación: el modelo es inteligente, pero no puede ver automáticamente todos los sistemas que necesita la tarea.
Qué significa “contexto”
El contexto es todo lo que el modelo puede ver al responder. En la práctica: cualquier cosa que el LLM utilice para estructurar una respuesta, generalmente el historial de chat más lo que el usuario haya pegado.
Ejemplo: crear una función de seguridad con ChatGPT. Un desarrollador podría:
- JIRA — copiar los requisitos y criterios de aceptación al chat.
- GitHub — pegar las implementaciones y repositorios relacionados.
Solo entonces plantean la verdadera pregunta. El modelo responde mejor, pero el proceso es problemático:
- El copiado y pegado manual entre sistemas es lento.
- El contexto se dispersa; los desarrolladores se convierten en APIs humanas.
- El tiempo de compilación puede superar al tiempo de desarrollo.
- Más fuentes hacen que el proceso sea inviable a gran escala; los sistemas reales son más grandes que un búfer de pegado.
Ese problema impulsó el uso de llamadas a funciones/herramientas a mediados de 2023 (el trabajo de OpenAI).
Llamadas a funciones
La llamada a funciones permite que un modelo acceda a recursos externos a través de funciones y utilice los resultados como contexto. El chat por sí solo dio paso a la automatización de tareas: el modelo elige una herramienta, la aplicación la ejecuta y el modelo continúa.
Con herramientas definidas para JIRA, GitHub, MySQL, Drive, Slack, entre otros, el modelo puede elegir qué invocar a partir de la solicitud del usuario, obtener contexto y responder, sin necesidad de que una persona real ingrese manualmente la información.
Límites de las llamadas a funciones por aplicación
Imagínese tres asistentes de IA en una empresa. Cada uno sigue necesitando sus propias funciones e integraciones para bases de datos, GitHub, JIRA, Slack y otros servicios.
Si tiene N asistentes y M recursos externos, corre el riesgo de tener N × M integraciones. Diez asistentes × veinte recursos ≈ doscientos enlaces personalizados. El crecimiento hace que mantener esta red sea costoso.
Si cada aplicación sigue siendo dueña de cada integración, la fragmentación simplemente se ha trasladado: el problema de armar el contexto se ha convertido en el problema de la integración.
¿Puede N × M reducirse a N + M? Ahí es donde entra en juego MCP.
Model Context Protocol (MCP)
MCP es un protocolo abierto que estandariza la forma en que las aplicaciones de IA se conectan a herramientas, datos y servicios externos.
Existen dos roles principales:
- Cliente MCP — se encuentra en la aplicación/agente de IA, se conecta a un servidor y descubre y utiliza las herramientas/recursos expuestos.
- Servidor MCP — actúa como puente entre la aplicación de IA y GitHub, JIRA, una base de datos, Drive, Slack u otro servicio.
El cliente y el servidor comunican mediante MCP. En lugar de que cada asistente invente su propio adaptador para cada proveedor, las aplicaciones descubren y utilizan capacidades a través de un formato único.
Llamadas a funciones vs MCP — ejemplo con el clima
1. Llamadas a funciones
Definirás una función local de la aplicación que se comunica con la API meteorológica:
import requests
def get_weather(city):
response = requests.get(
"https://api.weather.com/current",
params={"city": city}
)
return response.json()
Registrarás esa función como una herramienta. El usuario pregunta “¿Cuál es el clima en Bengaluru?”. El modelo puede llamar a get_weather("Bengaluru"). La aplicación la ejecuta, devuelve los datos y el modelo completa la respuesta.
El equipo de la aplicación es responsable de definir y mantener esa función así como los componentes intermedios que permiten su uso con la API.
2. MCP
La información meteorológica se encuentra en un servidor MCP que se comunica con la API y expone una herramienta estándar:
@mcp.tool()
def get_weather(city: str):
"""Get the current weather for a city."""
return weather_api.get_current_weather(city)
La aplicación de IA es un cliente MCP que descubre la función get_weather. Con la misma pregunta del usuario, se descubre o invoca dicha función a través de MCP y luego se utiliza el resultado en la respuesta.
La diferencia radica en que MCP estandariza la comunicación entre la aplicación de IA y las capacidades disponibles, lo que permite que un único servidor sirva a muchos clientes compatibles.
Ventajas de MCP
- Mantenimiento menos repetitivo que los catálogos de funciones por aplicación
- Costos y tiempo reducidos en la integración
- Límites de seguridad más claros en el servidor
- La escalabilidad de las integraciones se acerca más a N + M que a N × M
Ese es el “porqué”. En las secciones siguientes se abordan la arquitectura, los aspectos internos y la implementación práctica.
Volviendo a analizar el caso de la función de seguridad
Regresemos al desarrollador que crea una funcionalidad de seguridad. Sin MCP ni herramientas adecuadas, su día se convierte en una búsqueda desordenada por JIRA, GitHub, MySQL, Drive y Slack. Cada paso implica copiar información de un contexto a otro. Con la llamada a funciones, esos pasos se convierten en funciones con nombre que el modelo puede invocar; sin embargo, cada asistente de la empresa sigue necesitando su propia copia de las integraciones.
MCP elimina esa duplicación. Un servidor meteorológico, un servidor JIRA y un servidor GitHub pueden servir a muchos clientes compatibles con MCP. La red N×M se acerca más a la configuración de N clientes más M servidores.
Notas de diseño que los equipos pasan por alto
Trate las descripciones de las herramientas como texto publicitario del producto: nombres claros y documentación de parámetros facilitan la selección correcta del modelo. Mantenga las herramientas de escritura detrás de un proceso de confirmación y separe los servidores de las herramientas del catálogo de solo lectura. Registre las llamadas a las herramientas con IDs de correlación para que una respuesta incorrecta pueda rastrearse a una recuperación defectuosa, en lugar de culpar al “modelo” de forma abstracta.
Al comparar la llamada a funciones con MCP para un nuevo sistema, pregúntese quién es responsable del ciclo de vida de la integración. Si la respuesta es “cada equipo de producto para siempre”, los servidores compartidos de MCP se pagan solos. Si la respuesta es “una demostración temporal”, una función local es suficiente.
Qué viene a continuación
Una vez que está clara la motivación —la fragmentación, el ensamblaje de contextos y los problemas de integración—, el siguiente paso es la arquitectura: cómo los clientes descubren las herramientas, cómo los servidores se autentican, cómo las sesiones transmiten resultados y cómo lanzar un primer servidor en producción. Esos temas merecen análisis detallados aparte; la función de este texto fue hacer innegable el “porqué” y mostrar el ejemplo relacionado con el clima desde ambos puntos de vista.
La fragmentación como problema presupuestario
Cuenta las horas que tu equipo dedica a pegar información de JIRA y GitHub en los chats. Ese trabajo representa un costo adicional para cada asistente de IA que adoptes. Las llamadas a funciones reducen el tiempo necesario para pegar datos, pero aumentan la cantidad de código de adaptación. MCP busca dirigir esos gastos hacia servidores compartidos en lugar de crear copias separadas para cada asistente.
Escribe el caso de negocio en esos términos: menos horas humanas dedicadas a las API, menos integraciones duplicadas y puntos de auditoría más claros. Para los departamentos financieros, los diagramas de arquitectura importan menos que las hojas de cálculo tipo N×M.
Consejos prácticos sobre el clima para los revisores
En la ruta de llamadas a funciones, el cliente HTTP para el clima se encuentra dentro de la aplicación. En la ruta MCP, está en un servidor que otras aplicaciones pueden reutilizar. La misma expresión del usuario, pero diferente titularidad de la integración. Se prefiere el servidor cuando ya se tiene en planes un segundo cliente; se prefiere la función local cuando el experimento no continúe en el próximo sprint.