SSH MCP Server

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

With no annotations provided, the description carries the full burden of behavioral disclosure and does so effectively. It describes timeout behavior, output truncation risks, memory concerns with unlimited output, default connection fallback, and detailed return structure including success status, exit codes, output streams, truncation flags, and error information. This provides comprehensive behavioral context beyond basic functionality.

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 perfectly structured and front-loaded with the core purpose first, followed by organized parameter explanations and return value documentation. Every sentence earns its place by providing essential information without redundancy. The bilingual format (Chinese purpose with English parameter names) is efficiently handled without wasting space.

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?

Given the complexity of remote command execution with 4 parameters, no annotations, and no output schema, the description provides complete context. It covers the tool's purpose, all parameter meanings with defaults and warnings, detailed return structure, and behavioral characteristics like timeout handling and output truncation. This is comprehensive for an agent to understand and use the tool correctly.

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?

With 0% schema description coverage, the description fully compensates by providing detailed semantic information for all 4 parameters. It explains what each parameter controls (command to execute, timeout seconds, output size limit with memory warnings, optional connection name with default behavior), including default values, special cases (0 for unlimited), and practical implications. This adds significant value beyond the bare schema.

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 specific action ('在远程服务器上执行shell命令' - execute shell commands on remote servers) and distinguishes it from siblings like check_ssh_connection (verification), download_file/upload_file (file transfer), list_directory (browsing), and execute_interactive_command (interactive execution). It precisely identifies both the verb (execute) and resource (shell commands on remote servers).

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 provides clear context about when to use this tool (for executing shell commands on remote servers) and implicitly distinguishes it from execute_interactive_command by describing batch execution with timeout and output limits. However, it doesn't explicitly state when NOT to use this tool or provide direct comparison statements with alternatives like 'use execute_interactive_command for interactive sessions'.

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