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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so safety is covered. The description adds one genuinely useful trait beyond that: results come from a real algorithm engine rather than being LLM-generated, which matters for trust. It says nothing about runtime, matrix size limits, or what happens with missing groups/thresholds.

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 with a bracketed domain tag, then the use case, then the return value. Every element is functional, though the bracketed tag and the tool purpose are partly redundant and sentence structure is fragmentary rather than fully composed.

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?

There is no output schema, and the description only says the return is a 'DEG gene list', which is adequate at a high level. However, data_json is a nested object expression matrix with no described shape or orientation in either description or schema, and groups' expected alignment with matrix columns is unstated – a real gap for a tool whose correctness depends on input layout.

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 all four parameters (groups, log2fc, fdr_threshold, data_json) are already documented, and the description adds no parameter meaning at all. Baseline 3 applies; the description neither clarifies default threshold behavior nor the expected orientation of the expression matrix.

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?

States a specific verb+resource: differential expression analysis on an RNA-seq expression matrix, returning a DEG list. The domain is clear, but it never distinguishes itself from the close sibling act_deg_analyze (or act_scrna_markers / act_atac_diff), so an agent cannot tell from the description alone which DEG tool to pick.

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 '用户有 RNA-seq 表达矩阵要做差异基因' implies the triggering condition (you have a bulk RNA-seq matrix and want DEGs), but there is no when-not guidance, no prerequisites, and no named alternative such as act_deg_analyze. Usage is only implied, not stated.

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