Catálogo de modelos MCP para agentes de programación: haga que la elección del modelo sea legible por máquina

Un catálogo de modelos MCP para agentes de programación es una lista estructurada y consultable de modelos disponibles que un agente puede leer a través del Model Context Protocol en lugar de depender de nombres de modelos codificados en el código fuente. Permite que un agente, un plugin de IDE o una capa de orquestación seleccione un modelo en tiempo de ejecución basándose en el tipo de tarea, la ventana de contexto o el límite de costes, en lugar de una cadena de texto que un desarrollador escribió hace seis meses y olvidó actualizar.

Esto es más importante de lo que parece. Los agentes de programación llaman a los modelos constantemente: para autocompletado, refactorizaciones de múltiples archivos, generación de pruebas y redacción de mensajes de confirmación (commit). Cada una de estas tareas tiene un modelo ideal diferente. Si el agente no puede descubrir qué modelos existen y para qué son buenos, alguien tiene que seguir editando un archivo de configuración cada vez que un proveedor lanza una nueva versión. Este artículo explica qué debe contener una entrada de catálogo de modelos, cómo se estructuran las solicitudes de estilo MCP para dicho catálogo y cómo decidir qué modelos asignar a qué tareas de programación.

Puntos clave

• Un catálogo de modelos convierte la selección de modelos de una cadena codificada a una búsqueda en tiempo de ejecución, lo que reduce la carga de mantenimiento cuando los proveedores lanzan nuevos modelos.
• Los agentes de programación se benefician de asignar diferentes tipos de tareas (autocompletado, refactorización, generación de pruebas, revisión) a diferentes modelos en lugar de usar un solo modelo para todo.
• Las solicitudes MCP para datos de catálogos de modelos suelen seguir una estructura de lista de recursos o llamada a herramientas; el esquema exacto debe verificarse con la propia documentación del proveedor antes de desarrollar sobre él.
• TokenLab publica un Model Data Center en /models/data y un directorio de modelos en /models; considérelos como el lugar para verificar los nombres actuales de los modelos, no este artículo, ya que las alineaciones de modelos cambian con frecuencia.

Por qué los agentes de programación necesitan datos de modelos legibles por máquina

La mayoría de las integraciones de agentes de programación siguen funcionando como funcionaban las integraciones de API hace una década: un desarrollador elige un nombre de modelo, lo pega en una configuración o variable de entorno y lo despliega. Eso funciona hasta que el proveedor deja de dar soporte al modelo, cambia los precios o lanza una opción mejor para la cual el equipo no tiene un proceso de adopción.

Un catálogo legible por máquina cambia el modo de fallo. En lugar de que un agente falle silenciosamente cuando se retira un modelo, puede consultar un catálogo, ver que el modelo ya no existe o está marcado como obsoleto y recurrir a una alternativa documentada. En lugar de que un desarrollador realice manualmente pruebas comparativas (benchmarking) de cada nueva versión, el agente (o las herramientas del desarrollador) puede comparar las ventanas de contexto listadas, el soporte de modalidades y los campos de coste antes de realizar el cambio.

Este es también un requisito previo para cualquier estrategia seria de enrutamiento de modelos. Si desea enviar completaciones de gran volumen y bajo coste a un modelo económico como DeepSeek V4 Flash o Gemini 3.5 Flash, y reservar un modelo más potente como Claude Sonnet 5 para refactorizaciones de múltiples archivos, la lógica de enrutamiento necesita una fuente de verdad sobre qué modelos están vigentes, cuánto cuestan y qué soportan. Sin eso, las reglas de enrutamiento se degradan de la misma manera que los nombres de modelos codificados.

TokenLab ha escrito sobre este problema directamente en el contexto de hacer que la información del modelo sea algo en lo que un agente pueda confiar, en lugar de algo que un humano tenga que verificar manualmente. Consulte agent-readable model truth para conocer el argumento más amplio sobre la verdad del modelo legible por agentes, y agent-first API para ver cómo cambia el diseño de la API cuando el llamador principal es un agente en lugar de un desarrollador humano.

Qué debe incluir una entrada de catálogo de modelos MCP

Una entrada de catálogo útil para un agente de programación necesita más que un nombre de modelo. Como mínimo, los desarrolladores que construyen o consumen uno deberían esperar ver:

• Identificador del modelo: la cadena exacta que espera la API, ya que los proveedores a menudo versionan los nombres con precisión (una discrepancia aquí es uno de los errores de integración más comunes).
• Proveedor: qué empresa o plataforma sirve el modelo, relevante cuando un catálogo agrega múltiples proveedores.
• Soporte de modalidad: texto, código, imagen o vídeo. Un catálogo que mezcle modelos de programación como Kimi K2.7 Code con modelos de imagen como Nano Banana Pro necesita un campo que permita al agente filtrar por lo que realmente necesita.
• Ventana de contexto: los límites de tokens son enormemente importantes para los agentes de programación que trabajan en repositorios grandes.
• Campos de coste: precios de tokens de entrada y salida, idealmente separados, ya que los agentes de programación a menudo tienen cargas de trabajo asimétricas con mucha entrada (contexto de archivo grande, salida de diff pequeña).
• Estado: actual, obsoleto o programado para su retirada. Este es el campo que evita fallos silenciosos.
• Etiquetas de idoneidad de tareas: metadatos opcionales pero útiles como "programación", "enrutamiento de bajo coste" o "pesos abiertos" (open-weight), para que un agente pueda filtrar sin conocer las características de cada modelo de antemano.

Ninguno de estos campos está garantizado en el formato de catálogo de todos los proveedores. Antes de crear una integración, verifique el esquema real documentado en el proveedor que esté utilizando. Específicamente para los modelos servidos por TokenLab, el conjunto de campos actual y la cadencia de actualización deben verificarse en /models/data en lugar de asumirse a partir de este artículo, ya que los esquemas de catálogo cambian a medida que se añaden nuevos modelos y modalidades.

Ejemplo: Solicitud de un catálogo de modelos a través de MCP

MCP suele comunicarse a través de JSON-RPC 2.0. Un cliente que solicita a un servidor que enumere los recursos de modelos disponibles podría enviar una solicitud con esta forma. Este ejemplo ilustra el patrón general de lista de recursos de MCP y no es una declaración sobre el esquema en vivo de ningún proveedor específico; confirme los nombres de métodos exactos y los campos de respuesta en https://docs.tokenlab.sh o en la documentación de su propio servidor MCP antes de escribir código de producción.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "resources/list",
  "params": {
    "filter": {
      "modality": "text",
      "tag": "coding"
    }
  }
}

Una forma de respuesta plausible, nuevamente ilustrativa en lugar de un esquema verificado:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "resources": [
      {
        "id": "claude-sonnet-5",
        "provider": "Anthropic",
        "modality": ["text", "code"],
        "context_window": "verify at provider docs",
        "status": "current",
        "tags": ["coding", "review"]
      },
      {
        "id": "deepseek-v4-flash",
        "provider": "DeepSeek",
        "modality": ["text", "code"],
        "context_window": "verify at provider docs",
        "status": "current",
        "tags": ["low-cost", "coding"]
      }
    ]
  }
}

No trate los valores de la ventana de contexto, los nombres de campo exactos o los modelos específicos enumerados anteriormente como hechos confirmados sobre ninguna API en vivo. Existen aquí para mostrar la forma de una solicitud y respuesta, no para indicar precios o números de capacidad. Obtenga siempre esos números de la documentación actual del proveedor o de /models/data en el momento en que realice la integración.

Elección de modelos por tarea: una lista de verificación de decisiones

Un catálogo de modelos solo es útil si el agente (o el desarrollador que configura el agente) tiene una regla para hacer coincidir el tipo de tarea con el modelo. La siguiente tabla es un marco de trabajo inicial, no un resultado de referencia. Verifique los precios actuales y las afirmaciones de capacidad con la documentación del proveedor y /models antes de comprometerse con una regla de enrutamiento en producción.

Tarea del agente de programación	Lo que más importa	Ejemplos de modelos a evaluar
Autocompletado / sugerencias en línea	Baja latencia, bajo coste por llamada	DeepSeek V4 Flash, Gemini 3.5 Flash, Laguna XS 2.1
Refactorización de múltiples archivos	Ventana de contexto más grande, razonamiento de código sólido	Claude Sonnet 5, DeepSeek V4 Pro
Generación de pruebas	Formato consistente, razonamiento moderado	Kimi K2.7 Code, Claude Sonnet 5
Revisión de código / resumen de PR	Razonamiento sólido, capacidad para referenciar diffs con precisión	Claude Sonnet 5, Gemini 3.5 Flash
Tareas por lotes de alto volumen (linting, comentarios de documentos)	Coste por token sobre capacidad bruta	GLM-5.2, Qwen3.7 Plus, MiniMax M3
Requisito de pesos abiertos (autoalojamiento o restricciones de licencia)	Pesos abiertos, desplegable fuera de una API gestionada	GLM-5.2, DeepSeek V4 Pro, DeepSeek V4 Flash, Qwen3.7 Plus, Kimi K2.7 Code

Una lista de verificación práctica para construir la lógica de enrutamiento en sí:

1. ¿La entrada del catálogo incluye un campo de estado, para que pueda detectar la obsolescencia antes de que falle una llamada?
2. ¿El catálogo separa los modelos capaces de programar de los modelos generales de texto o imagen, para que el filtrado no requiera listas codificadas?
3. ¿Puede establecer un límite de costes por tipo de tarea y hacer que el agente seleccione el modelo más barato que lo cumpla, en lugar de recurrir siempre a la opción más capaz (y más cara)?
4. ¿Existe un modelo de respaldo definido para cada categoría de tarea, en caso de que la opción principal no esté disponible o tenga límites de tasa?
5. ¿Está volviendo a consultar el catálogo de forma programada, no solo en la primera integración, ya que las alineaciones de modelos cambian con el tiempo?

Dónde encaja TokenLab en este flujo de trabajo

TokenLab mantiene un Model Data Center en /models/data y un directorio de modelos en /models, ambos observados a fecha de 2026-07-14. Estas son las superficies que debe consultar para obtener los listados de modelos actuales, en lugar de confiar en cualquier artículo estático, ya que los catálogos de modelos son intrínsecamente sensibles al tiempo. La documentación de la API de TokenLab en https://docs.tokenlab.sh es el lugar para verificar los esquemas exactos de solicitud y respuesta antes de integrar.

Si está creando un agente de programación que necesita enrutar entre modelos como Claude Sonnet 5 para tareas de revisión, DeepSeek V4 Flash para completaciones baratas de gran volumen y Kimi K2.7 Code para la generación de pruebas, el patrón práctico es tratar el identificador del modelo como una variable resuelta en el momento de la solicitud frente a un catálogo, no como una constante compilada en el código fuente de su agente. Empiece revisando los listados actuales en /models/data y confirmando la forma de solicitud que necesita su cliente MCP frente a la documentación de la API de TokenLab antes de integrar la lógica de enrutamiento en producción.

Limitaciones

Este artículo describe un patrón general para catálogos de modelos MCP y enrutamiento de agentes de programación. No confirma que ningún proveedor específico, incluido TokenLab, exponga todos los campos descritos anteriormente (ventana de contexto, campos de coste, estado, etiquetas de tarea) exactamente con esta forma. Los esquemas, los nombres de campo y los modelos disponibles cambian con frecuencia. Trate los ejemplos JSON de este artículo como ilustrativos del patrón general de solicitud y respuesta de MCP, no como un esquema verificado para ningún endpoint en vivo. Antes de realizar el despliegue, confirme los identificadores de modelo exactos, los precios y las ventanas de contexto con la documentación actual del proveedor y con /models/data.

Preguntas frecuentes

¿MCP define por sí mismo un esquema de catálogo de modelos estándar? MCP define patrones generales para recursos y herramientas sobre JSON-RPC, pero los campos exactos en un catálogo de modelos (precios, ventana de contexto, estado) dependen de cómo el servidor que implementa MCP elija exponer esos datos. Verifique el esquema específico con el servidor o proveedor con el que se esté integrando.

¿Debería un agente de programación utilizar siempre el modelo más capaz disponible? No necesariamente. Tareas como el autocompletado son sensibles a la latencia y al coste, mientras que las refactorizaciones de múltiples archivos se benefician de un razonamiento más sólido y un contexto más amplio. Un catálogo con etiquetas de tarea y campos de coste le permite enrutar por tarea en lugar de recurrir a un solo modelo para todo.

¿Con qué frecuencia debo volver a consultar el catálogo de modelos del que depende mi agente? Las alineaciones de modelos cambian lo suficiente como para que una integración única no sea suficiente. Construya su lógica de enrutamiento para consultar el catálogo en lugar de almacenar en caché los identificadores de modelo de forma permanente, y consulte /models/data o la documentación de su proveedor de forma regular.