Check the current status of the CNKI collaboration window, including whether it is open, visible (headful), and list all current tabs. Use this to verify window state when uncertain.
查看协作模式当前状态：窗口是否打开、是否可见（有头）、当前所有标签页。适合在不确定窗口状态时先查一下。
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.2.1Does 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.