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

Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so safety is covered. The description adds one genuinely useful behavioral claim — "真实算法引擎执行，非大模型生成" — telling the agent results are computed deterministically rather than fabricated, which matters for trust in downstream reporting. It says nothing about runtime, failure modes on sparse peak matrices, or how the test is chosen (the refusal message in the schema hints at validation but no details).

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?

Only three short segments, so nothing is bloated, but the ordering is awkward: the return claim ("返回：差异 peak") sits before the algorithm note and the sentences are clipped fragments rather than a front-loaded summary. The "非大模型生成" parenthetical is the most informative clause yet buried last.

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 single-parameter statistical tool with 100% schema coverage and a nested input object, the schema plus annotations cover most of what an agent needs. The description still omits output shape (which peak identifiers, fold-change, adjusted p-value columns come back), despite advertising a return value, and gives no guidance on minimum replicate structure the algorithm requires.

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 single nested data_json parameter is documented in depth, including matrix orientation (rows/cols), optional groups alignment with cols, and precomputed p_values/log2fc. The description adds nothing about parameter meaning, so the schema carries the burden — but it does so well enough that little is missing.

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 pairs a vague verb ("扩增") with a domain label ("ATAC 差异可及性"), but the actual operation — differential accessibility testing on ATAC-seq peaks — is only inferable from the Chinese domain tag, not stated as a verb+resource. It does not distinguish itself from near siblings such as act_chip_peak, act_rnaseq_deg, or act_deg_analyze, which an agent could easily confuse it with.

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 only usage signal is "用户有 ATAC-seq 要做差异开放区域", which states the triggering scenario but gives no when-not conditions and no pointer to alternatives such as act_chip_peak or act_deg_analyze. An agent must guess which differential-analysis sibling is correct for ATAC data versus ChIP or bulk RNA data.

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