Tu equipo lleva semanas intentando que sus agentes de IA accedan de forma fiable a herramientas externas: una base de datos, una API de CRM, un sistema de ficheros. El resultado habitual es una colección de adaptadores artesanales, prompts que encodan contexto a mano y pipelines que se rompen cada vez que cambia un endpoint. El coste de mantenimiento se dispara antes de que el sistema llegue a producción real.

Esto no es un problema de modelo. Es un problema de protocolo. Y el Model Context Protocol (MCP), impulsado por Anthropic y adoptado ya por OpenAI, Google DeepMind y la mayoría de los frameworks Agentic relevantes, es la respuesta que la industria lleva años esperando. El problema es que muchos equipos lo están adoptando sin entender sus implicaciones arquitectónicas reales, y eso tiene un precio.

💡 Pro-Tip del CTO: El error más común que veo en el mercado es tratar MCP como si fuera una librería más que integras en un sprint. MCP no es un SDK: es un cambio de modelo mental sobre cómo tus agentes negocian capacidades con el entorno. Los equipos que lo implémentan sin rediseñar su capa de herramientas acaban con los mismos problemas de antes, pero ahora con una capa de abstracción extra encima.

Qué es MCP y Por Qué Ahora 🔧

MCP es un protocolo abierto cliente-servidor que estandariza cómo los modelos de lenguaje descubren, invocan y reciben resultados de herramientas externas. La analogía más precisa: es el USB-C del ecosistema Agentic. En lugar de que cada framework (LangChain, AutoGen, CrewAI, LlamaIndex) implemente su propio sistema propietario de tool-calling, MCP define un contrato común.

La arquitectura MCP distingue tres entidades clave:

• MCP Host: el agente o la aplicación LLM (Claude, GPT-4o, Llama 4, tu agente custom).
• MCP Client: el componente dentro del host que gestiona la conexión con los servidores.
• MCP Server: el proceso ligero que expone herramientas, recursos y prompts al agente.

La comunicación se produce vía JSON-RPC 2.0 sobre stdio o HTTP/SSE. No hay estado compartido entre sesiones por defecto, lo que lo hace stateless y más fácil de escalar horizontalmente. Sin embargo, esa apatridia tiene implicaciones que muchos equipos no anticipan.

Los Tres Problemas de Arquitectura que MCP Expone (No Resuelve)

Adoptar MCP sin una estrategia arquitectónica sólida equivale a migrar a microservicios sin un API Gateway: introduces complejidad distribuida sin los beneficios correspondientes. Estos son los tres problemas reales que emergen en producción:

1. Gestión de Identidad y Autorización entre Agentes

MCP no define un modelo de seguridad nativo entre servidores. Si tu agente puede invocar herramientas críticas (escritura en base de datos, envío de emails, ejecución de queries SQL), necesitas implementar tú authn/authz sobre el transporte. El patrón más robusto en producción combina:

• JWT con scopes granulares por herramienta.
• Allowlists estáticas de operaciones permitidas por rol de agente.
• Rate limiting a nivel de MCP Server, no a nivel de LLM.

Ignorar esto significa que cualquier prompt injection exitoso tiene acceso irrestricto a todas las herramientas registradas.

2. Observabilidad y Trazabilidad de Llamadas a Herramientas

Un agente en producción puede encadenar 15-30 tool calls en una sola sesión. Sin trazabilidad adecuada, depurar un fallo es como buscar un null pointer en un sistema distribuido sin logs. Las capas que debes instrumentar:

• Tracing distribuido (OpenTelemetry) desde el LLM hasta cada MCP Server.
• Registro de todas las invocaciones con timestamp, parámetros de entrada y respuesta (esto tiene implicaciones de GDPR que hay que gestionar).
• Métricas de latencia por herramienta: los cuellos de botella rara vez están donde crees.
• Alertas sobre patrones anómalos de uso de herramientas (un agente que invoca delete_record 200 veces en un minuto es una señal de alarma, no de eficiencia).

3. Gestión del Contexto y Coste Real de Tokens

Cada llamada a una herramienta MCP devuelve contenido que se inyecta en el contexto del agente. Con modelos como GPT-4o o Claude 3.5 Sonnet, el coste por token en sesiones largas puede dispararse más de lo esperado. Los patrones que mitigan esto:

• Truncado selectivo de respuestas de herramientas: no pases el JSON completo de un endpoint si solo necesitas 3 campos.
• Caché de herramientas para llamadas idémpotentes con TTL corto (Redis sobre el MCP Server).
• Context compression automático entre pasos del agente usando modelos más baratos (Haiku, GPT-4o-mini) para resumir tool outputs antes de pasarlos al modelo principal.

El Patrón de Despliegue que Funciona en Producción 🛡️

Después de desplegar sistemas Agentic en entornos empresariales reales, el patrón que mejor escala con MCP es el siguiente:

Capa 1 — AI Gateway centralizado: Kong AI Gateway o AWS Bedrock Gateway delante de todos los LLMs. Gestiona throttling, logging y failover de modelos en un único punto.

Capa 2 — MCP Servers como microservicios contenerizados: cada MCP Server en un contenedor independiente (Docker/Kubernetes), con sus propios recursos, límites de CPU/RAM y configuración de seguridad. No compartas MCP Servers entre agentes con diferentes niveles de privilegio.

Capa 3 — Orquestador de agentes con circuit breakers: si un MCP Server falla, el agente no debe colapsar. Implementa patrones de resiliencia clásicos: circuit breaker (Resilience4j o equivalente en Go/Python), retry con backoff exponencial y fallback graceful.

Capa 4 — Evaluación continua (Evals): no lances un agente a producción sin un conjunto de evals automáticos que verifiquen que las herramientas se invocan correctamente ante inputs conocidos. Frameworks como Braintrust o PromptFoo permiten integrar evals en el CI/CD.

MCP vs. Function Calling Nativo: Cuándo Usar Cada Uno

La pregunta que más recibo en conversaciones con CTOs: ¿cuándo MCP y cuándo el function calling nativo de OpenAI/Anthropic?

Regla práctica:

• Function calling nativo: cuando tienes un único agente, un único modelo y herramientas simples que no se reutilizan entre proyectos. Es más sencillo de implementar y la latencia es menor.
• MCP: cuando tienes múltiples agentes que necesitan acceder a las mismas herramientas, cuando las herramientas deben ser independientes del modelo (portabilidad entre GPT-5, Claude 4, Llama 4), o cuando el equipo de backend quiere mantener las herramientas de forma autónoma sin tocar el código del agente.

La madurez de una arquitectura Agentic se mide, entre otras cosas, por cuánto tiempo puede cambiar el modelo subyacente sin que los equipos de producto noten el cambio. MCP es un habilitador clave para alcanzar ese nivel de desacoplamiento.

El Baño de Realidad: El Coste de No Abordar MCP Ahora

Los equipos que siguen construyendo integraciones artesanales de tool-calling en 2025 están acumulando deuda técnica Agentic a un ritmo que no será sostenible en 12 meses. Cuando GPT-5 o Claude 4 aterricen en producción con capacidades de razonamiento multi-step significativamente superiores, los sistemas que no estén basados en estándares como MCP necesitarán una reescritura parcial o total de su capa de herramientas.

Además, el ecosistema de MCP Servers de terceros está creciendo rápidamente: Stripe, GitHub, Slack, Linear, Notion y docenas de proveedores más ya publican sus propios MCP Servers. Cada mes que pasa sin adoptar el estándar es un mes que tus competidores pueden integrar nuevas capacidades en horas, mientras tu equipo tarda semanas en adaptar sus conectores propietarios.

El coste real no es el tiempo de implementar MCP. Es el tiempo que perderás reescribiendo lo que ya deberías tener bien hecho.

¿Estás implementando MCP en tu organización o te has encontrado con los problemas que describo? Deja tu experiencia en los comentarios: las conversaciones técnicas reales son más útiles que cualquier post. Si el artículo te ha aportado perspectiva, un ❤️ o un 🦄 ayuda a que llegue a más arquitectos que lo necesitan. Y si tienes un colega CTO que todavía no ha oído hablar de MCP, 🔖 guárdalo para cuando lo necesite.

Sobre el autor:
Aurimas Markunas es CTO & Senior Cloud Architect especializado en sistemas distribuidos, Kubernetes, AWS, Go y Python. Dedica su día a día a la integración de inteligencia artificial en entornos de producción, huyendo del hype para construir sistemas escalables y seguros. 🔗 Conecta conmigo en LinkedIn

🚀 En Empleado Inteligente no hacemos chatbots; construimos ecosistemas de Agentic AI y automatización avanzada que operan 24/7 integrados en tu back-office.