Responds to ping requests
Why it matters
MCP clients send ping requests to verify a server is alive before timing out a connection or showing an error to the user. A server that returns -32601 Method not found on ping tells the client it is disconnected, triggering reconnection logic or user-visible errors even when the server is running fine. A server that returns a non-standard value (e.g., the string "pong" instead of an empty object {}) breaks clients that validate response shape. Ping is cheap to implement correctly and expensive to get wrong.
Severity rationale
Low because a broken ping handler causes spurious connection errors and reconnection overhead but does not expose data or corrupt tool results.
Remediation
The MCP SDK handles ping automatically — do not override it. For custom implementations, add a case for ping that returns an empty result object.
// src/transport/handler.ts — ping handler
if (message.method === 'ping') {
return {
jsonrpc: '2.0',
id: message.id,
result: {} // empty object, not null, not 'pong'
}
}
Verify the ping handler is working by sending { "jsonrpc": "2.0", "method": "ping", "id": 1 } directly to your server and confirming the response is { "jsonrpc": "2.0", "id": 1, "result": {} }.
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the MCP Server Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
External references
- external · mcp-spec-ping — MCP Specification — Ping/pong utility method
Taxons
History
- 2026-04-18·v1.0.0·Initial import from mcp-server·automated