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

The annotations already establish that this is a safe, read-only, closed-world computation, so the description need not restate that. It does add useful methodological context (90% CI with the 80-125% acceptance rule) and says what the result contains. It does not disclose requirements or failure modes, such as a minimum sample size per group or how unequal-length lists are treated.

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 definition is short and front-loaded, with the WHEN condition placed before aliases. The bilingual duplication and the long alias list are boilerplate padding, but they cost little and do not bury the core statement.

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?

There is no output schema, so the description is responsible for describing the return value; 'RETURNS: 90%CI 与等效性判定' does this only in outline and does not say whether point estimates, ratios, or power are also returned. For a computational tool taking two array inputs, the description is adequate but not complete.

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% for both parameters, so the baseline is 3; the description adds no extra meaning beyond 'test vs reference AUC'. Worse, it advertises a Cmax input that does not exist in the schema, which could lead an agent to look for a nonexistent parameter.

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 states a specific verb and resource: 'compare test vs reference AUC/Cmax and judge 80-125% bioequivalence with 90% CI'. That is enough for an agent to tell it apart from neighboring PK/statistics tools such as pk_nca, delong_auc_compare, or clinical_basic_bridge. The only flaw is that it claims Cmax support, which the schema does not expose.

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?

A 'USE WHEN' clause gives a trigger condition, which is more than most definitions offer. However, it names no alternatives and no exclusions, so an agent cannot tell when pk_nca or stats_toolbox would be the better choice. The mention of Cmax in the trigger is actively misleading, since no Cmax parameter exists.

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