ssh_stat

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

The description adds meaningful behavioral context beyond the readOnlyHint annotation: it discloses the SFTP lstat mechanics, the symlink-following behavior, and the server-side credential model. It also gives a security directive—'Never ask the user for a password'—which is valuable for agent behavior. No contradiction with 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?

Four short, purpose-driven sentences. The first sentence delivers the core purpose, the second adds a critical behavior, and the remaining sentences address credentials and server routing. Every sentence earns its place, and the structure is front-loaded and scannable.

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 definition is largely complete for a read-only stat tool: it explains the operation, symlink behavior, credential handling, and how to obtain the server alias. With no output schema, it does not explicitly describe the returned stat fields, but 'SFTP lstat' reasonably implies standard stat metadata; this is a minor gap rather than a critical omission.

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 50%: the server parameter is already described in the schema, but the path parameter has no schema description. The tool description helps by calling it 'a remote path' and explaining lstat semantics, but it does not add much detail about path formatting or expected values. This partially compensates for the schema gap but does not fully clarify parameter 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?

The description states a specific operation: 'Inspect a remote path through SFTP lstat on the selected server.' It also clarifies an important semantic detail—'The final symlink is not followed'—which distinguishes this from a plain read or list operation and helps separate it from siblings like ssh_read_file and ssh_list_dir.

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 explicit routing guidance: 'Use ssh_list_servers when the user has not supplied an exact configured alias.' This addresses a common precondition for selecting the tool. It does not, however, contrast ssh_stat with path-related siblings such as ssh_read_file, ssh_list_dir, or ssh_exec, so the when-not-to-use guidance is partial.

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