List Models

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

No annotations are provided, so the description carries the full disclosure burden. It discloses the non-obvious behavior that multimodal projection detection is included in the scan, and the read-only nature is implied by '扫描/返回', but it says nothing about cost, latency, failure when the directory is absent, or whether results are cached.

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 compact sentence that front-loads the action and the returned data. Nothing is wasted, though the extreme terseness leaves coverage gaps that a second clause could have closed.

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?

With an output schema present, the description need not explain return values, and 0 params means no parameter docs are required. However, the term '主模型' (main models) implies a distinction from other models and the purpose of the multimodal projection probe is unexplained, so an agent cannot fully predict the scope of the listing.

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 tool takes zero parameters, so per the baseline rule this is a 4. The description correctly implies no input filtering is possible, which is consistent with the empty schema.

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 names a specific verb (扫描/返回) and resource (本地模型目录, GGUF 主模型元数据), so the agent knows this enumerates locally available models rather than server or runtime state. It is clearly distinguishable from siblings like start_server or runtime_info, though it does not explicitly name them.

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?

There is no when-to-use guidance, no prerequisite (e.g. does the server need to be running?), and no mention of alternatives. The purpose implicitly suggests 'use this to discover models', but nothing is stated.

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