fix: sanitize Perplexity API error messages

[sebastiondev]

Summary

This PR prevents verbose upstream Perplexity API failure details from being returned to MCP clients.

Vulnerability: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor

Severity: Medium

Affected code: src/server.ts, primarily makeApiRequest, performChatCompletion, and performSearch.

Data flow: a remote MCP client invokes a tool, the server calls the Perplexity API, an upstream HTTP/network/JSON parsing error occurs, and the thrown Error message is propagated by the MCP SDK back to the client in result.content[].text. Before this change, that message could include raw upstream response bodies or raw exception text.

Fix

The client-facing errors now return stable, generic messages such as:

• Perplexity API error: <status> <statusText>
• Network error while calling Perplexity API
• Failed to parse JSON response from Perplexity API
• Failed to parse JSON response from Perplexity Search API

The detailed upstream body or exception text is still written to the existing server-side logger for operators, but it is no longer included in thrown errors that can be serialized back to MCP clients. This keeps diagnostics available without exposing provider internals, account details, traces, or other sensitive error content to remote callers.

Security analysis

This is exploitable because the HTTP transport can be exposed remotely, binds to 0.0.0.0 in the public start mode, and can allow broad origins. A remote MCP client can trigger upstream failures, for example with invalid credentials, malformed upstream responses, API errors, or network/parse failures. Since thrown tool errors are returned to clients by the SDK, raw upstream response bodies and exception messages become client-visible.

The fix mitigates that by separating operational detail from client-facing error text. Clients still receive enough information to understand that the API request failed, while sensitive details stay in server-side logs.

Before submitting, we attempted to disprove this by checking whether existing transport controls, access controls, or framework behavior prevented exposure. They do not: the MCP SDK returns thrown tool errors to the caller, and the server can be run as an unauthenticated public HTTP service, so the raw error text was reachable without equivalent privileged access.

Tests

Tested with:

npm test

Result: all tests passed (3 test files, 80 tests).

Additional regression coverage was added to verify that upstream response bodies, JSON parse exception details, and network exception details are not present in client-facing thrown errors.

cc @lewiswigmore