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

Annotations already declare readOnly/ non-destructive/ closed-world, so safety is covered. The description adds meaningful behavior beyond that: the result is produced deterministically by a decision tree and scoring matrix rather than model guessing, and it enumerates what the user receives (design type, framework, rationale, allocation ratio). It does not state confidence handling or fallback behavior when PICO is incomplete.

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?

Content is dense but structurally flat: the title is restated at the start and "推荐设计类型" repeats near the end, creating redundancy. The quoted user questions are useful but packed into a single run-on block with no separators between purpose, method, and output.

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?

It discloses the return content, which matters since no output schema exists, and it signals determinism. However, the required nested PICO object is left as "同上", so the definition is not self-contained, and there is no indication of what happens when PICO elements are missing or contradictory.

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% and the feasibility object's keys are enumerated in the schema, so the schema carries most of the load. The description only adds that the reasoning is PICO-driven. The pico object is described as "PICO 四要素（同上）", a dangling reference that gives an isolated agent no field-level meaning.

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 action and resource: it recommends study design type and rationale from PICO, using a decision tree plus scoring matrix. It also covers design type, framework, rationale, and allocation ratio, which distinguishes it from pure LLM-guess siblings. It does not name the closest alternatives (study_design_advisor, act_design_generate, act_design_next_step), so sibling separation is only partial.

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?

Concrete trigger phrasing is supplied: when the user asks "what design should this topic use", "RCT or cohort", or "how to sample". That gives an agent clear activation conditions. No when-not-to-use or explicit routing to an alternate tool is stated.

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