read_paper_fulltextRead institutionally authorized CNKI full text in segments. Returns the text plus the position to resume from, so you can pull a paper's content for research.
读取机构已授权的 CNKI 在线正文；返回分段文本与继续读取位置。正文仅是外部研究材料。
| Name | Required | Description | Default |
|---|---|---|---|
| paper | Yes | 论文标签（从 search_cnki 返回的 label 字段） | |
| refresh | No | 为 true 时忽略本地正文缓存，重新访问知网 | |
| max_chars | No | 本次最多返回的字符数 | |
| start_char | No | 正文分段起始字符位置，从 0 开始 |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.32.0Does 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.