Driftline

Overview Schema Source Related Servers Discussions Admin

Check model IDs for retirement

check_models

Read-onlyIdempotent

Check OpenAI, Anthropic, and Google model IDs for retirement status, date, days left, and replacement before using them in code.

Instructions

Look up OpenAI, Anthropic and Google model IDs and return, for each one, its retirement status, retirement date, days left and replacement. Use it before writing, changing or keeping a model ID in code, or when the user asks whether a model still works. To find the IDs inside a codebase use scan_project instead; to list everything retiring soon use upcoming_retirements. Read-only. Data comes from the providers' official deprecation pages, re-checked daily at aidriftline.com (fetched with a 4 s timeout, falling back to the copy in the package when offline). IDs not in the registry return status "unknown": no retirement is published for them, which does not prove the ID exists. Up to 100 IDs per call; extra IDs are ignored.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "ids": "<ids>"
    },
    "name": "check_models"
  }
}

Input Schema

Name	Required	Description	Default
`ids`	Yes	Model IDs exactly as written in code, e.g. ["gpt-4o", "claude-sonnet-4-5", "models/gemini-2.5-pro"]. Provider prefixes (openai/, models/), Bedrock, Vertex and OpenRouter spellings and Claude short names are accepted and normalized.

Output Schema

Name	Required	Description
`models`	Yes
`all_dates`	No
`next_step`	No	Present when a model has to move: how to test prompts on the replacement first
`registry_source`	Yes	live = aidriftline.com/models.json; bundled = the copy shipped in the package (used offline)
`registry_checked`	Yes	Date the registry was last checked against the provider pages

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv0.1.1Nov 12, 2026

changedInput schema / properties / ids / description

Previous value: -"Model IDs, e.g. [\"gpt-4o\", \"claude-sonnet-4-5\"]"New value: +"Model IDs exactly as written in code, e.g. [\"gpt-4o\", \"claude-sonnet-4-5\", \"models/gemini-2.5-pro\"]. Provider prefixes (openai/, models/), Bedrock, Vertex and OpenRouter spellings and Claude short names are accepted and normalized."

addedInput schema / properties / ids / maxItems
```
Added value: +100
```

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "all_dates": {
+      "type": "string"
+    },
+    "models": {
+      "items": {
+        "properties": {
+          "advice": {
+            "description": "One plain sentence to pass on to the user",
+            "type": "string"
+          },
+          "alias_of": {
+            "type": "string"
+          },
+          "days_left": {
+            "description": "Days until the date; 0 or negative when it has passed",
+            "type": "number"
+          },
+          "id": {
+            "description": "The ID as given",
+            "type": "string"
+          },
+          "normalized": {
+            "description": "The ID after removing provider prefixes such as models/ or openai/",
+            "type": "string"
+          },
+          "page": {
+            "description": "aidriftline.com page with the source for this date",
+            "type": "string"
+          },
+          "provider": {
+            "type": "string"
+          },
+          "qualifier": {
+            "description": "exact date, earliest possible shutdown (Google), or not before this date (Anthropic)",
+            "enum": [
+              "exact",
+              "earliest",
+              "not-before"
+            ],
+            "type": "string"
+          },
+          "replacement": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "retires": {
+            "description": "YYYY-MM-DD",
+            "type": "string"
+          },
+          "routes": {
+            "description": "true: after the date the provider answers with the replacement model instead of failing",
+            "type": "boolean"
+          },
+          "status": {
+            "description": "retired = calls fail (or are re-routed) now; at-risk = retires within 90 days; deprecated = retirement announced, further out; active = announced as active; unknown = no retirement published",
+            "enum": [
+              "retired",
+              "at-risk",
+              "deprecated",
+              "active",
+              "unknown"
+            ],
+            "type": "string"
+          }
+        },
+        "required": [
+          "id",
+          "status",
+          "advice"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "next_step": {
+      "description": "Present when a model has to move: how to test prompts on the replacement first",
+      "type": "string"
+    },
+    "registry_checked": {
+      "description": "Date the registry was last checked against the provider pages",
+      "type": "string"
+    },
+    "registry_source": {
+      "description": "live = aidriftline.com/models.json; bundled = the copy shipped in the package (used offline)",
+      "enum": [
+        "live",
+        "bundled"
+      ],
+      "type": "string"
+    }
+  },
+  "required": [
+    "models",
+    "registry_checked",
+    "registry_source"
+  ],
+  "type": "object"
+}

First observedv0.1.0Nov 12, 2026

TDQS

A4.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds real context beyond the annotations: data provenance from official deprecation pages, daily refresh, a 4 s fetch timeout with an offline package fallback, and the meaning of status "unknown" (no published retirement, not proof the ID exists). The 100-ID cap being silently ignored is also disclosed. Deduction only because the fallback/staleness caveat could be stated crisply about how fresh results may be when the network path fails.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose, then routing, then operational caveats in descending priority. Dense but almost every clause carries information; the parenthetical about the fetch timeout and offline copy is the one segment that reads more like implementation detail than agent guidance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so field-level return documentation is unnecessary, and the description still orients the caller to what comes back. For a single-parameter read tool, purpose, routing, provenance, edge-case status and call limits are all covered; nothing needed to invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and already documents accepted prefixes and normalization, so the baseline is met. The description nonetheless adds behavior the schema does not encode: IDs beyond 100 are ignored rather than erroring, and unregistered IDs return "unknown" rather than failing.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (look up) and resource (OpenAI, Anthropic and Google model IDs) plus the exact return fields: retirement status, retirement date, days left, replacement. An agent can distinguish it from scan_project and upcoming_retirements without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit triggers ('before writing, changing or keeping a model ID in code, or when the user asks whether a model still works') and names both alternatives with the condition that selects each: scan_project to find IDs in a codebase, upcoming_retirements to list what is retiring soon.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server