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

With no annotations at all, the description carries the full burden; it does disclose the important trait that the download depends on a local persistent SSO session and institutional authorization. It does not disclose side effects (writes a file to disk), failure behavior when the session expires or entitlement is missing, or whether a verification window may open (relevant given the open_verification_window sibling).

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?

A single compact sentence with no filler, and the key constraint (authorized via persistent SSO) is front-loaded. It is efficient but so terse that it omits behavior an agent needs, leaving little structure to build on.

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 values need not be described, and both required parameters are fully documented in the schema. Still, for a tool that mutates the filesystem and depends on live authentication, the description should say what happens on auth failure or when the PDF is already cached — gaps that matter given siblings like list_cached_papers and renew_session.

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 the schema already explains that 'paper' is a label from search_cnki and 'save_dir' must be an absolute path. The description adds no parameter-level meaning beyond that, 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?

The description names a specific verb and resource ('下载…CNKI PDF 文件') and adds the retrieval mechanism (local persistent SSO session). An agent can tell it downloads a single PDF for one paper, though it never explicitly contrasts itself with the sibling download_papers_batch or read_paper_pdf.

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 clause '机构已授权的' implies the precondition that the user must have institutional entitlement, which is useful routing context. However, there is no explicit when-to-use vs. download_papers_batch / read_paper_pdf / list_cached_papers guidance, and no statement of what to do when unauthorized.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses the cache-skip behavior, but says nothing about what happens on partial failures, that downloads may trigger verification (a concern the schema hints at), or what auth/session state is required.

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?

A single compact sentence with the batch capability front-loaded and the cache behavior as a secondary clause. No filler, nothing to cut.

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 values needn't be explained, and the three parameters are fully documented in the schema. However, for a networked batch download that can hit verification walls and requires a session, the description omits failure and auth context that an agent would need to plan around.

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 three parameters including concurrency limits and the verification caveat are already documented in the schema. The description only restates the cache-skip rule, adding nothing beyond structured data; 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 resource ('批量下载 PDF') plus batch scope ('一次调用完成多篇'), which implicitly separates it from the single-file sibling download_paper_pdf. It never names the sibling explicitly, so differentiation relies on the word '批量'.

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?

Usage is implied by '一次调用完成多篇' — use this when you have multiple papers. There is no explicit when-not guidance (e.g., use download_paper_pdf for a single paper) and no prerequisites such as login state mentioned, despite siblings like get_login_status and open_verification_window.

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

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

With no annotations, the description carries the full burden, and it discloses useful traits: it works purely locally with no network access, it renames files by a deterministic year_author_title scheme, and it explains that the cache stores hash names — the reason the export exists. It still does not say what happens when a paper is not cached, when the output directory already contains files, or what the return looks like, but the disclosures it does make are valuable.

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?

Two short paragraphs, front-loaded with the core operation and then the motivation. Every sentence earns its place and there is no filler, though the second paragraph is largely rationale rather than operational detail.

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?

For a 2-parameter tool whose parameters are fully documented, with an output schema, and with no safety annotations needed beyond 'local, no network', the description is nearly complete. It gives what the tool does, why it matters, and where the output goes; only edge-case behaviour (what happens when a paper is not cached) 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 both parameters are already fully documented — the paper labels (cnki:… / zotero:…) and the default output directory. The description adds no extra syntax or format details about them, so the baseline of 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 states a concrete verb and resource: it copies cached paper PDFs, renames them to '年份_作者_标题.pdf', and writes them into one folder. The line '纯本地，不联网' tells an agent it is a local file operation, which separates it from the network-downloading sibling tools such as download_papers_batch and download_paper_pdf.

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 a clear context for use: when the paper is finalised and the references must be handed to someone else, creating a plain 'list of citations'. It does not explicitly state when not to use it or name the sibling it replaces (for example, download_papers_batch when the PDFs are not yet cached), so the guidance is solid but incomplete.

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

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

No annotations exist, so the description carries the full behavioral burden, yet it only says the lookup is 'quick/快速'. It does not state whether matching is exact or fuzzy, whether it is a pure read with no side effects, or how ties/no-match cases behave — all relevant given siblings like open_verification_window and the download/cache tools.

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?

One short sentence with zero waste and the matching criterion front-loaded. It is efficient but borders on under-specification rather than achieving tight completeness.

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 values need not be explained, and there is only one well-documented parameter. Still, with no annotations and 16 siblings, the description should at minimum say this is a read-only best-match lookup and how it differs from search_cnki.

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 coverage is 100% and the sole parameter already documents itself as '论文标题', so the schema does the heavy lifting. The description's phrase '输入标题' merely restates that, adding no constraints on length, formatting, or whether the full title is required.

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 resource ('CNKI 论文'), so the agent knows it returns the single closest paper rather than a list. It does not name or contrast with the obvious sibling search_cnki, so the agent must infer the difference between 'best match' and 'search'.

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?

Usage is only implied: 'with an input title' suggests using it when you already have a title and want one exact paper. There is no explicit when-to-use vs. search_cnki / get_paper_detail, and no statement about what happens when no match is found.

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

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

With no annotations, the description carries the full burden, and it does add one genuinely useful behavioral fact: it never returns cookies, tokens, accounts, or passwords, which stops an agent from fishing for credentials. It does not disclose whether the check is purely local or triggers a browser/network call, nor any rate-limit or side-effect profile, so the disclosure is partial.

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?

Two short clauses, front-loaded with what is checked and followed by the key privacy guarantee. Every clause earns its place and nothing is padded.

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 values need not be explained, and with zero parameters the surface is small. What remains thin is the operational context: no statement of when to call it relative to renew_session or whether the call has side effects.

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 tool takes zero parameters, so there is no parameter semantics to explain and the baseline of 4 applies. The description correctly adds no redundant parameter commentary.

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 (检查/check) and a specific resource (CNKI 持久登录状态/persistent login status), which is enough to separate it from read-oriented siblings like search_cnki or get_paper_detail. It does not explicitly contrast with the closest sibling, renew_session, so the boundary with session management is left implicit.

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?

There is no explicit when-to-use or when-not-to-use statement, nor any reference to alternatives such as renew_session or open_verification_window. Usage is only inferable from the purpose itself (check status before an authenticated operation), which is the definition of implied guidance.

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

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

No annotations are provided, so the description must carry the burden for behavioral transparency. It adds useful provenance and content information: this is the official CNKI export, supplemented with DOI, abstract, and keywords. However, it omits operational behavior such as whether an active session or login is required, whether some papers have no BibTeX, and whether results are cached.

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?

It is a single sentence that is front-loaded with the verb and resource. It contains no filler, and the parenthetical enrichment note earns its place by telling the agent what extra fields appear in the result.

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 it does not need to describe return values, and the description identifies the data source and the enriched fields. The only gap is context about how it fits with its siblings and whether a session is needed.

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?

There is only one parameter, and schema coverage is 100%; the schema already explains that 'paper' is the label field returned by search_cnki. The description adds no additional syntax, format, or sourcing guidance beyond that, so the baseline of 3 for high-coverage schemas 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?

It uses the specific verb 'get' (获取) with a precise resource, the BibTeX citation entry, and the scope, CNKI papers. It distinguishes itself implicitly from the other sibling tools by naming the output format and the enrichment it adds (DOI, abstract, keywords), though it does not explicitly name a sibling tool to differentiate itself.

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 '可直接复制到 .bib 文件中使用' (can be copied directly into a .bib file and used) implies that this tool is useful when inserting citations into a reference manager. However, it does not say when to choose this tool rather than get_paper_detail or export_papers, nor does it mention prerequisites or exclusions.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the two retrieval modes, but says nothing about pagination behavior, result ordering, rate/session constraints, or that paper labels must come from a prior search_cnki call (only the schema hints at this). For a zero-annotation tool this is a notable gap.

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?

A single compact sentence with the core operation front-loaded and no filler. However, it spends its only clause restating the kind enum that the schema already defines, rather than spending that space on usage or behavioral guidance.

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 full schema coverage and an output schema present, the description needn't explain return values, so the essentials for calling the tool are covered. But for a zero-annotation tool with a required paper label sourced from another tool, a hint about that dependency and pagination would materially improve completeness.

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 kind, limit, offset and paper are all documented in the schema itself. The description only restates the kind semantics that the schema already spells out, adding no formatting or value-range detail beyond it. 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 specific verb (获取/get) and resource (论文的参考文献/引证文献) and clarifies both directions — what the paper cites vs. who cites it — so the agent can distinguish it from a generic detail lookup. It does not explicitly name or differentiate against siblings like get_paper_detail, which keeps it below 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?

Usage is implied by the two-mode framing (references vs. citing), but there is no explicit statement of when to prefer this tool over get_paper_detail or search_cnki, nor any stated prerequisites. The agent must infer the call context.

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

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

No annotations are provided, so the description carries the full burden, yet it discloses nothing beyond the basic fetch intent. It does not say whether a live CNKI session or login is required (siblings like renew_session and get_login_status imply session-dependent tooling), whether a browser window is opened, or what 'complete information' covers.

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?

A single short sentence with no filler and the resource front-loaded. It is efficient, though its terseness is part of why the behavioral gaps exist.

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 values need not be explained, and the parameter is fully covered by the schema. However, with no annotations and no differentiation from several closely related siblings, the definition is only minimally sufficient for correct tool selection.

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 coverage is 100% and the single parameter is well documented in the schema, including that the label comes from search_cnki. The description adds no additional semantics, so the baseline of 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 resource: retrieving the complete information of a CNKI paper detail page. The intent is unambiguous, but it does not distinguish itself from siblings such as read_paper_fulltext, get_paper_citations, or get_paper_bibtex, which also return paper-level data.

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?

There is no guidance on when to use this tool versus read_paper_fulltext, read_paper_pdf, get_paper_citations, or get_paper_bibtex. No prerequisites or exclusions are stated, so the agent must infer the choice from the name alone.

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

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.

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

With no annotations, the description carries the full behavioral burden and does a good job: it explains that the window stays in front, does not need to be closed, and enables later requests in the same browser session to pass. It does not cover edge cases such as what happens if no browser session exists, but the key session-persistence behavior is disclosed.

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?

Two short sentences, front-loaded with the purpose and followed by the important post-completion behavior. Every sentence adds useful information with no waste.

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?

Given the simple zero-parameter interface, absence of annotations, and presence of an output schema, the description covers the essential purpose and session behavior. It could be slightly more complete by stating when a verification window is likely needed, but it is adequate for correct invocation.

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 tool takes zero parameters, so there are no parameter semantics to document; baseline 4 applies. The description appropriately does not add irrelevant parameter details.

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 states a specific action and resource: opening a CNKI verification window for manual slider or click-image verification. It is clearly distinct from sibling tools such as search_cnki or read_paper_fulltext, though it does not explicitly name alternatives or contrast itself with tools like renew_session.

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 a clear usage context: call this when CNKI requires manual slider or click-image verification. It does not explicitly state when not to use it or name an alternative tool, but the context is sufficiently clear for an agent to infer the situation.

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

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

With no annotations, the description carries the behavioral burden and does well: it explains the copy behavior, why it reduces verification risk, the fallback to an independent profile, and the Chrome-must-be-quit prerequisite. It does not disclose whether the source Chrome profile is modified or where the copied profile is stored, which leaves a minor transparency gap.

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 description is reasonably front-loaded: purpose, rationale, optionality, prerequisite, error handling, and alternative are ordered logically. There is slight repetition around the one-time nature, but it remains useful rather than bloated.

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 the description does not need to explain return values. For this simple zero-required-parameter setup tool, it covers the important operational context: optionality, fallback behavior, Chrome shutdown prerequisite, and retry condition. Minor missing context includes privacy implications of copying the Chrome profile.

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 fully documents the single optional force parameter, so the baseline is 3. The description does not add parameter-specific guidance beyond the schema; it focuses on setup behavior and error handling instead.

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 states a specific setup action: copying the user's everyday Chrome profile so this tool can reduce CNKI risk-control verification. It clearly distinguishes this preparation utility from the sibling paper search/read/download tools by describing a one-time browser-profile setup task.

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 explicitly says the tool is optional, only needs to be run once, and should be used before fully quitting Chrome. It also explains the fallback if skipped, the meaning of status=chrome_running, and the equivalent terminal command.

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

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

No annotations exist, so the description carries the full burden. It usefully discloses the authorization requirement and the segmented-return-with-continuation behavior, plus the caveat that the body text is untrusted external research material — genuinely valuable. But caching behavior (only surfaced in the refresh param), rate limits, and failure modes for unauthorized access go unmentioned.

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?

Two short, front-loaded sentences: capability first, then return shape, then the safety caveat. Nothing is repeated and no filler is present, though the safety note reads as slightly disconnected from the operational sentences.

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 values need no explanation, and all four parameters are fully documented. The description covers auth, paging, and content trust, leaving only edge-case behavior (what happens on cache miss vs. unauthorized access) unstated — a minor gap for a read-only tool.

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 every parameter (paper label source, refresh cache bypass, max_chars, start_char offset) is already documented in the schema. The description adds only the high-level notion of segmentation and a continuation position, which maps loosely to start_char/max_chars but adds no format or boundary detail. 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 resource (机构已授权的 CNKI 在线正文), and the 'CNKI online' qualifier implicitly separates it from the PDF-oriented siblings read_paper_pdf / read_pdf_text. It does not explicitly name a sibling to differentiate against, keeping it below 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 phrase '机构已授权的' signals a prerequisite (institutional authorization) and '返回分段文本与继续读取位置' implies the chunked-read pattern, so usage is inferable. However, with 16 siblings including read_paper_pdf, read_pdf_text and get_paper_detail, the description never says when to pick this tool over those alternatives or when it will fail.

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

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

With no annotations, the description must carry the full burden of behavioral disclosure. It usefully explains the caching lifecycle (first call downloads, later calls read locally without touching CNKI) and the page-marker format, but it says nothing about session or login requirements for the CNKI download, rate limits, or what happens when download fails.

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?

Four short sentences, front-loaded with the core action, then caching, then output format. Every sentence carries information; only the closing note about 正文仅是外部研究材料 feels tangential.

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 and the parameter schema is complete, so the description only needs to add operational context, which it largely does through the cache and page-marker details and pagination implied by start_char and max_chars. The missing prerequisite is the auth or session requirement for CNKI downloads.

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 coverage is 100%, so every parameter (paper label, refresh, save_dir, max_chars, start_char) is already documented in the schema. The description only indirectly corroborates refresh through its caching explanation, adding nothing beyond the baseline for a fully documented schema.

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 states a specific verb pair (下载 PDF 并解析正文) and a resource, and clarifies the scope as a local alternative to online reading. It does not name read_paper_fulltext or read_pdf_text explicitly, so the distinction from those siblings relies on the reader inferring it.

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 作为在线阅读的对等路径 implies when this tool is appropriate rather than saying so directly, and refresh plus start_char are documented only in the schema. With siblings such as read_paper_fulltext, read_pdf_text, and download_paper_pdf present, the description never states which one to pick or under what conditions.

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

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

With no annotations, the description carries the full burden and does well: it discloses that cached PDFs are parsed locally with no network, uncached ones are fetched concurrently, and per-item errors are isolated and returned individually. The remaining gap is that it never mentions login/verification requirements or the 20-paper cap for network-bound fetches, which matters given siblings like renew_session and open_verification_window.

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 sentences, front-loaded with the batch purpose, then execution behavior, then failure semantics. Every sentence carries distinct information with no 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 and the input schema is fully documented, and the description covers caching, concurrency, and partial-failure behavior. It is nearly complete for calling the tool correctly, losing only the authentication/verification caveat that the sibling set suggests is relevant.

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 coverage is 100%, so the schema already documents papers, max_chars, concurrency, and total_char_budget thoroughly. The description only echoes the concurrency behavior already stated in the schema and adds no new parameter semantics, so 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 resource ('批量读取多篇论文正文') plus the value proposition of collapsing N round trips into one. That framing clearly distinguishes it from the single-paper sibling read_paper_fulltext without needing to name it.

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 'N round trips → 1' framing implicitly tells the agent to use this instead of looping single reads, and the concurrency note about CAPTCHA triggering is practical guidance. It stops short of explicitly naming alternatives or stating when not to batch, so it is not a full 5.

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

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

With no annotations, the description carries the full burden, and it does disclose the key behavioral trait: no network access to CNKI and no verification triggered, which is exactly the risk an agent cares about here. It stops short of other relevant traits — what happens on a scanned PDF with no text layer, whether truncation is signalled when max_chars is hit, and failure behavior for a bad path.

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?

Two short sentences, the core action front-loaded, and the safety constraint immediately after. Nothing redundant or padded.

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 values needn't be explained, and the tool is simple. But the surrounding family contains two closely overlapping readers (read_paper_fulltext, read_paper_pdf) plus read_papers_batch, and the description gives no basis for choosing among them — the main missing piece for correct invocation.

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 file_path (absolute local path or cnki: tag), max_chars and start_char are all fully documented in the schema. The description adds only the implicit hint that file_path points at something already downloaded. 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 resource: read the body text of an already-downloaded PDF. The 'already downloaded' qualifier usefully scopes it. However, it never distinguishes itself from the near-identical siblings read_paper_fulltext and read_paper_pdf, so an agent cannot tell from this text which one to open.

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?

There is no explicit 'use this when…' or mention of the alternatives. The clause 'pure local operation, does not access CNKI, does not trigger verification' implies the usage condition (call this when you want to avoid hitting CNKI/anti-bot flows), but the agent must infer that and is given no routing rule against the sibling readers.

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

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

With no annotations, the description carries the full burden and does well: it discloses that the tool opens an interactive login window, that it must be called a second time with confirmed=true after the user logs in, and that passing school triggers an automatic SSO redirect rather than manual popup navigation. It does not say whether the call blocks, what happens if the user never completes login, or whether it is safe to repeat.

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?

Four short blocks with the call protocol front-loaded, followed by the failure symptom that motivates the tool and the off-campus guidance. Every sentence carries actionable content; only mild redundancy between the description and the schema's school description.

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?

For an interactive, side-effect-heavy tool with no annotations, the description covers the workflow, the diagnostic symptom, and the SSO behavior, and an output schema exists so return values need not be explained. The main gap is failure handling — what to do if login is never completed or the renewal fails.

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 both parameters are already documented in detail, so the schema does the heavy lifting. The description reinforces the two-step confirmed=true workflow and the off-campus rationale for school, but adds little semantic detail beyond what the schema properties already say; 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 opening line gives a specific verb and resource ('重新建立知网会话' — re-establish the CNKI session) and immediately describes the two-phase call protocol. It is clearly a session-repair tool, but it never names or contrasts with the near-siblings get_login_status and open_verification_window, which an agent must choose between.

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?

Strong, concrete triggering conditions: it states that expired CNKI cookies produce no visible prompt and surface only as download failures or an '机构没有额度' message, and that this tool should be used first in that case. It also prescribes the off-campus path (pass school). No explicit exclusions or named alternative tools are given, which keeps it below a 5.

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

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

With no annotations, the description carries the full disclosure burden. It does add genuine behavioral detail — that setting author/journal switches the backend to 专业检索, and that source_category is a result-sidebar group filter with no professional-search equivalent — but it never mentions that this is a browser-session operation needing a login (siblings renew_session and get_login_status imply that dependency) or anything about rate limits or failure modes.

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?

Purpose is stated first, then the critical parameter constraint, then examples — a good front-loaded order with no filler prose. It is slightly redundant with the schema's own query and author descriptions, but the repetition is defensible for a misuse-prone parameter.

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?

For a 7-parameter search tool with an output schema (so return values need no explanation), the description covers search semantics, filter composition, and the sidebar-vs-expression caveat ('其他条件…请优先用检索表达式'). An agent can construct a correct call from this plus the schema; the only missing piece is session/auth state, which is minor here.

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 coverage is 100%, so the baseline is 3; the description earns above that by repeating and reinforcing the highest-risk parameter rule (never put an author name in query) and by demonstrating parameter combinations in examples. Note the schema already documents sort/pages/search_type/source_category enumerations, so most added value is concentrated in the query-vs-author distinction.

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 opening sentence gives a specific verb and resource plus the return shape: search CNKI papers and return a paper list. The scope is unmistakable against retrieval-oriented siblings like get_paper_detail or read_paper_fulltext, but no sibling is named explicitly, so differentiation is inferred rather than stated.

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 explicit routing rules with a warning ('重要：query 参数只放主题/关键词/篇名，不要把作者名混入 query'), tells the agent which parameter to use instead, and notes that author and query can be combined. Two worked examples ('经济增长' + author='张三'; 'ESG' + source_category='北大核心,CSSCI') remove any remaining ambiguity about how to compose a call.

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