list_ai_models
列出 OpenAI、Anthropic(Claude)、Google(Gemini)模型與 API 功能的淘汰狀態、下架日與官方建議替代;可依公司、狀態、類型篩選。
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | ||
| status | No | ||
| provider | No |
列出 OpenAI、Anthropic(Claude)、Google(Gemini)模型與 API 功能的淘汰狀態、下架日與官方建議替代;可依公司、狀態、類型篩選。
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | ||
| status | No | ||
| provider | No |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full disclosure burden. It does add real behavioral content — it enumerates the returned attributes (淘汰狀態、下架日、官方建議替代) — and the verb 列出 implies a read-only listing. But it omits pagination, sorting, result volume, and data freshness, which matter for a catalog spanning three providers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence that front-loads what is returned and appends the filter capability. Zero filler and no repetition of the tool name or obvious facts.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three optional filter params, no output schema, and no annotations, the description covers the core (resource, returned fields, filters) but leaves the sibling-boundary question unresolved — with five related tools in scope, the agent still lacks a criterion for choosing this one. Adequate but with a clear gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it does: '可依公司、狀態、類型篩選' maps directly onto provider/status/kind and confirms all three act as optional filters. The enum values themselves are self-explanatory, so no deeper syntax detail is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (列出) and resource (AI 模型與 API 功能的淘汰狀態、下架日、官方替代), which is far more informative than the bare name list_ai_models. However, it never distinguishes itself from siblings like ai_model_shutdown_calendar, upcoming_ai_model_shutdowns, or find_ai_model_replacement, whose scope overlaps heavily with the deprecation/shutdown/replacement content it claims to return.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes that results '可依公司、狀態、類型篩選' but gives no when-to-use guidance, no prerequisites, and no pointer to alternatives. An agent cannot tell from this text whether to call list_ai_models, upcoming_ai_model_shutdowns, or find_ai_model_replacement for a given deprecation question.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.