MCP Model Catalog for Coding Agents: Make Model Choice Machine-Readable

A coding agent that hardcodes model names will eventually page someone at 2 a.m. An MCP model catalog for coding agents changes that failure mode. Instead of a string buried in source code, the agent reads a structured list of current models, costs, modalities, and status fields at request time. We maintain a similar catalog at TokenLab, and we treat the catalog as the source of truth for routing. In our pipeline, model choice is a lookup, not a constant.

Why Coding Agents Need Machine-Readable Model Data

Most coding agent integrations still work like API integrations from a decade ago. A developer picks a model name, pastes it into a config or environment variable, and ships. That works until the provider deprecates the model, changes pricing, or releases a better option. Then the team has no process for adopting it.

A machine-readable catalog changes the failure mode. When a model is retired, the agent can query the catalog, see the model is gone or marked deprecated, and fall back to a documented alternative. Instead of a developer manually benchmarking every new release, tooling can compare listed context windows, modality support, and cost fields before switching.

This is also a prerequisite for serious model routing. You may want cheap, high-volume completions on DeepSeek V4 Flash or Gemini 3.5 Flash. You may reserve Claude Sonnet 5 for multi-file refactors. The routing logic still needs a source of truth. That source must say which models are current, what they cost, and what they support. Without it, routing rules rot the same way hardcoded model names do.

TokenLab has written about this problem directly. See agent-readable model truth for the broader argument, and agent-first API for how API design changes when the primary caller is an agent rather than a human developer.

Key Takeaways

What Belongs in an MCP Model Catalog Entry

A useful catalog entry for a coding agent needs more than a model name. At minimum, builders and consumers should expect to see:

• Model identifier: the exact string the API expects, since providers often version names precisely (a mismatch here is one of the most common integration bugs).
• Provider: which company or platform serves the model, relevant when a catalog aggregates multiple providers.
• Modality support: text, code, image, or video. A catalog mixing coding models like Kimi K2.7 Code with image models like Nano Banana Pro needs a field that lets an agent filter by what it actually needs.
• Context window: token limits matter enormously for coding agents working across large repositories.
• Cost fields: input and output token pricing, ideally separated, since coding agents often have asymmetric input-heavy workloads (large file context, small diff output).
• Status: current, deprecated, or scheduled for retirement. This is the field that prevents silent breakage.
• Task suitability tags: optional but useful metadata such as 'coding,' 'low-cost routing,' or 'open-weight,' so an agent can filter without knowing every model's characteristics in advance.

None of these fields are guaranteed to exist in every provider's catalog format. Before building an integration, check the actual schema documented at the provider you use. For TokenLab-served models specifically, verify the current field set and update cadence at /models/data rather than assuming they match this article. Catalog schemas change as new models and modalities are added.

Example: Requesting a Model Catalog Over MCP

MCP typically communicates over JSON-RPC 2.0. A client asking a server to list available model resources might send a request shaped like this. This example follows the general MCP resource-list pattern. It is not a claim about any specific provider's live schema. Confirm exact method names and response fields against https://docs.tokenlab.sh or your MCP server's own documentation before writing production code against it.

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

A plausible response shape, again illustrative rather than a verified schema:

{
  "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"]
      }
    ]
  }
}

Do not treat the context window values, exact field names, or the specific models listed above as confirmed facts about any live API. They show the shape of a request and response, not pricing or capability numbers. Pull those numbers from the provider's current documentation or from /models/data when you build.

Choosing Models by Task: A Decision Checklist

A model catalog is only useful if the agent or the developer configuring the agent has a rule for matching task type to model. The table below is a starting framework, not a benchmark result. Verify current pricing and capability claims against provider documentation and /models before committing to a routing rule in production.

Coding agent task	What matters most	Example models to evaluate
Autocomplete / inline suggestions	Low latency, low cost per call	DeepSeek V4 Flash, Gemini 3.5 Flash, Laguna XS 2.1
Multi-file refactor	Larger context window, strong code reasoning	Claude Sonnet 5, DeepSeek V4 Pro
Test generation	Consistent formatting, moderate reasoning	Kimi K2.7 Code, Claude Sonnet 5
Code review / PR summarization	Strong reasoning, ability to reference diffs accurately	Claude Sonnet 5, Gemini 3.5 Flash
High-volume batch tasks (linting, doc comments)	Cost per token above raw capability	GLM-5.2, Qwen3.7 Plus, MiniMax M3
Open-weight requirement (self-host or license constraints)	Open weights, deployable outside a managed API	GLM-5.2, DeepSeek V4 Pro, DeepSeek V4 Flash, Qwen3.7 Plus, Kimi K2.7 Code

A practical checklist for building the routing logic itself:

1. Does the catalog entry include a status field, so you can detect deprecation before a call fails?
2. Does the catalog separate coding-capable models from general text or image models, so filtering doesn't require hardcoded lists?
3. Can you set a cost ceiling per task type and have the agent select the cheapest model that meets it, rather than always defaulting to the most capable (and most expensive) option?
4. Is there a fallback model defined for every task category, in case the primary choice is unavailable or rate-limited?
5. Are you re-checking the catalog on a schedule, not just at first integration, since model lineups change over time?

Where TokenLab Fits in This Workflow

TokenLab maintains a Model Data Center at /models/data and a model directory at /models, both observed as of 2026-07-14. Check these surfaces for current model listings rather than relying on any static article. Model catalogs are inherently time-sensitive. TokenLab's API documentation at https://docs.tokenlab.sh is the place to verify exact request and response schemas before integrating.

You may build a coding agent that routes between several models. Use Claude Sonnet 5 for review tasks, DeepSeek V4 Flash for cheap high-volume completions, and Kimi K2.7 Code for test generation. Treat the model identifier as a variable. Resolve it at request time against a catalog, not as a constant compiled into your agent's source. The practical step is to check /models/data and confirm the request shape your MCP client needs against the TokenLab API documentation. Wire routing logic into production only after those checks.

Limitations

This article describes a general pattern for MCP model catalogs and coding agent routing. It does not confirm that any specific provider, including TokenLab, exposes every field described above (context window, cost fields, status, task tags) in exactly this shape. Schemas, field names, and available models change frequently. Treat the JSON examples in this article as illustrative of MCP's general request and response pattern, not as a verified schema for any live endpoint. Before shipping, confirm exact model identifiers, pricing, and context windows against the provider's current documentation and against /models/data.

FAQ

Does MCP itself define a standard model catalog schema?

MCP defines general patterns for resources and tools over JSON-RPC, but the exact fields in a model catalog (pricing, context window, status) depend on how the server implementing MCP chooses to expose that data. Verify the specific schema with the server or provider you are integrating against.

Should a coding agent always use the most capable model available?

Not necessarily. Tasks like autocomplete are latency- and cost-sensitive, while multi-file refactors benefit from stronger reasoning and larger context. A catalog with task tags and cost fields lets you route by task rather than defaulting to one model for everything.

How often should I re-check the model catalog my agent depends on?

Model lineups change often enough that a one-time integration is not sufficient. Build your routing logic to query the catalog rather than cache model identifiers permanently, and check /models/data or your provider's documentation on a regular schedule.

Get Started by reviewing the current listings at /models/data and confirming the request shape your MCP client needs against the TokenLab API documentation before wiring routing logic into production.