Checks SSH MCP service liveness, reports version info, measures communication latency, and echoes custom messages to verify connectivity.
测试 SSH MCP 服务的存活状态、版本信息与通信延迟
This tool declares no required parameters. Add optional parameters from the input schema as needed.
{
"id": 1,
"jsonrpc": "2.0",
"method": "tools/call",
"params": {
"arguments": {},
"name": "ssh_ping"
}
}| Name | Required | Description | Default |
|---|---|---|---|
| message | 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 burden, and it does disclose the observable behavior (liveness, version, latency) which hints at the response. However it says nothing about whether it is read-only, whether it opens a network connection, or what side effects the echoed message has, leaving real behavioral gaps.
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 front-loaded clause that states the resource and the three things it verifies, with zero filler. Nothing is redundant and nothing needs to be moved.
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 one-optional-parameter diagnostic tool with no output schema and no annotations, the description's enumeration of liveness/version/latency effectively conveys what comes back and is sufficient to call it. Only the echo parameter's purpose is left entirely to the schema.
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% and the single optional 'message' parameter is documented as an echo payload in the schema. The description adds no semantics for it, so the baseline of 3 applies with the schema doing the work.
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 names a specific verb (测试/test) and resource (SSH MCP 服务) and enumerates what it checks: liveness, version info, and latency. This clearly separates it from siblings like ssh_exec or sftp_* which act on remote hosts rather than the local service itself, though it never explicitly references an alternative.
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?
Usage is only implied: a health/latency probe is naturally used for diagnostics or connectivity checks before connecting, but the description never states when to call it versus ssh_connect or ssh_list_connections. No prerequisites or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.