List Cached Papers

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

With no annotations to lean on, the description carries the burden itself and discloses the important traits: fully offline, no CNKI access, and no network requests on the follow-up read paths. It doesn't cover result ordering, empty-result behavior, or size limits, keeping it short of a 5.

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?

Three short lines: what the tool returns, when to call it, and what to do with the results. The offline guarantee is stated up front rather than buried, and no sentence is 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?

An output schema exists, so return-shape detail is unnecessary; the description instead supplies the workflow context (call first, then read via file_path or read_paper_pdf). Minor gaps remain around result size and behavior when nothing matches, but nothing an agent needs to invoke it correctly is missing.

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 query and include_zotero are already documented in the schema, including the default of true for the latter. The description adds nothing about either parameter, so the 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?

States a specific verb (列出) and a precisely scoped resource: local papers from two named sources (CNKI cache + Zotero library). The clause 纯离线，不访问知网 immediately distinguishes it from the online sibling search_cnki.

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?

Gives an explicit trigger (查文献前先调用本工具) and then routes the agent onward: use read_pdf_text with the returned file_path, or read_paper_pdf for CNKI-cached entries. This names both the condition and the alternatives, which is rarer than a mere 'use this to list papers'.

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