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

The annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the bar is lower. The description adds genuinely useful behaviour beyond them: it says the output consists of a PSI value plus a stability verdict, and that it is executed by a real algorithmic engine rather than generated by an LLM, which signals determinism and trustworthiness.

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 two short clauses that lead with the topic and the user scenario, then state the return values. There is no filler, and the engine-authenticity note is short but earns its place.

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 three-parameter statistical tool with no output schema, the description correctly compensates by naming the return values. It is still slightly incomplete, because it doesn't mention any known stability thresholds (for example, PSI < 0.1 meaning stable) or how the bin count affects the verdict, but everything needed to invoke the tool correctly is present.

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 100%: the schema already documents expected_probs as '开发集概率', observed_probs as '验证集概率', and n_bins as '分箱数'. The description adds no extra meaning about parameter formats, ordering, or how n_bins defaults, so this is a baseline-3 case.

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 concrete metric and resource: evaluating model stability (PSI) after the data changes, and it also states the two return values (PSI value and stability judgment). This is clear enough for an agent to tell it apart from neighbouring model-evaluation siblings such as act_roc or act_calibration, although 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?

The phrase '用户要评估模型换数据后稳不稳（PSI）' implies a usage trigger, namely comparing a development set against a validation set for distribution shift. It does not, however, say when to choose this tool over related evaluation tools, nor does it state any prerequisites, such as both probability arrays needing the same length or unit.

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