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

Annotations already establish this as a non-destructive, read-only, closed-world operation, and the description correctly adds the output format ("RETURNS: 列线图 SVG"), which matters because there is no output schema. However, it never explains how the Cox/logistic model is meant to be supplied — the schema only offers a single CSV field — leaving a real behavioral gap for a figure-generation tool.

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?

Pipe-delimited, front-loaded, and every segment conveys something (trigger, aliases, return type). The repeated tool name in the header and the four near-duplicate aliases are slightly redundant but serve search matching.

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 no output schema, stating the return type as SVG is genuinely useful and covers the output side. The input side is incomplete: for a single-CSV-parameter tool the description should indicate what that CSV must be for a model-to-nomogram conversion to succeed.

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 100% with a single optional parameter, so baseline 3 applies. The description adds nothing about what the CSV must contain (coefficients? training rows? column naming?), which is precisely the information the terse "CSV 文本" schema description does not supply.

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?

"Turn a logistic or Cox model into a nomogram figure for clinical use" is a specific verb + resource + scope statement, so the agent knows exactly what the tool produces. It stops short of naming a sibling (e.g. forest_plot, calibration_curve) that an agent might confuse it with, which keeps it out of 5 territory.

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 "USE WHEN" clause gives a clear triggering condition: when you already have a logistic or Cox model and want a clinical nomogram figure. There are no explicit exclusions or alternative-tool routing, so the agent must infer that model fitting itself belongs to survival_cox or stats_toolbox.

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