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

Annotations already establish readOnly=true, destructive=false, openWorldHint=false, and the description is consistent with that closed-world profile (a fixed in-site corpus of 1.53M PMC records). It adds genuinely non-obvious behavioral context beyond the annotations: results come back as a list including PMCIDs, and the retrieval is done by a real algorithm engine rather than LLM generation, which tells the agent the output is citable rather than synthesized.

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?

Extremely compact and front-loaded: corpus scope first, usage triggers second, return format third, reliability note last. No sentence is redundant, and the bracketed header lets an agent pattern-match the tool's domain at a glance.

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 no output schema, the description does supply the one thing that matters for interpretation — results are a literature list with PMCIDs — which is enough to call and consume the tool. It stops short of saying how many results come back by default, whether abstracts are included, or how this differs from the PubMed sibling, leaving meaningful gaps for an agent choosing among search tools.

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% for both parameters (q with an English-works-better note, limit), so the schema already carries parameter meaning. The description adds only the return-shape detail (list with PMCID) and says nothing about query syntax, ranking, or what limit defaults to — baseline 3 is appropriate.

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 specific verb+resource (文献检索 / literature search) and quantifies the corpus (站内 153 万篇 PMC), so an agent immediately knows what is searched and over what body of material. However, it never distinguishes itself from closely overlapping siblings such as act_pubmed_search, act_literature_overlap, or act_lit_verify_citations, so sibling disambiguation is left to guesswork.

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?

It gives usable positive triggers — '用户要找文献、找证据、看研究现状' (user wants to find literature, evidence, or the state of research) — which is real when-to-use guidance. But there are no exclusions or alternatives: with act_pubmed_search sitting right next to it, the description should say whether this replaces or complements external PubMed search; that is left entirely implicit.

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