fix: return JSON-RPC errors from MCP route when server/transport construction fails

[Matt Van Horn (mvanhorn)]

Summary

JSON-RPC calls to the built-in MCP server no longer fail with an opaque InternalServerError. Construction failures in the MCP server or transport are now caught by the route's own error path and returned as spec-compliant JSON-RPC errors with the underlying message, so clients see what actually broke.

Why this matters

On v0.46.0 every POST /mcp call (initialize, tools/list) returned InternalServerError even with cdpConnected: true and a working raw CDP endpoint; the reporter in #1437 verified with curl that the failure is immediate on first request and hits every MCP client. That response shape matches the generic app.onError fallback in apps/server/src/api/server.ts, which fires because the POST / handler in apps/server/src/api/routes/mcp.ts constructed the MCP server and transport BEFORE its try/catch — any synchronous throw during construction (tool registration, connector wiring, transport options) bypassed the JSON-RPC error path entirely.

Changes

• Server and transport construction moved inside the route's existing try block, so construction failures log with request context, report with the route: mcp tag, and return a JSON-RPC error (code: -32603) carrying the underlying error message instead of the app-level fallback shape.

Testing

Extended the existing test suite (which already injects createMcpServer/createMcpTransport factories) with cases where each factory throws; asserts the response is a 500 JSON-RPC error object, not the app-level InternalServerError shape.

Fixes #1437

[greptile-apps]

PR author is not in the allowed authors list.