Read remote text file contents over SFTP from a Linux/Unix host, enforcing a 512KB default byte cap; larger files are rejected and should be downloaded instead.
读取远程主机文本文件内容（单次读取限制 512KB 防爆，超出建议下载）
| Name | Required | Description | Default |
|---|---|---|---|
| encoding | No | 文件文本解码字符集，默认 utf-8 | utf-8 |
| maxBytes | No | 最大读取字节数限制，默认 512KB (524288 字节)，超出则拦截并建议下载 | |
| remotePath | Yes | 远程文件绝对路径（必须以 '/' 开头） | |
| connectionId | No | 目标连接标识符，缺省时使用当前默认连接 |
Changes observed during successful MCP inspections.
v1.2.5Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses the hard 512KB read cap and that exceeding it triggers interception plus a download suggestion, which is real behavior beyond the schema. However, it says nothing about error behavior, binary/encoding failure handling, permission requirements, or what the call returns.
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 action front-loaded and the limit/fallback parenthesized after it. Every clause earns its place; nothing is redundant 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?
For a 4-parameter read tool with no annotations and no output schema, the description covers the critical size constraint but omits what the caller receives (text content string?), how binary or oversized content behaves in practice, and default-connection behavior. Adequate but with clear gaps.
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 four parameters (encoding, maxBytes, remotePath, connectionId) are already documented in the schema; this is the baseline case where the schema does the heavy lifting. The description's 512KB mention merely restates the maxBytes default/limit rather than adding new semantics.
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 ('读取远程主机文本文件内容'), so an agent immediately knows this reads a remote text file rather than writing, listing, or stat-ing one. It implicitly routes oversized reads toward the download sibling ('超出建议下载') but never names sftp_download explicitly, so it stops short of full sibling differentiation.
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 a clear use condition (reading remote text file content) and an implicit when-not: files exceeding the 512KB single-read limit should go to a download instead. There is no explicit prerequisite or connection guidance, but the boundary condition for choosing an alternative is present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.