mcp: add ErrorHandler to ServerOptions

[ravyg]

Add an optional ErrorHandler callback to ServerOptions for receiving
out-of-band errors that occur during server operation but are not
associated with a specific request.

Error sources wired to the handler:

• Keepalive ping failures (previously silently dropped)
• Notification delivery errors (previously logged as warnings)
• Internal JSON-RPC protocol errors (previously printed via log.Printf)

When ErrorHandler is nil, existing behavior is preserved — errors are
logged at the appropriate level.

Thanks to @findleyr and @jba for the design discussion on this issue.

Fixes #218

[maciej-kisiel]

The issue this is addressing is waiting for community feedback. We're not planning to merge it before there is interest in it.

[jba]

Maybe we can just use the logger in all the places we currently drop the error. Then it's still reported, but we don't have to add any API.

[ravyg]

Thanks @jba and @maciej-kisiel for the feedback. Splitting this into two PRs based on @jba's suggestion above:

• mcp: log out-of-band errors instead of dropping them #887 (just opened) — the smaller, no-new-API version: routes the currently-dropped errors (keepalive ping failures, jsonrpc2 internal errors) through the existing *slog.Logger that Server and Client already guarantee non-nil. This addresses the concrete observability gap in Proposal: add ErrorHandler to ServerOptions #218 without expanding the public surface, and is exactly what @jba proposed.
• This PR (mcp: add ErrorHandler to ServerOptions #865) — kept open as the ErrorHandler callback proposal. Parking it pending community input on whether a structured callback API is also wanted on top of logging. Happy to close it out entirely if mcp: log out-of-band errors instead of dropping them #887 is sufficient and there's no further demand for a callback shape.

[ravyg]

Closing this out — #887 landed the logger-based fix for #218 that @jba proposed, which resolves the concrete observability gap (keepalive ping failures and jsonrpc2 internal errors are now reported via the existing *slog.Logger).

As I noted on 2026-04-09, I was keeping this open in case a structured ErrorHandler callback was also wanted on top of logging. No demand has surfaced in the week since #887 merged, and the logger-only route respects @maciej-kisiel's earlier guidance about not expanding API without community interest — so the callback isn't justified right now.

If anyone reading this later has a concrete use case where the logger isn't enough (metrics sink, custom alerting, programmatic test hook, etc.), please comment here or open an issue and I'm happy to revisit with a narrower proposal. The branch stays on my fork.

Thanks @jba and @maciej-kisiel for steering this toward the simpler design.