MCP - Modelo, Contexto y Prompt explicados con ejemplos simples

El enfoque MCP (Model - Context - Prompt) ha ganado fuerza como método estructurado para trabajar con modelos de lenguaje (LLMs) dentro de entornos técnicos. Sin embargo, para muchos desarrolladores, aún suena abstracto o complejo. Este artículo busca explicar los tres pilares de MCP con ejemplos simples y útiles para el desarrollo diario.

¿Qué es MCP?

MCP es una arquitectura conceptual que separa las tres partes fundamentales en una interacción con inteligencia artificial:

• Modelo: El motor de IA que procesa tu entrada (por ejemplo, GPT-4, Claude, Mistral).
• Contexto: Toda la información relevante que acompaña al prompt, como código fuente, reglas, documentación o historial de conversaciones.
• Prompt: La instrucción o tarea específica que le pides al modelo.

Modelo: el motor de inferencia

El modelo es el corazón del enfoque MCP. Es la pieza responsable de procesar los datos de entrada —es decir, el contexto y el prompt— y generar una respuesta coherente. Técnicamente, se trata de un modelo de lenguaje entrenado con grandes cantidades de texto y código, capaz de realizar tareas como generación de contenido, análisis semántico, completado de código, reformulación, inferencias lógicas, entre otras.

En la práctica, el modelo puede ser una instancia de un sistema público como GPT-4 de OpenAI, Claude de Anthropic, Amazon Titan o Google Gemini. También puede tratarse de modelos privados o fine-tuned, entrenados específicamente sobre el dominio de la empresa, como un LLM especializado en lenguaje legal, financiero o médico. Elegir el modelo correcto no es trivial: implica equilibrar precisión, velocidad, costos de uso, capacidad de contexto y requerimientos de privacidad o cumplimiento normativo.

Para entenderlo de forma simple, podemos recurrir a una analogía: el modelo es como un chef altamente capacitado. Es capaz de cocinar una gran variedad de platos, pero para hacerlo bien, necesita dos cosas fundamentales: ingredientes y una receta. Si no tiene ninguno de esos elementos, improvisará con lo que encuentre. Lo mismo ocurre con un modelo: sin contexto relevante ni una instrucción clara (el prompt), responderá de manera genérica, posiblemente irrelevante o incluso incorrecta.

Pero la analogía no se queda ahí. No todos los chefs dominan todas las cocinas. Algunos son expertos en repostería, otros en comida asiática, y otros en cocina molecular. Lo mismo ocurre con los modelos de lenguaje. Algunos modelos están optimizados para generación de código (como Codex o StarCoder), otros para comprensión de texto legal, otros para razonamiento matemático, y otros para tareas conversacionales. Intentar usar un modelo especializado en generación creativa para analizar logs técnicos o estructuras de código complejas probablemente no dará buenos resultados.

Desde el punto de vista técnico, un error común es tratar al modelo como una constante. En realidad, es un componente que puede y debe cambiar según el tipo de tarea. Por ejemplo, un flujo de CI/CD que integra IA para generar pruebas automáticas puede utilizar un modelo robusto como GPT-4, mientras que una tarea más liviana como traducir documentación interna puede delegarse a un modelo más barato y rápido. Esta flexibilidad es clave para escalar MCP en entornos de producción de forma eficiente.

Además, el modelo también puede definirse como una capa abstracta dentro de un sistema, desacoplada del resto de los componentes. Esto permite intercambiar proveedores, controlar versiones, evaluar nuevos lanzamientos y ajustar hiperparámetros (como temperatura o top-k) según el uso esperado. En ambientes regulados, esta capa también facilita cumplir con auditorías, validaciones y pruebas de confiabilidad.

En resumen, entender al modelo como un componente dinámico, configurable y alineado con los objetivos del flujo de trabajo es esencial para aprovechar verdaderamente el enfoque MCP. No se trata simplemente de "usar IA", sino de usar la IA correcta, para el problema correcto, en el momento correcto.

Contexto: los ingredientes del problema

Dentro del enfoque MCP, el contexto representa toda la información que el modelo necesita conocer para ejecutar correctamente la tarea que se le está solicitando. No es parte del prompt en sí, pero influye profundamente en el resultado que se obtiene. Un modelo de lenguaje, por muy avanzado que sea, no tiene memoria del estado del sistema ni conocimiento del proyecto en que estás trabajando; depende completamente del contexto que se le proporcione en cada interacción.

En entornos de desarrollo, el contexto puede adoptar muchas formas: archivos de código fuente como un .js, .py o .ts, descripciones funcionales extraídas desde una historia de usuario, definiciones de contratos API (como OpenAPI o GraphQL), documentación técnica, convenciones internas de estilo, logs de errores o incluso conversaciones anteriores con el equipo. La clave está en seleccionar el subconjunto de información que sea relevante, precisa y lo suficientemente acotada para que el modelo tenga las pistas correctas sin distraerse con datos superfluos.

Una forma simple de entenderlo es retomando la analogía del chef. Si el modelo es el chef, el contexto son los ingredientes que se colocan sobre la mesa. Si pides una pasta con salsa blanca pero sólo le entregas arroz, ajo y carne molida, el chef hará lo que pueda, pero probablemente no será lo que esperabas. De igual manera, si solicitas al modelo que documente una función, pero no le das el archivo donde se define esa función ni las reglas de documentación esperadas, la respuesta será genérica, incompleta o incorrecta.

La calidad del contexto determina en gran parte la calidad de la respuesta del modelo. Un contexto bien curado guía al modelo hacia soluciones precisas, contextualizadas y alineadas con el estilo del equipo. Por el contrario, un contexto ambiguo, extenso o mal estructurado puede llevar al modelo a generar resultados poco útiles o directamente erróneos.

Desde el punto de vista técnico, es fundamental tener en cuenta los límites de tokens del modelo utilizado. Cada modelo tiene una capacidad máxima de procesamiento, conocida como "ventana de contexto", que suele estar entre los 4.000 y los 128.000 tokens, dependiendo del proveedor y del modelo en cuestión. Superar ese límite significa que parte de la información será descartada o truncada, muchas veces sin advertencia clara. Por eso, construir el contexto implica no solo recopilar datos, sino priorizarlos y organizarlos de forma estratégica.

En aplicaciones avanzadas, el contexto no se construye manualmente, sino que se genera dinámicamente a partir del estado del sistema, consultas al repositorio, búsquedas semánticas en bases vectoriales, o extracción de fragmentos relevantes desde bases documentales. Este proceso se conoce como context injection o retrieval augmented generation (RAG) y es uno de los pilares del uso moderno de IA aplicada a software.

En resumen, el contexto en MCP no es un accesorio opcional: es una pieza clave del rompecabezas. Un modelo sin contexto es como un chef en una cocina vacía. Solo cuando se le entrega la información adecuada puede ejecutar su tarea de forma eficaz, eficiente y alineada con lo que el equipo realmente necesita.

Ejemplo técnico

Archivo: authService.js

function loginUser(email, password) {
  const user = findUserByEmail(email);
  if (!user) throw new Error("User not found");
  // ...
}
  

Este fragmento puede ser el contexto que acompañará al prompt: "Genera pruebas unitarias para loginUser usando Jest."

Prompt: la instrucción específica

El prompt es el componente más visible de la interacción con un modelo de lenguaje, pero no por eso el más simple. Representa la instrucción directa, explícita y detallada que se le entrega al modelo para que realice una tarea específica. En el contexto del enfoque MCP, el prompt es mucho más que una frase: es un diseño consciente de comunicación entre humano y máquina, con objetivos claros, restricciones técnicas y expectativas de resultado.

En el desarrollo de software, los prompts pueden adoptar muchas formas: solicitar la generación de una función, pedir una refactorización bajo ciertos patrones, requerir la documentación de un módulo, generar un conjunto de pruebas unitarias, detectar vulnerabilidades de seguridad o incluso sugerir mejoras en la experiencia de usuario. El poder del modelo radica en gran parte en la calidad y precisión de la instrucción que recibe. Un prompt débil, ambiguo o mal redactado suele producir resultados insatisfactorios, sin importar cuán avanzado sea el modelo.

Siguiendo la analogía del chef: el prompt es la receta o el pedido que haces. Puedes tener los mejores ingredientes (contexto) y el mejor chef del mundo (modelo), pero si solo dices “hazme algo rico”, corres el riesgo de recibir cualquier cosa. En cambio, si le pides “haz una pasta Alfredo con crema, mantequilla, ajo y queso parmesano”, las probabilidades de obtener lo que esperas son mucho más altas. Así ocurre también con los modelos de lenguaje: cuanto más claro y específico seas, más útil y alineada será la respuesta.

Desde una perspectiva técnica, diseñar buenos prompts implica tener claridad sobre la tarea, comprender cómo interpreta el modelo el lenguaje natural, y aplicar principios como prompt chaining (encadenamiento de instrucciones), few-shot prompting (ejemplos incluidos), o instrucciones estructuradas (usando listas, markdown o bloques de código para guiar al modelo).

Por ejemplo, un prompt como:

“Refactoriza este código”

Es demasiado genérico. En cambio, un prompt como:

“Refactoriza esta función aplicando el patrón Singleton, conservando compatibilidad con Node.js 18 y asegurando que se mantengan los tests existentes sin cambios.”

Es mucho más claro, reduce la ambigüedad y le da al modelo una guía precisa sobre qué se espera y bajo qué restricciones.

El diseño de prompts también puede y debe ser versionado como parte del flujo MCP. Un mismo prompt puede tener variantes para ambientes distintos (por ejemplo, desarrollo vs producción), puede evolucionar con el proyecto, o incluso formar parte de una biblioteca interna de prompts curados y certificados por el equipo técnico.

Además, los prompts pueden ser generados dinámicamente. En sistemas avanzados, es posible usar parámetros, plantillas y condiciones que ajusten la instrucción según el contexto actual. Esto permite construir asistentes inteligentes que se adaptan automáticamente a cada situación, sin requerir intervención humana constante.

En definitiva, el prompt es el punto de articulación entre lo que el equipo necesita y lo que el modelo puede ofrecer. Es el puente entre intención y ejecución. Dominar su diseño es esencial para que el enfoque MCP sea efectivo, predecible y escalable en entornos técnicos reales.

Ejemplo técnico

Prompt:
"Escribe las pruebas unitarias para la función loginUser del archivo authService.js usando Jest.
Asegúrate de incluir los casos cuando el usuario no existe y cuando la contraseña es incorrecta."
  

Consejo técnico

Evita prompts ambiguos. Sé específico, directo y estructurado. Puedes usar listas, ejemplos o plantillas dentro del prompt para mejorar la precisión.

Cómo se ve todo junto: caso completo de MCP

Modelo: GPT-4

Contexto:
- Archivo: authService.js (contiene la lógica de login)
- Archivo: securityRules.md (documenta cómo manejar errores de autenticación)

Prompt:
"Genera pruebas unitarias para la función loginUser, validando:
1. Usuario inexistente
2. Contraseña incorrecta
3. Inicio de sesión correcto
Usa Jest y sigue las reglas de manejo de errores definidas en securityRules.md"
  

Este ejemplo muestra cómo el modelo, el contexto y el prompt trabajan juntos para producir un resultado preciso y alineado con los requerimientos del proyecto.

Conclusión

El enfoque MCP no es complejo una vez entendido. Al separar los elementos clave de la interacción con IA, se gana claridad, control y capacidad de escalar el uso de inteligencia artificial en el desarrollo de software. Para cualquier equipo técnico que desee trabajar de manera profesional con LLMs, entender y aplicar MCP es el primer gran paso.