MCP y la ingeniería de contexto: el protocolo que reordena cómo los agentes leen el mundo

Hace dos años, conectar un modelo de lenguaje a una herramienta externa exigía escribir glue code a medida, mantenerlo, y rezar para que la API no cambiara de versión. Hoy, según un análisis publicado esta semana por InfoWorld, el Model Context Protocol ha reconfigurado esa ecuación al situar la gestión del contexto como una disciplina propia —la llamada context engineering— en lugar de un problema de fontanería que cada equipo resolvía por su cuenta.

El artículo llega en un momento en que MCP lleva ya varios meses consolidado como estándar de facto para integraciones con Claude y, cada vez más, con otros LLMs. No es una novedad que MCP existe: lo que sí es relevante es el argumento de fondo que desarrolla InfoWorld, y que merece detenerse.

Qué es la ingeniería de contexto y por qué MCP encaja ahí

La context engineering parte de una constatación sencilla: el rendimiento de un modelo no depende solo de sus parámetros, sino de qué información llega al modelo, cuándo y en qué formato. Un Claude Opus 4.7 con una ventana de un millón de tokens tiene capacidad bruta de sobra; el problema real es decidir qué poner en esa ventana para que la respuesta sea útil.

MCP aborda esto con una arquitectura cliente-servidor en la que los MCP servers exponen herramientas, recursos y prompts bajo una interfaz estandarizada. El modelo no necesita saber si está tirando de una base de datos vectorial, de una API REST o de un sistema de ficheros local: recibe contexto estructurado a través del mismo contrato. Eso convierte el protocolo en una capa de abstracción para el contexto, no solo para la llamada a funciones.

La distinción importa. Hasta ahora, muchos equipos pensaban en MCP principalmente como un mecanismo de tool calling sofisticado. El enfoque de InfoWorld —y el que estamos viendo crecer en la comunidad de integradores— es diferente: MCP como infraestructura para decidir qué sabe el agente en cada momento de su ciclo de vida.

Dónde se nota en la práctica

En el ecosistema Claude, esto se traduce en varias piezas que ya funcionan juntas:

• MCP servers configurados en `claude_desktop_config.json` o desde Claude Code permiten que distintos agentes compartan el mismo servidor de contexto sin duplicar lógica.
• Los hooks de Claude Code (PreToolUse, PostToolUse, Stop) permiten interceptar el ciclo de vida para enriquecer o filtrar el contexto antes de que llegue al modelo, cerrando el bucle entre ingeniería de contexto y control de flujo.
• Skills y subagentes pueden consumir contexto servido por MCP servers especializados, lo que evita meter en el prompt principal información que solo necesita un subagente concreto.

El resultado práctico es que los sistemas mejor diseñados hoy no meten todo en el contexto desde el inicio: lo inyectan bajo demanda, según el estado del agente y la tarea en curso. MCP es el mecanismo que hace eso posible de forma reproducible.

Para quién es relevante esto

La pieza de InfoWorld está orientada a perfiles técnicos con conocimiento previo de LLMs, pero las implicaciones son amplias:

• Equipos que mantienen integraciones Claude verán en este enfoque una guía para refactorizar arquitecturas donde el contexto crece de forma descontrolada.
• Ingenieros de plataforma que estén evaluando estandarizar el acceso a herramientas internas encontrarán en MCP un argumento sólido para no reinventar el contrato cada vez.
• Desarrolladores de plugins y MCP servers tienen aquí una validación de que el trabajo en la capa de contexto tiene más impacto a largo plazo que optimizar el prompt en sí.

Lo que no aborda el artículo —y es una laguna— es la parte de observabilidad: saber qué contexto recibió el modelo en una llamada concreta sigue siendo difícil, y MCP no resuelve eso por sí solo. Es el siguiente problema que la comunidad tendrá que trabajar.

---

Desde EP, el planteamiento nos parece sólido y bien fundamentado: tratar el contexto como un recurso que se gestiona, no como un texto que se concatena, es exactamente el cambio de mentalidad que separa los agentes que funcionan en producción de los que solo funcionan en demos. MCP es hoy la herramienta más madura para hacer eso con Claude, aunque todavía queda trabajo en las capas de monitorización y depuración.