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

An MCP model catalog for coding agents is a structured, queryable list of available models that an agent can read through the Model Context Protocol instead of relying on model names hardcoded into source code. It lets an agent, an IDE plugin, or an orchestration layer select a model at runtime based on task type, context window, or cost ceiling rather than a string a developer typed six months ago and forgot to update.

This matters more than it sounds. Coding agents call models constantly, for autocomplete, for multi-file refactors, for test generation, for commit message drafting. Each of these tasks has a different ideal model. If the agent cannot discover what models exist and what they are good for, someone has to keep editing a config file every time a provider ships a new release. This article walks through what a model catalog entry should contain, how MCP-style requests for that catalog are shaped, and how to decide which models to route to which coding tasks.

Key Takeaways

Why Coding Agents Need Machine-Readable Model Data

Most coding agent integrations still work the way API integrations worked 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 that the team has no process for adopting.

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

This is also a prerequisite for any serious model routing strategy. If you want to send cheap, high-volume completions to a low-cost model like DeepSeek V4 Flash or Gemini 3.5 Flash, and reserve a stronger model like Claude Sonnet 5 for multi-file refactors, the routing logic needs a source of truth about which models are current, what they cost, and what they support. Without that, routing rules rot the same way hardcoded model names do.

TokenLab has written about this problem directly in the context of making model information something an agent can trust rather than something a human has to re-verify by hand. See agent-readable model truth for the broader argument about agent-readable model truth, and agent-first API for how API design changes when the primary caller is an agent rather than a human developer.

What Belongs in an MCP Model Catalog Entry

A useful catalog entry for a coding agent needs more than a model name. At minimum, developers building or consuming one 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 are using. For TokenLab-served models specifically, the current field set and update cadence should be verified at /models/data rather than assumed from this article, since 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 is illustrative of the general MCP resource-list pattern and 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 exist here to show the shape of a request and response, not to state pricing or capability numbers. Always pull those numbers from the provider's own current documentation or from /models/data at the time 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. These are the surfaces to check for current model listings, rather than relying on any static article, since 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.

If you are building a coding agent that needs to route between models like Claude Sonnet 5 for review tasks, DeepSeek V4 Flash for cheap high-volume completions, and Kimi K2.7 Code for test generation, the practical pattern is to treat the model identifier as a variable resolved at request time against a catalog, not a constant compiled into your agent's source. 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.

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.