HTTP client sends handler exception messages back to the server #660

When a handler registered with on_server_request (for example the on_elicitation callback) raises, MCP::Client::HTTP#dispatch_server_request answers the server with "Internal error handling #{method} request: #{e.message}" (http.rb:1198-1206). Exception messages often contain local details such as file paths, host names or library internals.

The server side stopped sending exception messages to clients in #486, for #485. This is the same problem on the client side. ServerRequestError keeps its explicit message (http.rb:1192-1197), which is correct because the handler chose that text.

Repro

Run from the repository root with bundle exec ruby -I lib repro.rb:

require "mcp"
require "mcp/client/http"
require "webmock"
include WebMock::API
WebMock.enable!

url = "http://localhost:9292/mcp"
reply = nil
stub_request(:post, url).to_return do |request|
  body = JSON.parse(request.body)
  if body["method"] == "tools/list"
    events = [
      { jsonrpc: "2.0", id: "s1", method: "elicitation/create", params: { message: "Name?", requestedSchema: { type: "object", properties: {} } } },
      { jsonrpc: "2.0", id: body["id"], result: { tools: [] } },
    ]
    { status: 200, headers: { "Content-Type" => "text/event-stream" }, body: events.map { |event| "data: #{event.to_json}\n\n" }.join }
  else
    reply = body
    { status: 202 }
  end
end

transport = MCP::Client::HTTP.new(url: url)
transport.on_server_request("elicitation/create") { |_params| File.read("/etc/example-app/ui.yml") }
transport.send_request(request: { jsonrpc: "2.0", id: "1", method: "tools/list" })

p reply["error"]

Expected: a generic message, for example {"code" => -32603, "message" => "Internal error"}.

Actual:

{"code" => -32603, "message" => "Internal error handling elicitation/create request: No such file or directory @ rb_sysopen - /etc/example-app/ui.yml"}

Suggested fix

Send a fixed message such as "Internal error" (optionally with the method name) for unexpected exceptions, and make the exception available to the application locally, for example through a reporter callback or a log line. Keep the current behavior for ServerRequestError.