Allow bypassing proxy with Connection Type dropdown

[cliffhall]

Description

• In App.tsx

  • Add state for connectionType
  • Fetch connectionType from localstorage if present

• In Sidebar.tsx

  • Add dropdown for connectionType, only visible if transport type is not stdio

• In Sidebar.test.tsx

  • set connectionType to "proxy"

• In useConnection.ts

  • add connectionType param, defaulting to "proxy"
  • add state for mcpSessionId
  • Only check proxy health if the connection type is proxy
  • create a serverUrl variable which will either be the proxy url OR the server url depending upon the connection type
  • added captureResponseHeaders function to extract the protocol-related headers from a response.
  • when creating transport options and connectionType is "direct" and transportType is not "stdio",
    • add the appropriate Accept and Content-Type headers
    • capture the protocol related response headers and store them in the custom fetch handler
    • set serverUrl to be the server url, not the proxy url
  • if connection type is proxy set serverUrl to the mcpProxyUrl
  • use serverUrl instead of mcpProxyUrl for the transport instantiation

• In useConnection.test.tsx

  • replaced test "sends X-MCP-Proxy-Auth header when proxy auth token is configured" with two tests:
    • "sends X-MCP-Proxy-Auth header when proxy auth token is configured for 'proxy' connectionType"
    • "does NOT send X-MCP-Proxy-Auth header when proxy auth token is configured for 'direct' connectionType"
  • added Connection URL Verification section with 2 tests
    • uses server URL directly when connectionType is 'direct'"
    • "uses proxy server URL when connectionType is 'proxy'"

Motivation and Context

Multiple issues have been raised where the proxy has obfuscated what is actually going on with the server.

Checking the browser's network inspector tab doesn't help because it only shows the connection to the proxy, not what was actually sent to or returned from the server.

The Proxy is only actually necessary for STDIO connections, because it runs the server in a process. For SSE and StreamableHttp servers, the only hurdle for connecting directly from the browser is that the server must configure CORS to allow it.

So for developers who would like better insight into the traffic and don't mind configuring CORS on their server, this dropdown (which only appears for SSE and StreamableHttp Transport types) is a great way to cut out the middleman.

How Has This Been Tested?

I added CORS configuration to the Everything Reference server for its SSE and StreamableHttp transports.

Direct SSE Connection From Inspector

Direct StreamableHttp Connection From Inspector

Proxied SSE Connection From Inspector

Proxied StreamableHttp Connection From Inspector

Breaking Changes

Nope.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

Test against this PR on the Servers repo: modelcontextprotocol/servers#2725