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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered and only value-add context is required. The description supplies none: it does not say whether the tool returns a framework/template, a screening protocol, or guidance text, nor whether it depends on any prior conversation state. With zero parameters and no output schema, this is the only place that could have explained the return, and it does not.

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, but it is three unpunctuated fragments rather than front-loaded prose, and '系统评价辅助' plus '系统评价框架' restate the title and each other. Minimal waste in length, but the structure does not put the operative information (what is produced) first.

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?

The tool takes no parameters and has no output schema, so complexity is low, yet an agent still cannot predict what comes back or how to present it to the user. For a generic 'framework' action tool whose entire value is the returned content, at least one clause describing the deliverable was needed. What remains is a topic label, not a callable contract.

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?

The input schema defines zero properties, so there are no parameter semantics to explain and the baseline of 4 applies. The description does not need to compensate for any schema gap, and it makes no misleading claims about inputs.

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 domain (systematic review / Meta) and two activities (literature screening and extraction) plus a 'systematic review framework', so the topic is identifiable. But it never states what the tool actually does — there is no verb describing the operation or the artifact produced (a framework prompt? a checklist? a workflow?). It is also a near-restatement of the title '系统评价辅助', leaving the agent to infer that this is a generic guidance/scaffold tool.

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 '用户要做系统评价/Meta 的文献筛选与提取' implies the trigger condition: invoke this when the user needs systematic-review screening and extraction. That is a usable implied when-to-use signal, but there are no exclusions and no named alternatives, despite close siblings such as act_lit_digest, literature_search_pmc, prisma_flowchart, act_pdf_pico, and meta-analysis helpers like forest_plot or egger_bias_test that an agent must choose between.

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