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

Un agente de programación que codifica nombres de modelos de forma rígida eventualmente despertará a alguien a las 2 a.m. Un catálogo de modelos MCP para agentes de programación cambia ese modo de fallo. En lugar de una cadena de texto enterrada en el código fuente, el agente lee una lista estructurada de modelos actuales, costos, modalidades y campos de estado en el momento de la solicitud. Mantenemos un catálogo similar en TokenLab y lo tratamos como la fuente de verdad para el enrutamiento. En nuestro pipeline, la elección del modelo es una búsqueda, no una constante.

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 todavía funcionan como las integraciones de API de 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 retira el modelo, cambia los precios o lanza una opción mejor. Entonces, el equipo no tiene un proceso para adoptarlo.

Un catálogo legible por máquina cambia el modo de fallo. Cuando un modelo se retira, el agente puede consultar el catálogo, ver que el modelo ya no está disponible o está marcado como obsoleto, y recurrir a una alternativa documentada. En lugar de que un desarrollador realice evaluaciones comparativas manualmente de cada nuevo lanzamiento, las herramientas pueden comparar las ventanas de contexto enumeradas, el soporte de modalidades y los campos de costo antes de realizar el cambio.

Esto también es un requisito previo para un enrutamiento de modelos serio. Es posible que desee completaciones económicas y de alto volumen en DeepSeek V4 Flash o Gemini 3.5 Flash. Puede reservar Claude Sonnet 5 para refactorizaciones de múltiples archivos. La lógica de enrutamiento aún necesita una fuente de verdad. Esa fuente debe decir qué modelos están vigentes, cuánto cuestan y qué admiten. Sin ella, las reglas de enrutamiento se degradan de la misma manera que los nombres de modelos codificados de forma rígida.

TokenLab ha escrito sobre este problema directamente. Consulte agent-readable model truth para conocer el argumento más amplio, 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.

Conclusiones clave

• Un catálogo de modelos convierte la selección de modelos de una cadena codificada de forma rígida en 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 al enrutar 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 herramienta; verifique el esquema exacto con la documentación del propio proveedor antes de desarrollar sobre él.
• TokenLab publica un Centro de Datos de Modelos en /models/data y un directorio de modelos en /models; trátelos como el lugar para verificar los nombres de modelos actuales, no este artículo, ya que las alineaciones de modelos cambian con frecuencia.

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 y consumidores 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 video. Un catálogo que mezcla 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 extremadamente importantes para los agentes de programación que trabajan en repositorios grandes.
• Campos de costo: precios de tokens de entrada y salida, idealmente separados, ya que los agentes de programación suelen tener cargas de trabajo asimétricas con mucha entrada (contexto de archivos grandes, salida de diff pequeña).
• Estado: actual, obsoleto o programado para su retiro. Este es el campo que evita fallos silenciosos.
• Etiquetas de idoneidad de tareas: metadatos opcionales pero útiles como 'coding', 'low-cost routing' o 'open-weight', para que un agente pueda filtrar sin conocer las características de cada modelo de antemano.

No se garantiza que todos estos campos existan en el formato de catálogo de cada proveedor. Antes de crear una integración, verifique el esquema real documentado por el proveedor que utiliza. Para los modelos servidos por TokenLab específicamente, verifique el conjunto de campos actual y la cadencia de actualización en /models/data en lugar de asumir que coinciden con este artículo. Los esquemas de catálogo cambian a medida que se agregan nuevos modelos y modalidades.

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

MCP generalmente se comunica 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 sigue el patrón general de lista de recursos de MCP. No es una afirmació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 para él.

{
  "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. Muestran la forma de una solicitud y respuesta, no precios o números de capacidad. Obtenga esos números de la documentación actual del proveedor o de /models/data cuando realice la implementació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 tabla a continuación 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 costo 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 de referenciar diffs con precisión	Claude Sonnet 5, Gemini 3.5 Flash
Tareas por lotes de alto volumen (linting, comentarios de documentos)	Costo 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 de forma rígida?
3. ¿Puede establecer un límite de costo 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 velocidad?
5. ¿Está volviendo a verificar 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 Centro de Datos de Modelos en /models/data y un directorio de modelos en /models, ambos observados al 14-07-2026. Consulte estas superficies para obtener listados de modelos actuales en lugar de confiar en cualquier artículo estático. 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.

Puede crear un agente de programación que enrute entre varios modelos. Use Claude Sonnet 5 para tareas de revisión, DeepSeek V4 Flash para completaciones económicas de alto volumen y Kimi K2.7 Code para la generación de pruebas. Trate el identificador del modelo como una variable. Resuélvalo en el momento de la solicitud contra un catálogo, no como una constante compilada en el código fuente de su agente. El paso práctico es verificar /models/data y confirmar la forma de solicitud que necesita su cliente MCP contra la documentación de la API de TokenLab. Conecte la lógica de enrutamiento en producción solo después de esas verificaciones.

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 costo, estado, etiquetas de tarea) exactamente en esta forma. Los esquemas, los nombres de campo y los modelos disponibles cambian con frecuencia. Trate los ejemplos JSON en 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 usar siempre el modelo más capaz disponible?

No necesariamente. Tareas como el autocompletado son sensibles a la latencia y al costo, mientras que las refactorizaciones de múltiples archivos se benefician de un razonamiento más fuerte y un contexto más amplio. Un catálogo con etiquetas de tarea y campos de costo le permite enrutar por tarea en lugar de recurrir a un solo modelo para todo.

¿Con qué frecuencia debo volver a verificar el catálogo de modelos del que depende mi agente?

Las alineaciones de modelos cambian con la frecuencia 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 verifique /models/data o la documentación de su proveedor de forma regular.

Comience revisando los listados actuales en /models/data y confirmando la forma de solicitud que necesita su cliente MCP contra la documentación de la API de TokenLab antes de conectar la lógica de enrutamiento en producción.