El Model Context Protocol (MCP) se ha lanzado como un estándar concreto para convertir los modelos de lenguaje extensos (LLM) en agentes capaces de llamar a herramientas externas en un bucle medible y seguro. Al definir un "enchufe" compartido entre cualquier host compatible con MCP y cualquier servidor MCP, el protocolo permite a los desarrolladores reemplazar el código ad-hoc por un flujo de trabajo predecible y auditable.

Por qué los LLM necesitan un protocolo

Un LLM solo predice el siguiente token de texto a partir de sus datos de entrenamiento. No puede obtener hechos recientes, escribir en una base de datos o activar una API externa sin lógica adicional. Los desarrolladores han creado "agentes" que envuelven un modelo en un bucle: el modelo solicita una herramienta, la herramienta se ejecuta, el resultado se devuelve al modelo y este decide si continuar o responder al usuario.

Ese bucle funciona, pero sin un conjunto común de reglas es fácil crear procesos descontrolados o exponer un sistema a llamadas no deseadas. Cada nueva herramienta requería una integración personalizada, lo que dificultaba el seguimiento del uso de tokens, los límites de presupuesto o las políticas de seguridad en distintos proyectos.

MCP llena esos vacíos codificando la estructura del bucle y los datos que deben circular a través de él.

La anatomía de dos partes de un agente MCP

MCP separa un agente en una definición —la plantilla que describe lo que el agente puede hacer— y una instancia —la ejecución concreta de una solicitud de usuario.

Definición del agente (la plantilla)

  • Bucle del host – el orquestador que impulsa el ciclo de pedir-herramienta-leer-decidir.
  • Contexto del sistema – la personalidad e instrucciones de alto nivel que moldean el comportamiento del modelo.
  • Conjunto de servidores MCP – un catálogo de fuentes de herramientas disponibles que el host puede llamar.
  • Política de herramientas – lista explícita de qué herramientas están permitidas para un agente determinado.
  • Selección del LLM – el modelo específico que generará el razonamiento textual.
  • Límites de terminación – número máximo de iteraciones y presupuesto de tokens para evitar bucles infinitos.
  • Contrato de tarea – descripción formal de qué entradas acepta el agente y qué formato de salida devuelve.
  • Estrategia de contexto – reglas sobre cómo se recorta o resume el historial de la conversación para mantenerse dentro de los límites de tokens.

Instancia del agente (la tarea en ejecución)

  • Objetivo – la solicitud del usuario que inicia el bucle.
  • Contexto de trabajo – historial acumulado, incluyendo resultados de herramientas anteriores.
  • Credenciales – tokens o conjuntos de permisos necesarios para invocar las herramientas seleccionadas.
  • Presupuesto consumido – recuento de tokens gastados y pasos realizados hasta el momento.

Estos elementos muestran tanto lo que un agente tiene permitido hacer como lo que está haciendo actualmente.

Cómo cambia MCP el flujo de desarrollo

Antes de MCP, un desarrollador que quisiera que un LLM consultara una API de clima, extrajera una fila de una base de datos y luego redactara un informe, tenía que escribir código de integración a medida para cada endpoint. Ese código a menudo ocultaba las llamadas a las herramientas dentro del prompt del modelo, lo que hacía imposible ver qué solicitud activaba qué respuesta.

Con MCP, el host envía la conversación al modelo, inspecciona cualquier solicitud de herramienta que el modelo genere, ejecuta la herramienta él mismo y luego devuelve el resultado. El código adicional es mínimo, pero la visibilidad es total: cada ida y vuelta y cada token queda registrado.

Esa visibilidad aporta dos beneficios prácticos:

  1. Medición de costes – los desarrolladores pueden comparar un modelo más económico con uno más grande en la misma tarea, viendo exactamente cuántos tokens consume cada iteración.
  2. Auditoría de seguridad – la política de herramientas y las comprobaciones de credenciales ocurren fuera del modelo, evitando que este invoque servicios no autorizados de forma silenciosa.

Qué sigue sin definirse

MCP especifica la forma de la conversación y los metadatos que viajan con ella, pero no dicta cómo se implementa una herramienta internamente.

Qué esperar a continuación

  • Conjuntos de métricas – el próximo artículo de la serie promete una lista de verificación de los números que los desarrolladores deberían rastrear (gasto de tokens, recuento de iteraciones, latencia por herramienta). Esas métricas se convertirán en los controles de salud de facto para cualquier agente basado en MCP.

En resumen

El Model Context Protocol proporciona a los agentes LLM una estructura compartida y auditable que separa lo que un agente puede hacer de lo que está haciendo en cualquier momento. Al convertir las opacas llamadas a herramientas en un bucle transparente, MCP hace que esas mediciones sean posibles.