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

明确告知点击会真实发生在用户可见窗口，并提醒操作前应告知用户，体现了对副作用和用户可见影响的披露。由于没有 annotations，描述承担了全部责任，虽未提及可能引发的后续变化（如跳转、提交），但已含关键行为提示。

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?

描述简洁紧凑，使用条理化的列表说明目标写法，没有冗余信息。必要注意事项以一句独立警示句呈现，整体结构清晰。

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?

对于完成点击操作，描述覆盖了目标指定的所有方式、参数默认行为以及用户可见性警示。由于没有输出 schema，无需额外说明返回值。信息完整，足以指导代理正确调用。

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 覆盖 100%。描述额外详细解释了 target 的三种语法格式及其含义，并说明 index 的默认行为（不传则操作当前页），远超 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?

明确说明工具功能：在协作浏览器中点击目标（

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?

提供了目标书写格式（文本、row:N、CSS）和操作前的注意事项，但没有明确提及何时应使用本工具而非其他协作浏览器操作工具（如切换、读取、输入等）。缺少显式的替代方案区分。

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?

Description transparently explains the side effects: only the user page is closed, while the browser process and login state remain intact. This is helpful and goes beyond basic tool purpose.

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 a single, succinct sentence containing only relevant information with no fluff or redundancy.

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 action and lack of parameters/output schema, the description provides sufficient context for correct use, including the key behavioral constraint about login state.

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 has no parameters, and the schema coverage is complete. No parameter descriptions are needed, so this dimension defaults to a high baseline.

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?

Description clearly states the tool closes the collaboration window and distinguishes it from other cnki_co_* operations by specifying the scope (user page only). Verb and resource are explicit.

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?

No explicit guidance on when to use this tool versus alternatives like cnki_co_open or cnki_co_switch, but the behavioral note about preserving browser process and login state provides some contextual direction.

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?

The description discloses key behaviors: navigating the specified tab, defaulting to the user page, and waiting for manual CAPTCHA completion. These are important side effects for the agent to know, though it does not mention potential failures or timeouts.

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 concise, consisting of two clear sentences with no redundant information. It effectively communicates the core function and a critical behavioral note.

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 description is self-contained for the tool's purpose. It omits return values or error handling, but for a navigation command that waits on user interaction, this is acceptable. It does not differentiate from cnki_co_open, but that is not essential for local 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?

The schema already provides descriptions for both parameters. The description adds meaningful context by explaining the default behavior of the 'index' parameter (defaults to user page), enriching the parameter semantics beyond the 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 clearly states the action (navigate) and the target (specified tab, default user page) to a URL, and explicitly mentions CAPTCHA handling. It distinguishes the tool's primary function without ambiguity.

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 description does not provide guidance on when to use this tool versus alternatives like cnki_co_open or cnki_co_click. It only explains the mechanism, not the selection criteria.

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?

The description discloses that the window is visible, auto-login, persistent, and that repeated calls do not interrupt the user. It fully explains side effects and non-destructive behavior, even without annotations.

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 slightly verbose due to the protocol list, but each part is relevant and concise. The front-loaded main purpose is clear.

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 tool has no parameters and no output schema, the description fully covers what the tool does and its role in the collaboration workflow. Nothing essential 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?

No parameters are declared, so no parameter explanation is needed. The empty schema makes parameter semantics trivially complete, warranting the baseline score.

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 clearly states the tool opens a collaborative browser window (visible, auto-login, persistent) and identifies it as the starting point for collaboration mode. It distinguishes from sibling tools like cnki_co_close and cnki_co_switch.

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 implies this tool should be used first in collaboration mode and includes protocol rules for interaction, but does not explicitly contrast with alternative tools or specify when not to use it.

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?

The description is transparent about side effects: it states it is a read operation performed in the background and explicitly notes it will not switch the user's window focus. This assures safe usage with no destructive actions, and no annotations contradict this behavior.

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 concise and well-structured, using a bullet-like list to clearly present the three possible return types. It avoids unnecessary details and is easy for an agent to parse and act upon.

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 description provides sufficient context for typical usage, including return types, default tab behavior, and the background nature. It does not address edge cases like invalid tab indexes or unrecognized page types, but these are not critical for an agent's effective use of the 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?

The input schema already fully describes both parameters (index with default current tab, max_chars with default 6000). The description does not add extra semantic information beyond what the schema provides, so a baseline score of 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 clearly states the tool's function: to read the content of a specified tab (default current tab) in a collaborative browser, and it explicitly lists the structured return formats for different page types. It distinguishes itself from sibling tools by highlighting it is a background operation that does not switch the user's focus.

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 description provides a strong differentiator—it operates in the background without changing focus—and indicates it reads from a tab, which implicitly guides when to use it (e.g., to extract content while keeping the user's view unchanged). However, it does not explicitly contrast with sibling tools like cnki_co_switch or cnki_co_click.

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 provided, the description itself carries the burden. It uses '查看' (view), which indicates a read-only, non-mutating operation. However, it does not explicitly state that no side effects occur, so a small deduction is applied.

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 concise and well-structured, consisting of two short sentences that communicate the resource, action, and use case without any fluff.

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 description provides sufficient context for a simple status tool: it names the resource (collaboration mode status), the attributes it checks (window open, visibility, tabs), and when to use it. Since there is no output schema, it does not need to detail the response format, but a brief mention of the output structure could make it more complete.

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 has zero parameters, and the schema coverage is complete (no parameters to describe). According to the scoring guideline, 0 parameters warrants a baseline score of 4, and no additional parameter description is needed.

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 clearly states the tool's purpose: to view the current status of collaboration mode, listing specific elements (window open, visibility, tabs). It distinguishes itself from sibling tools like cnki_co_switch or cnki_co_read, which are actions rather than status checks.

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 description explicitly advises using this tool when unsure about the window state ('适合在不确定窗口状态时先查一下'), providing a clear use condition. It does not explicitly contrast with alternatives, but the condition is sufficient 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?

With no annotations, the description must disclose behavior itself. It states the main effect (foregrounding a tab) and adds 'window focus follows,' which is a behavioral detail. However, it does not mention edge cases like invalid index handling (though that may be considered minor for a simple action).

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 one concise sentence, directly stating the action and the focus-following behavior. No unnecessary words or redundancy.

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 tool's simplicity and lack of output schema, the description covers the essential aspects: purpose and parameter meaning. It does not explain error behavior or return values, but these are not required for such a basic action and the description is sufficient for an agent to invoke it correctly.

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 sole parameter 'index' has a clear description: tab number starting from 0, with a reference to cnki_co_tabs for context. This fully explains the parameter's meaning and usage, exceeding basic schema coverage by providing cross-reference.

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 clearly states the tool's purpose: to bring a specified tab to the foreground and follow window focus. It uses specific verb 'switch' and identifies the resource ('specified tab'), and it is distinct from sibling tools like cnki_co_tabs (list tabs) or cnki_co_open (open new tab).

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 description does not explicitly state when to use this tool versus alternatives. It implies usage when a tab needs focus, but lacks explicit guidance such as 'use when you need to activate a tab' or conditions that would make this tool preferable over others.

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 implies a read-only operation by saying 'list', but does not explicitly state that it has no side effects or does not modify state. However, the wording strongly suggests it.

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 concise and free of unnecessary words. It efficiently conveys the purpose and the usage hint in two 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?

Given no parameters and no output schema, the description sufficiently describes what the tool returns (index, title, URL, focus) and provides contextual guidance for when to use it, making it complete for an agent.

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 has no parameters, so a baseline score of 4 is applied. The description does not need to explain parameters, and it correctly omits them.

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 clearly states the tool lists all tabs in the collaborative browser, specifying the fields (index, title, URL, focus status). It distinguishes from sibling tools like switch, read, and click by focusing on listing.

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 provides a usage scenario: when the user asks to 'see the Nth tab', call this tool first to confirm the index. This gives clear guidance on when to use it.

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 convey behavior. It states the action (input text) but does not describe side effects, such as overwriting existing content, focusing the input, or triggering search. The absence of destructive hints makes it safe, but details are minimal.

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 a single, concise sentence that covers the core action and the parameter defaults. No unnecessary words or redundancy, making it highly efficient.

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 simple input action, the description provides sufficient context: what it does, default target, and custom selector option. It does not mention return values or validation, but given the simplicity and lack of output schema, this is adequate.

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 schema descriptions cover all three parameters (text, into, index) with no gaps. The description adds minimal extra value by explaining the default 'search' as the CNKI search box, which is already implied by the schema. Per guidelines, high schema coverage gives a baseline of 3.

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 clearly states the tool's function: entering text into an input box of a collaborative browser. It specifies the resource (collaborative browser) and the action, but does not explicitly contrast with sibling tools like clicking or reading, though the action is distinct enough.

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 description provides the default target (CNKI search box) and allows custom selectors, but does not explicitly state when to use this tool versus others, such as for typing versus clicking. The usage context is implied by the action, but no explicit alternatives are mentioned.

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 transparently describes the side effect of saving a file to the downloads/ directory and mentions the need for institutional login. It does not detail error handling or potential overwrites, but the core 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?

The description is concise, consisting of two short sentences within the tool description. It efficiently covers the input, action, output location, and a critical prerequisite without unnecessary wording. The structure is clean and direct.

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 simple download tool, the description is complete: it states what it does (download PDF), how (auto-click button), where it saves (downloads/), and a key condition (institutional login). No additional information is necessary for an agent to decide when to call it.

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 single parameter 'url' has a clear description in the schema: '知网文章详情页URL' (CNKI article detail page URL). The tool description repeats this, reinforcing the expected value. Schema coverage is 100%, and the description adds no ambiguity, though it also offers no extra details beyond the 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 clearly states the tool's purpose: downloading CNKI paper PDFs. It specifies the input (article detail page URL) and the action (auto-click download and save to downloads/). This distinguishes it from sibling tools like search or get_article, which have different functions.

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 description implicitly indicates usage by specifying the required input and the prerequisite of institutional login. It does not explicitly mention alternatives, but the distinct purpose makes it clear when to use this tool over others. The login requirement provides important context for when it can be used.

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 of behavioral disclosure. It does disclose the observable return contract ('返回标题、作者、摘要、关键词等'), which is the core behavior for a read-only retrieval tool. However, it omits failure behavior (malformed/unreachable URLs), whether CNKI subscription/login is a precondition, and any throttling or blocking considerations, all of which are material for this vendor.

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-load the purpose ('获取知网文章详细信息') and then pack input and output into a single follow-on sentence. There is no filler and no redundant restating of the tool name, so it is an efficient definition.

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 it is a one-parameter tool with no output schema and no annotations, the description is mostly self-sufficient: it explains why the URL you need and what you should get back. The vague trailing '等' leaves the full returned field set to guesswork, and there's no hint of what happens when the URL is invalid, which prevents a perfect score.

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%; the url parameter is already described in the schema as '知网文章详情页URL'. The description reinforces that the URL must be an article detail page rather than a search page, which adds marginal meaning, but with full schema coverage and one trivial parameter the baseline of 3 is exactly right.

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-resource pair ('获取知网文章详细信息') and enumerates the expected outputs (标题、作者、摘要、关键词), so an agent understands exactly what the tool fetches. That the input is an article URL, not a query, distinguishes it from the cnki_search/cnki_professional_search siblings, but it earns a 4 rather than a 5 because it never explicitly differentiates itself from the similarly URL-driven sibling cnki_get_citations.

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 guidance is only implied: stating '输入文章URL' implies the tool is appropriate once a specific article URL is already in hand, typically after a search. However, there is no explicit when-to-use vs when-to-avoid framing and no mention of alternatives such as cnki_get_citations or cnki_download, so the agent has to infer routing from the tool 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?

No annotations are provided, and the description does not disclose any behavioral details such as read-only nature, potential rate limits, authentication requirements, or side effects. Without this information, an agent cannot anticipate operational constraints or error conditions.

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 concise, consisting of two sentences that efficiently state the purpose, input, output, and optional parameter. No unnecessary information is included, and the structure is clear and direct.

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 absence of an output schema and annotations, the description provides sufficient context for basic use: it explains what the tool does and what inputs are needed. It does not describe the return format, but this is not strictly required for invoking the tool. Minor omission is the lack of detail on how the returned citation data is structured, but this is not critical for 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?

Both parameters are thoroughly explained. The description defines 'url' as the article detail page URL and 'tabs' as the citation types, listing all possible values and the default. This adds meaning beyond the schema, which only repeats the same descriptions, by clarifying the default behavior.

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 clearly states the tool retrieves citation network information for CNKI papers, specifically references and cited literature lists. It uses the verb '获取' (get) and specifies the resource (article detail page URL), making the purpose unambiguous and distinct from sibling tools that handle searches or article details.

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 description implies usage for citation data retrieval, and the input URL and optional tabs parameter provide clear guidance. It does not explicitly contrast with sibling tools like cnki_get_article, but the specialized focus on citations makes appropriate usage inferable. Lacks an explicit 'when not to use' statement.

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 succeeds: it discloses that wrong operators may hang the search, that '暂无数据' can indicate risk-control blocking rather than no results, that timeouts can be retried with browser rebuild, and that parallel calls timeout.

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 long but well organized: syntax rules, examples, syntax-guide referral, and a numbered operational notice. The content is mostly high-value, though the year rule is emphasized more than once and the overall length is substantial.

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 syntax-driven tool with no annotations and no output schema, the description is remarkably complete. It covers field operators, correct expression forms, common failure modes, retry behavior, concurrency constraints, and where to get more syntax help, which is everything an agent needs to invoke it safely.

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 schema already covers both parameters, and the prose adds substantial value for expression: field-specific operators, quoting style, AND/OR/NOT composition, multi-field examples, and the YE BETWEEN warning. It adds nothing about max_results, but the default value and schema description are already sufficient there.

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 identifies the exact action: searching CNKI directly using CNKI professional search syntax. The field/operator rules and examples make the tool clearly distinct from sibling tools like cnki_search or cnki_search_with_abstracts.

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 description provides strong operational guidance: consult cnki_syntax_guide when unsure about operators and do not call other cnki tools in parallel. However, it does not explicitly state when to prefer this tool over alternative sibling search tools, so it stops short of 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?

Even though annotations are None, the description discloses critical behavioral aspects: it uses a real browser, may trigger verification pages requiring manual intervention, can hit rate limits (returning '暂无数据' or timing out), and describes retry strategies. This is highly transparent about the tool's runtime behavior and 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?

The description is well-structured: a concise opening sentence states the purpose, followed by a numbered list of usage notes. The notes are lengthy but essential due to the browser-based nature and rate-limiting caveats. Information is front-loaded and organized logically, with no redundant fluff.

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 complexity (real browser, potential verification, rate limits, timeout retries), the description covers all necessary operational context. It explains how to construct queries, what parameters to use, how to handle errors, and when to involve the user (verification). There is no output schema, so return values are not required, but all other relevant aspects are addressed.

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?

All 9 parameters are described in the schema, with detailed explanations for 'query' including examples and supported modifier fields (e.g., 作者:, 关键词:). The descriptions clarify each filter (author, organization, fund, year) and the 'field' enum values. Schema coverage is 100%, and the description adds extra context for the query parameter, leaving no ambiguity.

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 clearly states it searches CNKI academic literature with natural language support and lists applicable use cases (topic, keyword, author, institution, year). However, it does not explicitly distinguish from sibling search tools like cnki_professional_search or cnki_search_with_abstracts, so the purpose is clear but not fully differentiated.

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 description includes a detailed '使用须知' block with explicit guidance: avoid parallel calls, use year_from/year_to instead of manual YE BETWEEN expressions, handle rate limiting with retry, deal with verification pages, and cap max_results. This provides strong operational instructions and effectively tells when and how to use the tool.

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?

The description transparently states that it automatically fetches details and provides time estimates (40-60s vs 15-20s for 10 results), which helps set expectations. It does not explicitly mention read-only behavior or side effects, but given the search context this is not a major 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 compact and well-structured, using a short introductory sentence followed by a clear breakdown of modes, time costs, and shared parameters. No redundancy or unnecessary elaboration.

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 search tool with no output schema, the description sufficiently covers what the tool does, the optional modes, and performance expectations. It does not describe error handling or pagination, but these are not critical for basic usage and the description is otherwise complete.

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?

All 9 parameters are described, with clear explanations for filters like author, keyword, year range, and organization. Default values for mode and max_results are provided. While the Chinese descriptions are concise, they add meaningful context beyond the bare 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 clearly states that the tool searches CNKI academic literature and automatically fetches detailed information for each paper, distinguishing itself from cnki_search by promising enhanced detail retrieval. The two modes (full and basic) further clarify the scope of what is returned.

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 description explains when to use each mode based on the trade-off between detail (full) and speed (basic), and notes it shares parameters with cnki_search. However, it does not explicitly compare with cnki_professional_search or other siblings, leaving some ambiguity about when to prefer this tool over alternatives.

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 provided, the description carries the full burden of behavioral disclosure. It states the tool provides a syntax reference but does not describe the return format (text, structured data), any side effects (though it is inherently read-only), or limitations. The description is functionally transparent but lacks detail on what the agent will receive or any caveats.

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, well-structured sentence that front-loads the purpose and follows with a usage trigger. Every clause earns its place, with no redundant wording.

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 zero-parameter, no-output-schema reference tool, the description covers the essential points: what the tool returns and when to call it. It does not specify the output format, but for a syntax guide, the agent can reasonably infer it receives textual reference material. Minor gap: could mention the output is parseable or structured, but not critical.

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 has 0 parameters, so the baseline is 4. There is nothing for the description to add about parameters, and the description correctly focuses on the tool's purpose rather than parameters.

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 uses a specific verb (获取/get) and resource (CNKI专业检索表达式的完整语法参考), and explicitly lists the types of syntax it covers (field codes, operators, descriptors). It clearly distinguishes itself from sibling search and action tools by being a reference guide rather than a search operation.

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 description gives an explicit when-to-use instruction: '在构造复杂检索表达式之前' (before constructing complex search expressions), making the trigger condition clear. It does not explicitly mention when not to use it or name alternatives, but its role as a prerequisite for search expression construction is unambiguous.

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