Reads a few source lines for a static clue after verifying the file hash, limiting access to unpacked directories already analyzed to prevent path escapes or changed files.
读取静态线索对应的少量源码行，先核对文件哈希。仅支持本工具实际分析过的、用户指定的已解包目录，拒绝路径越界和文件变更。
| Name | Required | Description | Default |
|---|---|---|---|
| context | Yes | ||
| node_id | Yes | ||
| study_id | Yes | 研究 ID，由 research_create 返回 | |
| analysis_id | Yes | ||
| observation_index | Yes |
Changes observed during successful MCP inspections.
v0.4.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds real behavioral context beyond that: hash verification before reading, restriction to previously analyzed unpacked directories, and explicit refusal of path escape and changed files. These are concrete safety and scope behaviors not encoded in the 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?
Two tight sentences, front-loaded with the core action (reading source lines) followed by the safety constraints. Little wasted text, though the parameter set is never addressed.
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?
Behavioral context (hash check, scope limits, rejection rules) is well covered, which is valuable for a no-output-schema tool, but with five required parameters at 20% schema coverage the definition leaves the agent guessing about how to supply valid inputs.
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 only 20% (only study_id is documented), yet the description explains none of the five required parameters — node_id, analysis_id, observation_index, and context are left entirely undefined. For a five-parameter tool with poor schema coverage, the description does not compensate.
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: reading a small set of source lines for a static clue, with hash verification first. This is clearly distinguishable from siblings like research_document_chunks or research_find_nodes, though it does not explicitly name an alternative tool.
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 meaningful preconditions — only directories this tool has already analyzed and that the user specified — and states that path traversal and file changes are rejected. However, it does not tell the agent when to prefer this over other read-style siblings, so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.