query_model_price查询指定大模型（如 GPT-5, Claude, DeepSeek）的最新 API 输入、输出和缓存输入单价（单位：每百万 tokens）。
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | 模型 ID 或模糊名称，大小写不敏感（例如 'gpt-5'、'deepseek-v4'、'claude-sonnet'）。匹配顺序：精确匹配 ID → 精确匹配名称 → 按包含关系匹配 ID → 按包含关系匹配名称，取首个命中。 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, idempotent, and non-destructive, so the description is not burdened with safety disclosure. It adds minor context like freshness ('最新') and price components, but does not disclose return format, error behavior, or whether results are cached. This is adequate but not rich.
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?
The description is a single, tightly written sentence that front-loads the action, target, and key details. There is no filler, redundancy, or unnecessary explanation.
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?
For a simple read-only lookup with one well-documented parameter and no output schema, the description conveys what is returned (input/output/cached-input prices) and their unit. It could mention edge cases or the sibling relationship, but the existing content is sufficient for basic invocation.
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?
The input schema covers the single 'model' parameter with detailed matching-order semantics, achieving 100% schema description coverage. The description adds unit context (per million tokens) and example models, but does not meaningfully expand on the schema's parameter documentation.
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?
The description uses a specific verb ('查询' / query) and clearly identifies the resource: latest API input, output, and cached-input unit prices for a specified model, with units defined (per million tokens). This distinguishes it from the sibling tool 'estimate_cost', which focuses on cost estimation rather than actual price lookup.
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 implies its usage context (when you need current API prices for a model) but does not explicitly mention alternatives or exclusions. It fails to reference the sibling tool 'estimate_cost' or clarify when to prefer this over cost estimation, so guidance is present but implicit.
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.
The two tools have clearly distinct purposes: one estimates input-side costs for text/tokens (a calculation service), the other queries model price listings (a reference/data service). There is no overlap or ambiguity between them; the shared context of model pricing is handled without duplication.
Both tools use a verb_noun pattern: 'estimate_cost' and 'query_model_price'. While the pattern is consistent (verb + object), the objects differ in abstraction—'cost' vs. 'model_price'—but this is acceptable. A minor deviation is that 'query_model_price' could be seen as a query action, while 'estimate_cost' is a computation, but the naming style remains coherent.
With only 2 tools, the server is minimal. For a focused utility like LLM cost estimation, 2 tools might be sufficient, but it feels slightly thin because an agent might expect additional related capabilities, such as output-cost estimation or a combined estimate. However, the purpose is clearly narrowed to input-side cost and price queries, so it is borderline.
The domain is LLM cost estimation, but the tool surface is incomplete: 'estimate_cost' explicitly warns that it only handles input cost and does not include output tokens, but there is no tool to estimate full round-trip costs or to combine input/output. It lacks a tool to estimate output cost directly, and while 'query_model_price' provides output prices, the agent must manually integrate them. This is a significant gap because the core use case of estimating a complete API call cost is not fully supported.