TokenLab for Agents: Machine-Readable Models, Pricing, SDKs, and MCP

TokenLab MCP is a read-only Model Context Protocol (MCP) server that gives a coding agent direct, structured access to TokenLab's public model catalog, pricing, and API overview before it writes a single line of integration code. It answers discovery questions — which model IDs currently exist, what they cost, what modality they support — and it does not call paid inference APIs on your behalf.

Many agent integration bugs don't start at the first API call—they start earlier, when the agent picks a model ID from a stale example, a cached memory, or a six-month-old tutorial, and only discovers the mismatch after a 404 or a pricing surprise.

Coding agents write fast. They do not always read first. Alongside TokenLab MCP, TokenLab publishes a compact llms.txt, a fuller llms-full.txt, and public model-data JSON files — the same model catalog and pricing surfaces you can browse yourself — so an agent can check current model IDs and costs before it hardcodes anything.

This article covers what those surfaces are, what they are not, and how to wire an agent to use them before it hardcodes a model name. For the full endpoint reference, see the integration docs.

Key Takeaways

Why Agents Pick Stale Model IDs in the First Place

Coding agents generate model IDs from what they learned during training, not from what's currently available. That training data has a cutoff, so an agent's internal sense of "the current model" is fixed at whatever was true when its weights were last updated. When you ask an agent to call a model API, it will confidently reach for the ID it remembers — even if that ID has since been renamed, deprecated, or replaced.

This isn't a bug in the agent's reasoning; it's a structural limitation of any system that relies on memorized knowledge instead of a live lookup. The fix isn't a smarter prompt — it's giving the agent a place to check before it writes code.

That's what TokenLab's model-data files and API exist for. Before generating a request, an agent (or the human reviewing its output) can query a live endpoint to confirm the model ID actually exists, what modality it supports, and what it costs — instead of trusting a name pulled from memory.

Endpoint	Purpose
https://tokenlab.sh/model-data/catalog.json	Full catalog of tracked models, structured for programmatic lookup
https://tokenlab.sh/model-data/latest.json	Current model list in a lightweight, agent-friendly format
https://tokenlab.sh/en/models	Human-readable model browser
https://tokenlab.sh/en/pricing	Current pricing by model and modality

A blog post — including this one — is a snapshot. It reflects what was true when it was written, and it will drift out of date the same way an agent's training data does. Live endpoints don't have that problem: they reflect what's true right now, which is why they're the safer thing to check before code ships, not a static article.

What TokenLab Exposes for Agent Discovery

The llms.txt layer

https://api.tokenlab.sh/llms.txt is a compact, agent-readable overview of the API: what endpoints exist, what a request looks like, and where to find deeper detail. It is designed to be short enough that an agent can read it in a single context window without burning a large token budget just to orient itself.

https://api.tokenlab.sh/llms-full.txt is the fuller version — more endpoint detail, more examples, more of the surface area an agent needs before generating a working integration rather than a rough draft.

If you land on the web domain instead of the API host, tokenlab.sh/llms.txt and tokenlab.sh/llms-full.txt redirect to the same API-hosted sources. That matters for agents: whichever entry point they crawl or fetch, they land on the same canonical text, not two diverging copies.

The Model Data Center

Beyond the text overview, TokenLab publishes structured JSON files an agent (or a build script) can pull directly:

• https://tokenlab.sh/model-data/catalog.json — the fuller model catalog.
• https://tokenlab.sh/model-data/latest.json — a snapshot oriented toward what's current right now.
• https://tokenlab.sh/model-data/summary.md — a human-and-agent-readable markdown summary, useful when you want a quick diff against what your codebase currently hardcodes.

These are static, fetchable files. An agent building a config file, a .env template, or a model-selection dropdown can pull the JSON directly instead of asking a human to paste in a model list that will be stale again in two weeks.

The MCP server — read-only, and worth being precise about that

https://github.com/hedging8563/tokenlab-mcp-server is public. It exposes four tools relevant to discovery:

• list_models — enumerate what's available, optionally filtered.
• get_model — pull detail on a specific model ID.
• get_model_pricing — pull current pricing for a specific model.
• get_api_overview — the MCP-native equivalent of reading llms.txt.

The important constraint: this server is read-only. It does not call paid inference APIs on your behalf, and it does not proxy generation requests. It answers questions about models, pricing, and API shape. If your agent needs to actually run inference, it still goes through TokenLab's normal API with your own key — the MCP server is a discovery layer, not an execution layer. Conflating the two is a common mistake worth avoiding explicitly in any agent prompt or skill file you write.

TokenLab MCP Discovery Example

TokenLab exposes a read-only Model Context Protocol (MCP) server that lets coding agents discover available models and pricing without performing any inference. The MCP server provides four tools:

• list_models — list available models, optionally filtered by recommended_for (e.g. image, video, embedding, rerank, translation)
• get_model — retrieve details for a specific model
• get_model_pricing — retrieve pricing information for a specific model
• get_api_overview — retrieve a summary of the TokenLab API

Example: listing models via MCP

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

Example: filtering models by recommended use

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

If you'd rather query the API directly instead of going through MCP, the equivalent REST calls are:

# List all models
curl https://api.tokenlab.sh/v1/models \
  -H "Authorization: Bearer sk-KEY"

# List models recommended for image tasks
curl "https://api.tokenlab.sh/v1/models?recommended_for=image" \
  -H "Authorization: Bearer sk-KEY"

Note that the MCP server is strictly read-only — it is intended for discovery (listing models, inspecting pricing, and reviewing API capabilities) and does not perform any inference itself.

For setup instructions and integration details, see:

• TokenLab MCP Server
• Coding Agent Skill

The skills repo

https://github.com/hedging8563/tokenlab-skills packages this discovery pattern into something a coding agent framework can load directly — a skill definition that tells the agent "read this before you write TokenLab integration code," rather than relying on the agent to independently decide to check.

The Recommended Agent Workflow

Public docs describe a specific sequence, and it holds up well in practice:

1. Before hardcoding any model name, call /v1/models or read llms.txt to confirm the ID actually exists right now.
2. For non-chat tasks — image, video, music, 3D, TTS, STT, embedding, rerank, translation — filter with /v1/models?recommended_for=<task> instead of assuming a chat-oriented model handles the task, or guessing at a model name from memory.
3. Before retrying a failed non-chat request, read /v1/models/:model and /v1/models/:model/pricing. A failed request against a wrong-modality model will often fail again on retry with the same input; checking the model's actual modality and pricing first saves a retry loop.

This sequence matters because it front-loads the two most common failure modes: wrong model ID, and wrong model family for the task.

Practical checklist for wiring this into an agent

Step	What to check	Where
1	Does this model ID still resolve?	/v1/models or llms.txt
2	Is this the right model family for the task (chat vs. image vs. embedding, etc.)?	/v1/models?recommended_for=<task>
3	What is current input/output pricing for this model?	/v1/models/:model/pricing or get_model_pricing (MCP)
4	What is the context window and modality?	/v1/models/:model or get_model (MCP)
5	Is there a newer model with a similar name that has replaced this one?	catalog.json / latest.json
6	Did the agent read llms.txt before generating integration code?	Confirm in the agent's tool-call log

If an agent skips step 1 and 2, everything downstream — retries, error handling, cost estimates — is built on an assumption instead of a fact.

Why This Matters for Non-Chat Tasks Specifically

Chat models get most of the attention, but the recommended_for filter exists because non-chat tasks fail in less obvious ways. A model built for text-to-text generation returning a malformed response to an image request does not always throw a clean, self-explanatory error. Sometimes it just returns something the agent doesn't know how to parse.

Filtering by recommended_for=image, recommended_for=video, recommended_for=embedding, and so on narrows the candidate set before the agent ever writes a request body. Given how many distinct image-generation entries can exist in the model catalog at any given time — 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 — guessing which one is "the image model" from memory is exactly the failure mode this workflow is designed to prevent. Video generation has its own set of task-specific models (seedance, veo-3, among others) with different pricing and modality shapes; the same filtering logic applies.

For exact current pricing, context limits, and modality on any specific model named here, check the model catalog and pricing page directly — that's the entire point of not hardcoding it into a blog post either. If you're evaluating models for agent-driven development work specifically, see best AI models for coding 2026.

What This Does Not Do

Being precise here matters as much as the workflow itself:

• The MCP server does not execute paid inference. It answers discovery questions. Running an actual generation request still goes through the standard API with your own credentials.
• llms.txt and the Model Data Center files are periodic snapshots, not a live database connection. Refresh timing isn't fixed to a strict schedule, so treat any date on these pages as approximate. For anything price-sensitive or safety-sensitive, the pricing endpoint and the dashboard API remain the source of truth at request time.
• None of this replaces reading the full API docs for authentication, rate limits, or error-handling semantics. Discovery surfaces tell an agent what exists; they don't replace the integration docs for how to call it correctly.

FAQ

What should an agent read before choosing a TokenLab model? Read llms.txt (or llms-full.txt for more detail) and call /v1/models before hardcoding any model ID. For non-chat tasks, filter with recommended_for rather than guessing a model name from memory.

Does TokenLab MCP call paid inference APIs? No. The public TokenLab MCP server is read-only. Its tools (list_models, get_model, get_model_pricing, get_api_overview) answer discovery questions about models and pricing. Actual inference calls go through the standard API with your own key.

When should an agent use recommended_for? Whenever the task is not plain chat — image, video, music, 3D, TTS, STT, embedding, rerank, or translation. Filtering by task narrows the model list to variants actually built for that modality, instead of assuming a chat-oriented model will handle it.

How does this reduce stale model IDs in generated code? By making discovery the first step instead of an afterthought. An agent that reads llms.txt, checks /v1/models, and confirms pricing before writing code is working from a current snapshot rather than a training-time memory that may already be several model generations old.

Sources and Freshness

• TokenLab llms.txt — https://api.tokenlab.sh/llms.txt — observed 2026-07-09
• TokenLab llms-full.txt — https://api.tokenlab.sh/llms-full.txt — observed 2026-07-09
• TokenLab MCP Server docs — https://docs.tokenlab.sh/integrations/tokenlab-mcp-server — observed 2026-07-09
• TokenLab API Integration Skill docs — https://docs.tokenlab.sh/integrations/coding-agent-skill — observed 2026-07-09
• TokenLab MCP Server repository — https://github.com/hedging8563/tokenlab-mcp-server — observed 2026-07-09
• TokenLab Skills repository — https://github.com/hedging8563/tokenlab-skills — observed 2026-07-09
• TokenLab Model Data Center — https://tokenlab.sh/model-data/catalog.json, https://tokenlab.sh/model-data/latest.json, https://tokenlab.sh/model-data/summary.md — observed 2026-07-09

Model IDs, pricing, and modality details in this article reflect a snapshot taken at time of writing. Snapshot pages like this one and llms.txt are updated periodically, but not on a fixed or guaranteed cadence — don't build retry logic or cost estimates around an assumed refresh interval. Verify current values against the pricing page and model catalog before shipping integration code. For a deeper look at how pricing is structured across model families, see Gemini API pricing for developers.

Next Steps with TokenLab MCP

To start using TokenLab MCP for model discovery:

1. Get an API key from the TokenLab dashboard.
2. Connect your agent following the coding agent integration guide.
3. Browse the catalog directly at tokenlab.sh/en/models to see current model coverage and metadata.
4. Check pricing for the models you plan to use at tokenlab.sh/en/pricing.

If you're deciding which models fit your workflow, see our breakdowns on best AI models for coding in 2026 and Gemini API pricing for developers.

Keep in mind that MCP is strictly a discovery layer — it surfaces model metadata, capabilities, and pricing so your agent can make informed decisions. Actual inference calls still go through the standard TokenLab API using your own API key; MCP does not route or proxy requests.