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

Annotations already declare readOnlyHint=false with destructiveHint=false and openWorldHint=false, so the agent knows this produces/persists something without being destructive. The description adds only the terse 'RETURNS: 系统评价框架' and never says what is created, whether prior content is overwritten, or what the caller gets back.

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?

Pipe-delimited, front-loaded sections make the trigger condition scannable immediately. The ALIASES block is boilerplate padding that does not help an agent decide or invoke, which keeps it below 5.

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 seven parameters, no output schema, and a write-capable (readOnlyHint=false) annotation profile, the description should say more about the artifact produced and how the PICO fields combine. It is adequate to recognize the right scenario but not to predict the result.

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% and each of the seven PICO fields is documented in the schema itself. The description adds no parameter-level guidance (e.g., that query must be a composite Boolean string assembled from P/I/C/O), so it neither compensates nor detracts; baseline 3 applies.

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 concrete resource and activity: 'screening and extraction support for a systematic review / meta-analysis', plus a return artifact ('系统评价框架'). It is clearly not a generic literature review tool, but it does not name or differentiate against any sibling (e.g., literature_review_outline, deep_peer_review), so it stops short of 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 'USE WHEN' clause supplies an explicit triggering condition tied to screening/extraction for a systematic review or meta-analysis. There are no exclusions or named alternatives, which keeps it at 4 rather than 5.

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