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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered structurally. The description adds one genuinely useful behavioral claim — '真实算法引擎执行，非大模型生成' — signaling deterministic computation rather than generative output. It says nothing about supported species pairs, unit conventions, or limitations of the conversion model, which are the behaviors that matter for this tool.

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 text is short and front-loads the purpose in a bracketed label, then states the trigger and the return value. The bracketed label largely duplicates the annotation title, and the parenthetical trust claim sits awkwardly at the end, but there is no 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 three-parameter deterministic calculation with no output schema, the description does say what comes back (dose plus rationale), which is the main gap it needed to fill. It remains incomplete on the two things an agent most needs before calling: the dose unit convention and the supported species values for the free-text species fields.

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%, so the baseline of 3 applies; the schema already documents all three parameters. The description adds no meaning beyond that — notably it never specifies the unit basis for source_dose (e.g., mg/kg) or accepted species naming, and it frames the operation as animal-to-human even though target_species is a free string allowing any pair.

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 operation — converting a dose between species (animal to human) — and states what it returns (converted dose plus rationale). It does not, however, distinguish itself from potentially overlapping siblings such as act_bridge_convert or act_pkpd_simulate, so an agent cannot rule out alternatives from the text alone.

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 '用户要把动物剂量换算成人体剂量' supplies an implied trigger scenario, which is adequate context for when to call it. There are no explicit exclusions, no naming of alternatives, and no stated prerequisites (e.g., which species pairs are supported).

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