ping
Verifies connectivity by echoing back the provided message, confirming the server is reachable and handling requests.
Instructions
Echo
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | No | Message to echo back |
Verifies connectivity by echoing back the provided message, confirming the server is reachable and handling requests.
Echo
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | No | Message to echo back |
Changes observed during successful MCP inspections.
v2.0.3Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, and it discloses nothing: no return format, no latency/connectivity semantics, no indication of what happens with an empty prompt. 'Echo' alone leaves the agent guessing about the tool's actual behavior.
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?
One word is technically concise but reflects under-specification rather than efficiency; there is no front-loaded purpose, scope, or context to structure. It saves characters at the cost of usability.
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 tool is trivial (single optional string, no output schema), so a short description could suffice, but even a minimal definition should state the purpose, such as a connectivity test. As written, the description is inadequate to guide correct invocation relative to the ping name vs echo behavior.
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%, with the single optional 'prompt' parameter documented as 'Message to echo back' with a default of ''. Per the baseline rule for high schema coverage, 3 is appropriate since the schema already does the work and the description adds nothing further.
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 is a single word, 'Echo', which restates the obvious behavior implied by the 'prompt' parameter without naming a resource or distinguishing it from siblings like 'Help' or 'timeout-test'. It conveys a vague notion of echoing input but gives no scope, format, or purpose beyond tautology.
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?
There is no indication of when to use this tool, when not to, or how it relates to alternatives such as 'Help' or 'timeout-test'. An agent cannot tell whether this is a health check, a connectivity probe, or a literal echo utility from the description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.