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

Um catálogo de modelos MCP para agentes de programação é uma lista estruturada e consultável de modelos disponíveis que um agente pode ler através do Model Context Protocol, em vez de depender de nomes de modelos codificados diretamente no código-fonte. Ele permite que um agente, um plugin de IDE ou uma camada de orquestração selecione um modelo em tempo de execução com base no tipo de tarefa, janela de contexto ou limite de custo, em vez de uma string que um desenvolvedor digitou há seis meses e esqueceu de atualizar.

Isso é mais importante do que parece. Agentes de programação chamam modelos constantemente, para autocompletar, refatorações de múltiplos arquivos, geração de testes e redação de mensagens de commit. Cada uma dessas tarefas possui um modelo ideal diferente. Se o agente não consegue descobrir quais modelos existem e para que servem, alguém precisa continuar editando um arquivo de configuração toda vez que um provedor lança uma nova versão. Este artigo percorre o que uma entrada de catálogo de modelos deve conter, como as solicitações estilo MCP para esse catálogo são estruturadas e como decidir quais modelos direcionar para quais tarefas de programação.

Principais Pontos

• Um catálogo de modelos transforma a seleção de modelos de uma string codificada 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 direcionar diferentes tipos de tarefas (autocompletar, refatoração, geração de testes, revisão) para modelos diferentes, em vez de usar um único modelo para tudo.
• As solicitações MCP para dados de catálogo de modelos geralmente seguem um formato de listagem de recursos ou chamada de ferramenta; o esquema exato deve ser verificado na documentação do próprio provedor antes de você desenvolver com base nele.
• A TokenLab publica um Model Data Center em /models/data e um diretório de modelos em /models; trate-os como o local para verificar os nomes atuais dos modelos, e não este artigo, já que as linhas de modelos mudam frequentemente.

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

A maioria das integrações de agentes de programação ainda funciona da maneira que as integrações de API funcionavam há uma década: 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 que a equipe não tem um processo para adotar.

Um catálogo legível por máquina altera o modo de falha. Em vez de um agente quebrar silenciosamente quando um modelo é aposentado, ele pode consultar um 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 realizar manualmente o benchmarking de cada novo lançamento, o agente (ou a ferramenta do desenvolvedor) pode comparar janelas de contexto listadas, suporte a modalidades e campos de custo antes de alternar.

Este também é um pré-requisito para qualquer estratégia séria de roteamento de modelos. Se você deseja enviar conclusões de alto volume e baixo custo para um modelo de baixo custo como o DeepSeek V4 Flash ou o Gemini 3.5 Flash, e reservar um modelo mais forte como o Claude Sonnet 5 para refatorações de múltiplos arquivos, a lógica de roteamento precisa de uma fonte de verdade sobre quais modelos estã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.

A TokenLab escreveu sobre esse problema diretamente no contexto de tornar as informações do modelo algo em que um agente possa confiar, em vez de algo que um humano precise verificar novamente manualmente. Veja agent-readable model truth para o argumento mais amplo sobre a verdade de modelos legível por agentes, e agent-first API para como o design de API muda quando o chamador principal é um agente em vez de um desenvolvedor humano.

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, desenvolvedores que constroem ou consomem um 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 o Kimi K2.7 Code com modelos de imagem como o 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: precificação de tokens de entrada e saída, idealmente separados, já que agentes de programação frequentemente possuem 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 quebras silenciosas.
• Tags de adequação de tarefa: metadados opcionais, mas úteis, como "programação", "roteamento de baixo custo" 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 cada provedor. Antes de construir uma integração, verifique o esquema real documentado no provedor que você está usando. Para modelos servidos especificamente pela TokenLab, o conjunto de campos atual e a cadência de atualização devem ser verificados em /models/data em vez de assumidos a partir deste artigo, já que 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 recursos de modelos disponíveis pode enviar uma solicitação estruturada como esta. Este exemplo é ilustrativo do padrão geral de listagem de recursos do MCP e 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 contra ele.

{
  "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 existem aqui para mostrar a forma de uma solicitação e resposta, não para declarar preços ou números de capacidade. Sempre obtenha esses números na documentação atual do próprio provedor ou em /models/data no momento em que você construir.

Escolhendo Modelos por Tarefa: Um Checklist 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 na documentação do provedor e em /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	Forte raciocínio, 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 open-weight (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

Um checklist prático 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?
3. Você pode definir um limite 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 limitada por taxa?
5. Você está verificando o catálogo novamente 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 Model Data Center em /models/data e um diretório de modelos em /models, ambos observados em 14/07/2026. Estas são as superfícies para verificar as listagens de modelos atuais, em vez de confiar em qualquer artigo estático, já que 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.

Se você está construindo um agente de programação que precisa rotear entre modelos como 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, o padrão prático é tratar o identificador do modelo como uma variável resolvida no momento da solicitação contra um catálogo, não uma constante compilada no código-fonte do seu agente. Comece revisando as listagens atuais em /models/data e confirmando o formato de solicitação que seu cliente MCP precisa contra a documentação da API da TokenLab antes de conectar a lógica de roteamento em produção.

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, exponha todos os campos descritos acima (janela de contexto, campos de custo, status, tags de tarefa) exatamente nesta forma. Esquemas, nomes de campos e modelos disponíveis mudam frequentemente. Trate os exemplos em 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 dos modelos, preços e janelas de contexto na documentação atual do provedor e em /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ço, 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á 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 único modelo 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 modelos permanentemente, e verifique /models/data ou a documentação do seu provedor em um cronograma regular.