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

Annotations already establish readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds the return payload (curves, median survival, HR, log-rank P), which is genuinely useful, but says nothing about modeling assumptions such as proportional hazards, censoring coding, or minimum sample requirements.

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 pipe-delimited layout is front-loaded and scannable: purpose, use condition, aliases, returns. The alias list is long but serves search/retrieval value in both languages; no sentence is filler.

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 six-parameter statistical modeling tool the definition covers what it does, when to use it, and what it returns, with no output schema needed for return values. It omits the conditional parameter relationships (cox requiring covariate_cols, group_col being optional for multivariable models) and any note about reference-group handling, which an agent must infer.

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% and each of the six parameters has a Chinese description covering time, event coding (1=event), group, analysis type (km/cox), and covariate columns. The description adds no guidance beyond the schema — notably it never explains which parameters are required under analysis_type='cox' versus 'km', though the baseline of 3 is appropriate when the schema does the work.

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 method set (KM curves plus multivariable Cox) and enumerates concrete outputs — survival curves, median survival, hazard ratios, log-rank P — so the resource is unambiguous. It does not, however, distinguish itself from the sibling kaplan_meier or animal_survival_km, which an agent could reasonably confuse with this tool.

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: follow-up time and event data' clause gives a clear triggering condition (time-to-event data with censoring, subgroup comparison, multivariable adjustment). It stops short of explicit exclusions or naming the simpler KM-only sibling as the alternative for single-curve cases.

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