Implementing an MCP Client with Browser-based OAuth

What is Implementing an MCP Client with Browser-based OAuth?

A browser-based MCP client that implements end-to-end OAuth authorization with Streamable HTTP Servers, allowing developers to inspect the transport layer and messages exchanged with MCP servers. It is designed for developers working with MCP servers that require client authorization.

How to use Implementing an MCP Client with Browser-based OAuth?

Connect to a server through the Connect panel, which triggers the OAuth flow via the server's /authorize and /token endpoints. Once connected, list tools in the Tools tab, invoke them with input parameters in the Run panel, and inspect responses in the Inspect panel.

Key features of Implementing an MCP Client with Browser-based OAuth

• OAuthClientProvider that stores auth tokens in session storage
• Two-step connect: acquire token, then establish transport
• Lists tools available on the connected MCP server
• Calls tools with user-provided input parameters
• Inspects server responses from tool execution
• Simplified implementation inspired by MCP Inspector

Use cases of Implementing an MCP Client with Browser-based OAuth

• Testing MCP servers that require OAuth authorization
• Debugging the MCP transport and message flow
• Developing Streamable HTTP servers with client authorization
• Inspecting tool responses without a full Inspector setup

FAQ from Implementing an MCP Client with Browser-based OAuth

What MCP servers does this client work with?

Only servers that implement client authorization, specifically the /authorize and /token endpoints.

Does this client support prompts and resources?

No, listing and using prompts or resources has not been implemented yet—those tabs provide no content.

How is OAuth handled in the browser?

The OAuthClientProvider saves and retrieves auth information in session storage, so tokens persist within the browser tab session.

How does this differ from MCP Inspector?

This project borrows heavily from MCP Inspector but aims for a simpler, more focused implementation for OAuth-based workflows.

Does it require a backend or proxy server?

The README describes a purely browser-based client; no backend or proxy is mentioned for the OAuth flow or transport.