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

Annotations already declare readOnly=true, destructive=false and openWorld=false, so the safety profile is covered structurally. The description adds one genuinely useful behavioral claim — that execution goes through a real algorithm engine rather than LLM generation — but says nothing about estimand choice, convergence/fallback behavior, or output shape beyond 'weights and effects'.

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?

Very short and front-loaded: method name bracketed first, then trigger, then return value, then an execution-trust note. Every clause carries information; only the parenthetical engine note is somewhat promotional rather than operational.

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?

With no output schema, the description at least states what is returned (weights and weighted effects), which is necessary. However, for a two-parameter inferential statistics tool it omits the estimand (ATE vs ATT), whether confidence intervals are produced, and how the odd string-typed numeric arrays should be formatted.

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%, with both parameters (treatment 0/1 and propensity scores) documented inline, so the schema carries the parameter burden and 3 is the baseline. The description adds no extra meaning — notably it does not clarify that inputs are passed as string arrays or explain the expected propensity-score range.

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?

Names a specific statistical method (IPTW / inverse probability weighting) and the analysis it performs, plus what it returns (weights and weighted effect estimates). It does not differentiate itself from similar siblings such as act_psm_match or act_smd_balance, which keeps it from a 5.

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 '用户要做倾向评分加权分析' implies the trigger condition (user requests propensity-score weighting), but there is no explicit when-not guidance and no mention of the closely related alternative tools (matching, balance diagnostics, effect-size calculation) that an agent must choose between.

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