vidlens_models

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

With zero annotations, the description carries the full burden and does the most important job: it discloses the two-phase download safety gate — without confirm=true the call only reports size and install location, and only confirm=true actually fetches. Undisclosed traits remain (default install path, disk-space/overwrite behavior, whether the download blocks or is async, network failure handling), which keeps this below 5.

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?

Purpose and the size/location/confirm guarantees come first, followed by a compact per-action breakdown — well front-loaded with no filler. The slash-delimited, bolded telegraphic style is slightly dense to parse but every clause carries information an agent needs.

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?

Three optional params, no annotations and no output schema mean the description must stand alone. It covers the risky path (download) but says nothing about what list/recommend return, whether download is long-running, or what happens on a partial/failed install — gaps that matter for a tool that mutates local disk.

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 coverage is 0%, so the description must compensate. It effectively documents `action` (three named values with meanings) and `confirm` (gates the real download), but `name` — the parameter that selects which model — is only implied by "装某个模型" with no format or accepted values. The parenthetical about "换目录" (changing directory) also hints at configuration that no parameter exposes, leaving a gap.

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 the resource (local model catalog / hardware recommendation / download) and enumerates three concrete verbs via action=list, action=recommend, action=download, each with its own scope. An agent can tell immediately that this tool manages models rather than video content, distinguishing it from the video_* siblings without opening the schema.

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?

Each action value is given a use condition: list to see the catalog with resolved local paths, recommend to pick a model for this machine, download to install one. However, there is no guidance on ordering (e.g. call recommend before download), no exclusion of when-not-to-use, and no mention of the vidlens_doctor sibling for environment problems.

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