TokenLab para Agentes: Modelos Legíveis por Máquina, Preços, SDKs e MCP

O TokenLab MCP é um servidor de Model Context Protocol (MCP) somente leitura que oferece a um agente de codificação acesso direto e estruturado ao catálogo público de modelos, preços e visão geral da API do TokenLab antes mesmo de ele escrever uma única linha de código de integração. Ele responde a perguntas de descoberta — quais IDs de modelo existem atualmente, quanto custam, qual modalidade suportam — e não realiza chamadas de APIs de inferência pagas em seu nome.

Muitos bugs de integração de agentes não começam na primeira chamada de API — eles começam antes, quando o agente escolhe um ID de modelo de um exemplo obsoleto, de uma memória em cache ou de um tutorial de seis meses atrás, e só descobre a incompatibilidade após um erro 404 ou uma surpresa no preço.

Agentes de codificação escrevem rápido. Eles nem sempre leem primeiro. Junto com o TokenLab MCP, o TokenLab publica um llms.txt compacto, um llms-full.txt mais completo e arquivos JSON de dados de modelos públicos — as mesmas superfícies de catálogo de modelos e preços que você mesmo pode consultar — para que um agente possa verificar os IDs e custos atuais dos modelos antes de codificar qualquer coisa.

Este artigo aborda o que são essas superfícies, o que elas não são e como conectar um agente para usá-las antes de codificar um nome de modelo. Para a referência completa de endpoints, consulte a documentação de integração.

Principais Pontos

• O TokenLab publica visões gerais da API legíveis por agentes em api.tokenlab.sh/llms.txt e llms-full.txt, com o domínio web redirecionando para a mesma fonte.
• Arquivos do Centro de Dados de Modelos Públicos (JSON de catálogo, JSON mais recente, JSON de tendências, markdown de resumo) fornecem aos agentes um snapshot consultável do que o TokenLab oferece atualmente.
• O servidor TokenLab MCP expõe list_models, get_model, get_model_pricing e get_api_overview — e é somente leitura. Ele não faz proxy de inferência paga.
• A documentação pública recomenda que os agentes chamem /v1/models ou leiam llms.txt antes de codificar um nome de modelo, e usem a filtragem recommended_for para tarefas que não sejam de chat, como imagem, vídeo ou embedding.
• Ler os endpoints de modelo e preço antes de tentar novamente uma solicitação de não-chat que falhou evita chamadas repetidas e fracassadas contra a família de modelos errada.

Por que os Agentes Escolhem IDs de Modelos Obsoletos em Primeiro Lugar

Agentes de codificação geram IDs de modelos a partir do que aprenderam durante o treinamento, não do que está disponível atualmente. Esses dados de treinamento têm um corte, então o senso interno do agente sobre "o modelo atual" é fixado no que era verdade quando seus pesos foram atualizados pela última vez. Quando você pede a um agente para chamar uma API de modelo, ele buscará com confiança o ID de que se lembra — mesmo que esse ID tenha sido renomeado, descontinuado ou substituído desde então.

Isso não é um bug no raciocínio do agente; é uma limitação estrutural de qualquer sistema que depende de conhecimento memorizado em vez de uma consulta em tempo real. A solução não é um prompt mais inteligente — é dar ao agente um lugar para verificar antes de escrever o código.

É para isso que existem os arquivos de dados de modelos e a API do TokenLab. Antes de gerar uma solicitação, um agente (ou o humano revisando sua saída) pode consultar um endpoint ao vivo para confirmar se o ID do modelo realmente existe, qual modalidade ele suporta e quanto custa — em vez de confiar em um nome extraído da memória.

Endpoint	Propósito
https://tokenlab.sh/model-data/catalog.json	Catálogo completo de modelos rastreados, estruturado para consulta programática
https://tokenlab.sh/model-data/latest.json	Lista atual de modelos em um formato leve e amigável para agentes
https://tokenlab.sh/en/models	Navegador de modelos legível por humanos
https://tokenlab.sh/en/pricing	Preços atuais por modelo e modalidade

Um post de blog — incluindo este — é um snapshot. Ele reflete o que era verdade quando foi escrito e ficará desatualizado da mesma forma que os dados de treinamento de um agente. Endpoints ao vivo não têm esse problema: eles refletem o que é verdade agora, e é por isso que são a coisa mais segura a verificar antes de enviar o código, não um artigo estático.

O que o TokenLab Expõe para Descoberta de Agentes

A camada llms.txt

https://api.tokenlab.sh/llms.txt é uma visão geral compacta e legível por agentes da API: quais endpoints existem, como é uma solicitação e onde encontrar detalhes mais profundos. Ele foi projetado para ser curto o suficiente para que um agente possa lê-lo em uma única janela de contexto sem gastar um grande orçamento de tokens apenas para se orientar.

https://api.tokenlab.sh/llms-full.txt é a versão mais completa — mais detalhes de endpoint, mais exemplos, mais da área de superfície que um agente precisa antes de gerar uma integração funcional em vez de um rascunho.

Se você acessar o domínio web em vez do host da API, tokenlab.sh/llms.txt e tokenlab.sh/llms-full.txt redirecionam para as mesmas fontes hospedadas na API. Isso é importante para os agentes: qualquer ponto de entrada que eles rastreiem ou busquem, eles chegarão ao mesmo texto canônico, não a duas cópias divergentes.

O Centro de Dados de Modelos

Além da visão geral em texto, o TokenLab publica arquivos JSON estruturados que um agente (ou um script de build) pode extrair diretamente:

• https://tokenlab.sh/model-data/catalog.json — o catálogo de modelos mais completo.
• https://tokenlab.sh/model-data/latest.json — um snapshot orientado para o que é atual agora.
• https://tokenlab.sh/model-data/summary.md — um resumo em markdown legível por humanos e agentes, útil quando você deseja um diff rápido em relação ao que sua base de código codifica atualmente.

Estes são arquivos estáticos e buscáveis. Um agente que constrói um arquivo de configuração, um modelo .env ou um menu suspenso de seleção de modelo pode extrair o JSON diretamente em vez de pedir a um humano para colar uma lista de modelos que estará obsoleta novamente em duas semanas.

O servidor MCP — somente leitura, e vale a pena ser preciso sobre isso

https://github.com/hedging8563/tokenlab-mcp-server é público. Ele expõe quatro ferramentas relevantes para descoberta:

• list_models — enumera o que está disponível, opcionalmente filtrado.
• get_model — extrai detalhes sobre um ID de modelo específico.
• get_model_pricing — extrai os preços atuais para um modelo específico.
• get_api_overview — o equivalente nativo do MCP à leitura de llms.txt.

A restrição importante: este servidor é somente leitura. Ele não chama APIs de inferência pagas em seu nome e não faz proxy de solicitações de geração. Ele responde a perguntas sobre modelos, preços e formato da API. Se o seu agente precisar realmente executar a inferência, ele ainda passará pela API normal do TokenLab com sua própria chave — o servidor MCP é uma camada de descoberta, não uma camada de execução. Confundir os dois é um erro comum que vale a pena evitar explicitamente em qualquer prompt de agente ou arquivo de habilidade que você escrever.

Exemplo de Descoberta com TokenLab MCP

O TokenLab expõe um servidor de Model Context Protocol (MCP) somente leitura que permite aos agentes de codificação descobrir modelos e preços disponíveis sem realizar qualquer inferência. O servidor MCP fornece quatro ferramentas:

• list_models — lista modelos disponíveis, opcionalmente filtrados por recommended_for (por exemplo, image, video, embedding, rerank, translation)
• get_model — recupera detalhes de um modelo específico
• get_model_pricing — recupera informações de preços de um modelo específico
• get_api_overview — recupera um resumo da API do TokenLab

Exemplo: listando modelos via MCP

{
  "tool": "list_models",
  "arguments": {}
}

Exemplo: filtrando modelos por uso recomendado

{
  "tool": "list_models",
  "arguments": {
    "recommended_for": "image"
  }
}

Se você preferir consultar a API diretamente em vez de passar pelo MCP, as chamadas REST equivalentes são:

# Listar todos os modelos
curl https://api.tokenlab.sh/v1/models \
  -H "Authorization: Bearer sk-KEY"

# Listar modelos recomendados para tarefas de imagem
curl "https://api.tokenlab.sh/v1/models?recommended_for=image" \
  -H "Authorization: Bearer sk-KEY"

Observe que o servidor MCP é estritamente somente leitura — ele se destina à descoberta (listar modelos, inspecionar preços e revisar recursos da API) e não realiza nenhuma inferência por si só.

Para instruções de configuração e detalhes de integração, consulte:

• Servidor TokenLab MCP
• Habilidade de Agente de Codificação

O repositório de habilidades

https://github.com/hedging8563/tokenlab-skills empacota esse padrão de descoberta em algo que um framework de agente de codificação pode carregar diretamente — uma definição de habilidade que diz ao agente "leia isso antes de escrever código de integração do TokenLab", em vez de confiar que o agente decidirá independentemente verificar.

O Fluxo de Trabalho Recomendado para Agentes

A documentação pública descreve uma sequência específica, e ela se sustenta bem na prática:

1. Antes de codificar qualquer nome de modelo, chame /v1/models ou leia llms.txt para confirmar se o ID realmente existe agora.
2. Para tarefas que não sejam de chat — imagem, vídeo, música, 3D, TTS, STT, embedding, rerank, tradução — filtre com /v1/models?recommended_for=<task> em vez de assumir que um modelo orientado a chat lida com a tarefa ou adivinhar um nome de modelo de memória.
3. Antes de tentar novamente uma solicitação de não-chat que falhou, leia /v1/models/:model e /v1/models/:model/pricing. Uma solicitação com falha contra um modelo de modalidade errada geralmente falhará novamente na nova tentativa com a mesma entrada; verificar a modalidade e o preço reais do modelo primeiro economiza um loop de nova tentativa.

Essa sequência é importante porque antecipa os dois modos de falha mais comuns: ID de modelo errado e família de modelo errada para a tarefa.

Checklist prático para conectar isso a um agente

Passo	O que verificar	Onde
1	Este ID de modelo ainda resolve?	/v1/models ou llms.txt
2	Esta é a família de modelos certa para a tarefa (chat vs. imagem vs. embedding, etc.)?	/v1/models?recommended_for=<task>
3	Qual é o preço atual de entrada/saída para este modelo?	/v1/models/:model/pricing ou get_model_pricing (MCP)
4	Qual é a janela de contexto e a modalidade?	/v1/models/:model ou get_model (MCP)
5	Existe um modelo mais novo com um nome semelhante que substituiu este?	catalog.json / latest.json
6	O agente leu llms.txt antes de gerar o código de integração?	Confirmar no log de chamadas de ferramentas do agente

Se um agente pula os passos 1 e 2, tudo o que vem a seguir — novas tentativas, tratamento de erros, estimativas de custo — é construído sobre uma suposição em vez de um fato.

Por que isso é Importante Especialmente para Tarefas que não são de Chat

Modelos de chat recebem a maior parte da atenção, mas o filtro recommended_for existe porque tarefas que não são de chat falham de maneiras menos óbvias. Um modelo criado para geração de texto para texto retornando uma resposta malformada para uma solicitação de imagem nem sempre gera um erro limpo e autoexplicativo. Às vezes, ele apenas retorna algo que o agente não sabe como analisar.

Filtrar por recommended_for=image, recommended_for=video, recommended_for=embedding e assim por diante reduz o conjunto de candidatos antes mesmo de o agente escrever um corpo de solicitação. Dada a quantidade de entradas distintas de geração de imagem que podem existir no catálogo de modelos a qualquer momento — nano-banana-2 (Gemini 3.1 Flash Image), nano-banana-pro (Gemini 3 Pro Image), nano-banana-2-lite (Gemini 3.1 Flash Lite Image), openai/gpt-image-2, reve/reve-2.0, microsoft/mai-image-2.5 — adivinhar qual é "o modelo de imagem" de memória é exatamente o modo de falha que este fluxo de trabalho foi projetado para evitar. A geração de vídeo tem seu próprio conjunto de modelos específicos para a tarefa (seedance, veo-3, entre outros) com diferentes preços e formatos de modalidade; a mesma lógica de filtragem se aplica.

Para preços atuais exatos, limites de contexto e modalidade em qualquer modelo específico nomeado aqui, verifique o catálogo de modelos e a página de preços diretamente — esse é o objetivo de não codificá-lo em um post de blog também. Se você estiver avaliando modelos especificamente para trabalho de desenvolvimento orientado a agentes, veja os melhores modelos de IA para codificação em 2026.

O que isso Não Faz

Ser preciso aqui é tão importante quanto o próprio fluxo de trabalho:

• O servidor MCP não executa inferência paga. Ele responde a perguntas de descoberta. Executar uma solicitação de geração real ainda passa pela API padrão com suas próprias credenciais.
• llms.txt e os arquivos do Centro de Dados de Modelos são snapshots periódicos, não uma conexão de banco de dados ao vivo. O tempo de atualização não é fixado em um cronograma rígido, então trate qualquer data nessas páginas como aproximada. Para qualquer coisa sensível a preço ou segurança, o endpoint de preços e a API do dashboard permanecem a fonte da verdade no momento da solicitação.
• Nada disso substitui a leitura da documentação completa da API para autenticação, limites de taxa ou semântica de tratamento de erros. As superfícies de descoberta dizem a um agente o que existe; elas não substituem a documentação de integração sobre como chamá-lo corretamente.

FAQ

O que um agente deve ler antes de escolher um modelo TokenLab? Leia llms.txt (ou llms-full.txt para mais detalhes) e chame /v1/models antes de codificar qualquer ID de modelo. Para tarefas que não sejam de chat, filtre com recommended_for em vez de adivinhar um nome de modelo de memória.

O TokenLab MCP chama APIs de inferência pagas? Não. O servidor público TokenLab MCP é somente leitura. Suas ferramentas (list_models, get_model, get_model_pricing, get_api_overview) respondem a perguntas de descoberta sobre modelos e preços. As chamadas de inferência reais passam pela API padrão com sua própria chave.

Quando um agente deve usar recommended_for? Sempre que a tarefa não for um chat simples — imagem, vídeo, música, 3D, TTS, STT, embedding, rerank ou tradução. Filtrar por tarefa reduz a lista de modelos para variantes realmente criadas para essa modalidade, em vez de assumir que um modelo orientado a chat lidará com isso.

Como isso reduz IDs de modelos obsoletos no código gerado? Tornando a descoberta o primeiro passo em vez de uma reflexão tardia. Um agente que lê llms.txt, verifica /v1/models e confirma os preços antes de escrever o código está trabalhando a partir de um snapshot atual, em vez de uma memória do tempo de treinamento que pode já ter várias gerações de modelos de idade.

Fontes e Atualidade

• TokenLab llms.txt — https://api.tokenlab.sh/llms.txt — observado em 09/07/2026
• TokenLab llms-full.txt — https://api.tokenlab.sh/llms-full.txt — observado em 09/07/2026
• Documentação do Servidor TokenLab MCP — https://docs.tokenlab.sh/integrations/tokenlab-mcp-server — observado em 09/07/2026
• Documentação da Habilidade de Integração da API TokenLab — https://docs.tokenlab.sh/integrations/coding-agent-skill — observado em 09/07/2026
• Repositório do Servidor TokenLab MCP — https://github.com/hedging8563/tokenlab-mcp-server — observado em 09/07/2026
• Repositório de Habilidades TokenLab — https://github.com/hedging8563/tokenlab-skills — observado em 09/07/2026
• Centro de Dados de Modelos TokenLab — https://tokenlab.sh/model-data/catalog.json, https://tokenlab.sh/model-data/latest.json, https://tokenlab.sh/model-data/summary.md — observado em 09/07/2026

Os IDs de modelos, preços e detalhes de modalidade neste artigo refletem um snapshot tirado no momento da redação. Páginas de snapshot como esta e o llms.txt são atualizadas periodicamente, mas não em uma cadência fixa ou garantida — não construa lógica de nova tentativa ou estimativas de custo em torno de um intervalo de atualização assumido. Verifique os valores atuais na página de preços e no catálogo de modelos antes de enviar o código de integração. Para uma visão mais profunda de como os preços são estruturados entre as famílias de modelos, veja preços da API Gemini para desenvolvedores.

Próximos Passos com o TokenLab MCP

Para começar a usar o TokenLab MCP para descoberta de modelos:

1. Obtenha uma chave de API no dashboard do TokenLab.
2. Conecte seu agente seguindo o guia de integração de agente de codificação.
3. Navegue pelo catálogo diretamente em tokenlab.sh/en/models para ver a cobertura atual de modelos e metadados.
4. Verifique os preços dos modelos que você planeja usar em tokenlab.sh/en/pricing.

Se você está decidindo quais modelos se encaixam no seu fluxo de trabalho, veja nossas análises sobre os melhores modelos de IA para codificação em 2026 e preços da API Gemini para desenvolvedores.

Tenha em mente que o MCP é estritamente uma camada de descoberta — ele exibe metadados, recursos e preços de modelos para que seu agente possa tomar decisões informadas. As chamadas de inferência reais ainda passam pela API padrão do TokenLab usando sua própria chave de API; o MCP não roteia ou faz proxy de solicitações.