Catálogo de Modelos MCP para Agentes de Programação: Torne a Escolha de Modelos Legível por Máquina

Um agente de programação que codifica nomes de modelos de forma rígida (hardcoded) eventualmente fará alguém receber um chamado às 2 da manhã. Um catálogo de modelos MCP para agentes de programação altera esse modo de falha. Em vez de uma string enterrada no código-fonte, o agente lê uma lista estruturada de modelos atuais, custos, modalidades e campos de status no momento da solicitação. Mantemos um catálogo semelhante na TokenLab e tratamos o catálogo como a fonte da verdade para o roteamento. Em nosso pipeline, a escolha do modelo é uma consulta, não uma constante.

Por que Agentes de Programação Precisam de Dados de Modelo Legíveis por Máquina

A maioria das integrações de agentes de programação ainda funciona como integrações de API de uma década atrás. Um desenvolvedor escolhe um nome de modelo, cola-o em uma configuração ou variável de ambiente e publica. Isso funciona até que o provedor descontinue o modelo, altere os preços ou lance uma opção melhor. Então, a equipe não tem um processo para adotá-la.

Um catálogo legível por máquina altera o modo de falha. Quando um modelo é aposentado, o agente pode consultar o catálogo, ver que o modelo não existe mais ou está marcado como obsoleto e recorrer a uma alternativa documentada. Em vez de um desenvolvedor comparar manualmente cada novo lançamento, as ferramentas podem comparar janelas de contexto listadas, suporte a modalidades e campos de custo antes de alternar.

Este também é um pré-requisito para um roteamento de modelo sério. Você pode querer conclusões baratas e de alto volume no DeepSeek V4 Flash ou Gemini 3.5 Flash. Você pode reservar o Claude Sonnet 5 para refatorações de múltiplos arquivos. A lógica de roteamento ainda precisa de uma fonte da verdade. Essa fonte deve dizer quais modelos são atuais, quanto custam e o que suportam. Sem isso, as regras de roteamento se degradam da mesma forma que os nomes de modelos codificados rigidamente.

A TokenLab escreveu sobre esse problema diretamente. Veja verdade de modelo legível por agente para o argumento mais amplo, e API focada em agentes para saber como o design de API muda quando o chamador principal é um agente em vez de um desenvolvedor humano.

Principais Conclusões

• Um catálogo de modelos transforma a seleção de modelos de uma string codificada rigidamente em uma consulta em tempo de execução, o que reduz a carga de manutenção quando os provedores lançam novos modelos.
• Agentes de programação se beneficiam ao rotear diferentes tipos de tarefas (autocompletar, refatorar, geração de testes, revisão) para diferentes modelos, em vez de usar um único modelo para tudo.
• Solicitações MCP para dados de catálogo de modelos geralmente seguem um formato de lista de recursos ou chamada de ferramenta; verifique o esquema exato em relação à documentação do próprio provedor antes de construir algo baseado nele.
• A TokenLab publica um Centro de Dados de Modelos em /models/data e um diretório de modelos em /models; trate-os como o local para verificar os nomes de modelos atuais, não este artigo, já que as linhas de modelos mudam frequentemente.

O que Pertence a uma Entrada de Catálogo de Modelos MCP

Uma entrada de catálogo útil para um agente de programação precisa de mais do que apenas um nome de modelo. No mínimo, construtores e consumidores devem esperar ver:

• Identificador do modelo: a string exata que a API espera, já que os provedores frequentemente versionam nomes com precisão (uma incompatibilidade aqui é um dos bugs de integração mais comuns).
• Provedor: qual empresa ou plataforma serve o modelo, relevante quando um catálogo agrega múltiplos provedores.
• Suporte a modalidade: texto, código, imagem ou vídeo. Um catálogo que mistura modelos de programação como Kimi K2.7 Code com modelos de imagem como Nano Banana Pro precisa de um campo que permita ao agente filtrar pelo que ele realmente precisa.
• Janela de contexto: limites de token importam enormemente para agentes de programação que trabalham em grandes repositórios.
• Campos de custo: preços de tokens de entrada e saída, idealmente separados, já que agentes de programação frequentemente têm cargas de trabalho assimétricas com uso intenso de entrada (contexto de arquivo grande, saída de diff pequena).
• Status: atual, obsoleto ou agendado para aposentadoria. Este é o campo que evita falhas silenciosas.
• Tags de adequação de tarefa: metadados opcionais, mas úteis, como 'coding', 'low-cost routing' ou 'open-weight', para que um agente possa filtrar sem conhecer as características de cada modelo com antecedência.

Nenhum desses campos tem garantia de existir no formato de catálogo de todos os provedores. Antes de construir uma integração, verifique o esquema real documentado no provedor que você usa. Para modelos servidos pela TokenLab especificamente, verifique o conjunto de campos atual e a cadência de atualização em /models/data em vez de presumir que eles correspondem a este artigo. Os esquemas de catálogo mudam à medida que novos modelos e modalidades são adicionados.

Exemplo: Solicitando um Catálogo de Modelos via MCP

O MCP geralmente se comunica via JSON-RPC 2.0. Um cliente solicitando que um servidor liste os recursos de modelo disponíveis pode enviar uma solicitação formatada assim. Este exemplo segue o padrão geral de lista de recursos do MCP. Não é uma afirmação sobre o esquema ao vivo de nenhum provedor específico. Confirme os nomes exatos dos métodos e os campos de resposta em https://docs.tokenlab.sh ou na documentação do seu próprio servidor MCP antes de escrever código de produção baseado nele.

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

Um formato de resposta plausível, novamente ilustrativo em vez de um 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"]
      }
    ]
  }
}

Não trate os valores da janela de contexto, nomes exatos de campos ou os modelos específicos listados acima como fatos confirmados sobre qualquer API ao vivo. Eles mostram o formato de uma solicitação e resposta, não preços ou números de capacidade. Obtenha esses números na documentação atual do provedor ou em /models/data quando for construir.

Escolhendo Modelos por Tarefa: Uma Lista de Verificação de Decisão

Um catálogo de modelos só é útil se o agente ou o desenvolvedor que configura o agente tiver uma regra para combinar o tipo de tarefa com o modelo. A tabela abaixo é uma estrutura inicial, não um resultado de benchmark. Verifique os preços atuais e as alegações de capacidade em relação à documentação do provedor e /models antes de se comprometer com uma regra de roteamento em produção.

Tarefa do agente de programação	O que mais importa	Exemplos de modelos para avaliar
Autocompletar / sugestões inline	Baixa latência, baixo custo por chamada	DeepSeek V4 Flash, Gemini 3.5 Flash, Laguna XS 2.1
Refatoração de múltiplos arquivos	Janela de contexto maior, forte raciocínio de código	Claude Sonnet 5, DeepSeek V4 Pro
Geração de testes	Formatação consistente, raciocínio moderado	Kimi K2.7 Code, Claude Sonnet 5
Revisão de código / resumo de PR	Raciocínio forte, capacidade de referenciar diffs com precisão	Claude Sonnet 5, Gemini 3.5 Flash
Tarefas em lote de alto volume (linting, comentários de doc)	Custo por token acima da capacidade bruta	GLM-5.2, Qwen3.7 Plus, MiniMax M3
Requisito de peso aberto (auto-hospedagem ou restrições de licença)	Pesos abertos, implantável fora de uma API gerenciada	GLM-5.2, DeepSeek V4 Pro, DeepSeek V4 Flash, Qwen3.7 Plus, Kimi K2.7 Code

Uma lista de verificação prática para construir a própria lógica de roteamento:

1. A entrada do catálogo inclui um campo de status, para que você possa detectar a descontinuação antes que uma chamada falhe?
2. O catálogo separa modelos capazes de programar de modelos gerais de texto ou imagem, para que a filtragem não exija listas codificadas rigidamente?
3. Você pode definir um teto de custo por tipo de tarefa e fazer com que o agente selecione o modelo mais barato que o atenda, em vez de sempre usar como padrão a opção mais capaz (e mais cara)?
4. Existe um modelo de fallback definido para cada categoria de tarefa, caso a escolha principal esteja indisponível ou com limite de taxa?
5. Você está verificando novamente o catálogo em um cronograma, não apenas na primeira integração, já que as linhas de modelos mudam com o tempo?

Onde a TokenLab se Encaixa neste Fluxo de Trabalho

A TokenLab mantém um Centro de Dados de Modelos em /models/data e um diretório de modelos em /models, ambos observados em 14/07/2026. Verifique essas superfícies para listagens de modelos atuais em vez de confiar em qualquer artigo estático. Catálogos de modelos são inerentemente sensíveis ao tempo. A documentação da API da TokenLab em https://docs.tokenlab.sh é o local para verificar os esquemas exatos de solicitação e resposta antes de integrar.

Você pode construir um agente de programação que roteia entre vários modelos. Use o Claude Sonnet 5 para tarefas de revisão, o DeepSeek V4 Flash para conclusões baratas de alto volume e o Kimi K2.7 Code para geração de testes. Trate o identificador do modelo como uma variável. Resolva-o no momento da solicitação em relação a um catálogo, não como uma constante compilada no código-fonte do seu agente. O passo prático é verificar /models/data e confirmar o formato de solicitação que seu cliente MCP precisa em relação à documentação da API da TokenLab. Conecte a lógica de roteamento em produção apenas após essas verificações.

Limitações

Este artigo descreve um padrão geral para catálogos de modelos MCP e roteamento de agentes de programação. Ele não confirma que nenhum provedor específico, incluindo a TokenLab, expõe todos os campos descritos acima (janela de contexto, campos de custo, status, tags de tarefa) exatamente neste formato. Esquemas, nomes de campos e modelos disponíveis mudam frequentemente. Trate os exemplos JSON neste artigo como ilustrativos do padrão geral de solicitação e resposta do MCP, não como um esquema verificado para qualquer endpoint ao vivo. Antes de publicar, confirme os identificadores exatos de modelos, preços e janelas de contexto em relação à documentação atual do provedor e em relação a /models/data.

FAQ

O próprio MCP define um esquema de catálogo de modelos padrão?

O MCP define padrões gerais para recursos e ferramentas via JSON-RPC, mas os campos exatos em um catálogo de modelos (preços, janela de contexto, status) dependem de como o servidor que implementa o MCP escolhe expor esses dados. Verifique o esquema específico com o servidor ou provedor com o qual você está se integrando.

Um agente de programação deve sempre usar o modelo mais capaz disponível?

Não necessariamente. Tarefas como autocompletar são sensíveis à latência e ao custo, enquanto refatorações de múltiplos arquivos se beneficiam de um raciocínio mais forte e um contexto maior. Um catálogo com tags de tarefa e campos de custo permite que você roteie por tarefa em vez de usar um modelo padrão para tudo.

Com que frequência devo verificar novamente o catálogo de modelos do qual meu agente depende?

As linhas de modelos mudam com frequência suficiente para que uma integração única não seja suficiente. Construa sua lógica de roteamento para consultar o catálogo em vez de armazenar identificadores de modelo permanentemente, e verifique /models/data ou a documentação do seu provedor em um cronograma regular.

Comece revisando as listagens atuais em /models/data e confirmando o formato de solicitação que seu cliente MCP precisa em relação à documentação da API da TokenLab antes de conectar a lógica de roteamento em produção.