What can mcp-remote do?

oauth-authenticated remote mcp server proxying, dual-transport mcp protocol bridging (stdio ↔ sse), session-based oauth token lifecycle management, mcp server discovery and connection pooling, client-to-server request routing with context preservation, transparent client authentication abstraction

mcp-remote

MCP ServerFree

Remote proxy for Model Context Protocol, allowing local-only clients to connect to remote servers using oAuth

Open Source

/ 100

6 capabilities

Capabilities6 decomposed

oauth-authenticated remote mcp server proxying

Medium confidence

Enables local-only MCP clients (like Claude Desktop) to securely connect to remote MCP servers by acting as an authentication-aware proxy that handles OAuth token negotiation and refresh. The proxy intercepts client connections, manages OAuth flows transparently, and forwards authenticated requests to the remote server without exposing credentials to the client, using a token-based session model.

Solves for

Connect a local Claude Desktop instance to an MCP server running on a remote machine without exposing the server directly to the internetUse MCP tools from a cloud-hosted server while keeping the client air-gapped or behind a firewallDelegate authentication responsibility to an OAuth provider rather than managing API keys in client configurationShare a single remote MCP server across multiple local clients with per-user OAuth credentials

Best for

Teams running MCP servers in cloud environments (AWS, GCP, Azure) with local development clients

Organizations requiring OAuth-based access control to MCP resources

Developers building multi-tenant MCP deployments where clients need isolated authentication

Requires

Node.js 16+ (typical for npm packages)

OAuth provider with client credentials (e.g., GitHub, Google, custom OIDC server)

Remote MCP server accessible over network (HTTP/HTTPS or stdio-over-network)

Limitations

Adds network round-trip latency for every MCP request (typically 50-200ms depending on network conditions)

OAuth token refresh adds blocking I/O during token expiration — no async token refresh mechanism documented

Requires OAuth provider configuration upstream — no built-in identity provider, only proxy layer

What makes it unique

Implements transparent OAuth token lifecycle management (acquisition, caching, refresh) within an MCP proxy layer, allowing MCP clients designed for local-only operation to authenticate against remote servers without client-side OAuth implementation. Uses stdio and SSE transport abstraction to support multiple MCP connection modes.

vs alternatives

Simpler than building OAuth into each MCP client or using a VPN/SSH tunnel, because it centralizes authentication at the proxy boundary and works with unmodified local MCP clients.

dual-transport mcp protocol bridging (stdio ↔ sse)

Medium confidence

Translates between stdio-based MCP connections (used by local clients like Claude Desktop) and SSE (Server-Sent Events) or HTTP-based remote connections, allowing clients designed for subprocess communication to transparently communicate with remote servers over HTTP. The proxy maintains separate transport state machines for each side and marshals MCP JSON-RPC messages between them.

Solves for

Connect a stdio-only MCP client to an HTTP-based remote MCP server without modifying the clientExpose a local stdio MCP server to remote clients over HTTP/SSE without rewriting the serverBridge between different MCP transport implementations (e.g., Anthropic's stdio standard vs custom HTTP servers)

Best for

Developers integrating legacy stdio-based MCP servers with modern HTTP-based infrastructure

Teams needing to expose local MCP tools to remote clients without rewriting either side

MCP ecosystem projects standardizing on HTTP while maintaining backward compatibility with stdio clients

Requires

Node.js with stream/events API support

MCP client supporting stdio transport (e.g., Claude Desktop)

Remote MCP server exposing HTTP/SSE endpoint

Limitations

SSE is unidirectional (server → client); bidirectional communication requires polling or WebSocket upgrade (not mentioned in docs)

Stdio buffering and message framing differences may cause edge cases with large payloads or rapid message sequences

No built-in message compression — large context payloads over HTTP incur full bandwidth cost

What makes it unique

Implements a protocol-agnostic message marshaling layer that decouples MCP semantics from transport implementation, allowing the same proxy to handle stdio ↔ SSE translation without duplicating MCP logic. Uses Node.js streams for backpressure handling and event emitters for transport state management.

vs alternatives

More flexible than hardcoding stdio-to-HTTP translation, because the abstraction supports adding new transports (WebSocket, gRPC) without rewriting the core proxy logic.

session-based oauth token lifecycle management

Medium confidence

Manages OAuth token acquisition, storage, and refresh within a session context, allowing the proxy to maintain authenticated state across multiple MCP requests without requiring the client to handle token management. Implements token caching with expiration tracking and automatic refresh before expiry, using a session identifier to correlate tokens with specific client connections.

Solves for

Automatically refresh OAuth tokens before they expire so client requests don't fail mid-sessionCache OAuth tokens in memory to avoid re-authenticating on every MCP requestIsolate OAuth credentials per client session so multiple concurrent clients don't share tokensTransparently handle OAuth provider token expiration without client-side retry logic

Best for

Multi-user MCP deployments where each client needs isolated OAuth credentials

Long-running MCP sessions where token refresh is inevitable

Teams using OAuth providers with short token lifetimes (< 1 hour)

Requires

OAuth provider supporting refresh token grant (e.g., authorization code flow with refresh token)

Client credentials (client_id, client_secret) for OAuth provider

Session identifier mechanism (cookie, header, or URL parameter) to correlate tokens with clients

Limitations

In-memory token storage is lost on proxy restart — no persistence layer documented

No distributed session store — token cache is local to proxy instance, breaks horizontal scaling

Token refresh is synchronous and blocking — concurrent requests during refresh may queue or timeout

What makes it unique

Implements session-scoped token lifecycle as a first-class concern in the MCP proxy, rather than delegating to a generic OAuth library. Tracks token expiration and proactively refreshes before client requests fail, reducing latency spikes from token refresh during active use.

vs alternatives

More user-friendly than requiring clients to handle OAuth refresh themselves, and more efficient than re-authenticating on every request, because it caches tokens and refreshes them proactively in the background.

mcp server discovery and connection pooling

Medium confidence

Maintains a registry of available remote MCP servers and manages connection state for each, allowing clients to discover and connect to multiple servers through a single proxy endpoint. Implements connection pooling to reuse established connections and avoid repeated handshakes, with health checking to detect and recover from stale connections.

Solves for

Discover available MCP servers from a central registry without hardcoding server URLs in client configConnect to multiple remote MCP servers through a single proxy endpointReuse TCP/HTTP connections to remote servers to reduce latency and resource usageAutomatically reconnect to a remote server if the connection drops mid-session

Best for

Multi-server MCP deployments where clients need dynamic server discovery

High-throughput MCP proxies where connection reuse significantly reduces overhead

Teams running MCP servers in Kubernetes or other dynamic infrastructure where server addresses change

Requires

Remote MCP servers with stable network addresses (or service discovery integration)

Connection pool configuration (pool size, timeout, health check interval)

Network connectivity from proxy to all remote servers

Limitations

Connection pool size is fixed at startup — no dynamic scaling based on load

Health checks add periodic network traffic; too-frequent checks waste bandwidth, too-infrequent checks miss failures

No load balancing across multiple instances of the same server — pool connects to a single endpoint

What makes it unique

Implements connection pooling as a transparent layer between MCP protocol handling and network I/O, allowing the proxy to manage connection lifecycle without exposing pool details to clients or servers. Uses health checks to detect failures and automatically reconnect, improving reliability for long-lived MCP sessions.

vs alternatives

More efficient than creating a new connection per request, and more reliable than relying on TCP keep-alive alone, because it actively monitors connection health and reconnects proactively.

client-to-server request routing with context preservation

Medium confidence

Routes MCP requests from local clients to the appropriate remote server while preserving request context (OAuth tokens, session IDs, request metadata). Implements request/response correlation to match responses to requests even when multiple requests are in flight, and handles request timeouts and error propagation back to the client.

Solves for

Forward MCP tool calls from a local client to a remote server and return results without losing contextHandle multiple concurrent requests from the same client without mixing up responsesPropagate errors from remote servers back to clients with full error contextImplement request timeouts to prevent hanging requests from blocking the proxy

Best for

High-concurrency MCP proxies handling multiple simultaneous client requests

Deployments requiring detailed request tracing and debugging

Teams needing to implement custom routing logic (e.g., round-robin across multiple servers)

Requires

Request/response correlation mechanism (e.g., JSON-RPC id field)

Timeout configuration (per-request or global)

Error handling strategy (retry, fail-fast, circuit breaker)

Limitations

Request correlation adds memory overhead — each in-flight request consumes memory for context tracking

Timeout handling is synchronous — no async timeout cancellation, may leave orphaned requests on remote server

Error propagation is best-effort — some network errors may not propagate cleanly back to client

What makes it unique

Implements request routing as a stateful layer that tracks in-flight requests and correlates responses, rather than treating each request as independent. Preserves OAuth tokens and session context across the routing boundary, ensuring remote servers receive authenticated requests with full client context.

vs alternatives

More robust than simple request forwarding, because it handles concurrent requests correctly and propagates errors with full context, reducing debugging time when requests fail.

transparent client authentication abstraction

Medium confidence

Abstracts away OAuth authentication details from the MCP client, making the proxy appear as a local MCP server that requires no authentication. Handles the OAuth flow (authorization code exchange, token refresh) transparently, so clients designed for local-only operation work unmodified against remote servers. Implements credential injection into outbound requests to remote servers.

Solves for

Use an unmodified MCP client (e.g., Claude Desktop) against a remote OAuth-protected serverHide OAuth complexity from client developers so they focus on MCP protocol, not authenticationSupport multiple authentication schemes (OAuth, API key, mTLS) without changing client codeEnforce authentication policy at the proxy boundary rather than in individual servers

Best for

Organizations deploying MCP to non-technical users who shouldn't manage OAuth tokens

Teams standardizing on a single authentication mechanism across multiple MCP servers

Developers building MCP clients that should work with both local and remote servers transparently

Requires

OAuth provider configuration (client_id, client_secret, token endpoint)

MCP client supporting the proxy's connection protocol (stdio or HTTP/SSE)

Mechanism to obtain initial authorization code (e.g., browser redirect, CLI prompt)

Limitations

Abstraction hides authentication details, making debugging harder when auth fails

Proxy becomes a single point of failure for authentication — if proxy is compromised, all clients are compromised

No per-request authentication override — all requests use the same OAuth token

What makes it unique

Implements authentication as a transparent proxy layer that clients don't interact with directly, rather than requiring clients to implement OAuth. Allows unmodified local-only MCP clients to work against remote OAuth-protected servers without code changes.

vs alternatives

Simpler for end users than managing OAuth tokens in client config, and more secure than embedding credentials in client code, because authentication is centralized and auditable at the proxy.

Capabilities are decomposed by AI analysis. Each maps to specific user intents and improves with match feedback.

Related Artifactssharing capabilities

Artifacts that share capabilities with mcp-remote, ranked by overlap. Discovered automatically through the match graph.

MCP Server25

mcp-auth

Plug and play auth for Model Context Protocol (MCP) servers

oauth 2.0 / openid connect server integration for mcpmcp protocol-aware token validation and session managementcredential exchange and token refresh orchestration

3 shared capabilities

MCP Server23

Neon

** - Interact with the Neon serverless Postgres platform

oauth server with token management and refresh flowdual-mode deployment with local and remote authentication

2 shared capabilities

MCP Server37

modelcontextprotocol

Specification and documentation for the Model Context Protocol

oauth 2.1 authorization framework with token management and validation

1 shared capability

MCP Server46

Neon MCP Server

Manage Neon serverless Postgres databases and branches via MCP.

oauth 2.0 authentication server for remote mcp clients

1 shared capability

MCP Server46

Cloudflare MCP Server

Manage Cloudflare Workers, KV, R2, and DNS via MCP.

dual-transport mcp endpoint with oauth 2.0 and api token authentication

1 shared capability

MCP Server30

@mcp-use/cli

The mcp-use CLI is a tool for building and deploying MCP servers with support for ChatGPT Apps, Code Mode, OAuth, Notifications, Sampling, Observability and more.

oauth 2.0 credential management and token refresh

1 shared capability

Best For

✓Teams running MCP servers in cloud environments (AWS, GCP, Azure) with local development clients
✓Organizations requiring OAuth-based access control to MCP resources
✓Developers building multi-tenant MCP deployments where clients need isolated authentication
✓Developers integrating legacy stdio-based MCP servers with modern HTTP-based infrastructure
✓Teams needing to expose local MCP tools to remote clients without rewriting either side
✓MCP ecosystem projects standardizing on HTTP while maintaining backward compatibility with stdio clients
✓Multi-user MCP deployments where each client needs isolated OAuth credentials
✓Long-running MCP sessions where token refresh is inevitable

Known Limitations

⚠Adds network round-trip latency for every MCP request (typically 50-200ms depending on network conditions)
⚠OAuth token refresh adds blocking I/O during token expiration — no async token refresh mechanism documented
⚠Requires OAuth provider configuration upstream — no built-in identity provider, only proxy layer
⚠Single proxy instance becomes a bottleneck; horizontal scaling requires load balancer and shared session store
⚠SSE is unidirectional (server → client); bidirectional communication requires polling or WebSocket upgrade (not mentioned in docs)
⚠Stdio buffering and message framing differences may cause edge cases with large payloads or rapid message sequences

Requirements

Node.js 16+ (typical for npm packages)OAuth provider with client credentials (e.g., GitHub, Google, custom OIDC server)Remote MCP server accessible over network (HTTP/HTTPS or stdio-over-network)Client supporting MCP protocol (Claude Desktop, custom MCP client, etc.)Node.js with stream/events API supportMCP client supporting stdio transport (e.g., Claude Desktop)Remote MCP server exposing HTTP/SSE endpointNetwork connectivity between proxy and remote server

Input / Output

Accepts: MCP protocol messages (JSON-RPC over stdio or SSE), OAuth authorization codes and refresh tokens, MCP server connection parameters (URL, authentication method), MCP JSON-RPC messages via stdio (newline-delimited JSON), HTTP SSE streams from remote server, MCP protocol initialization handshakes, OAuth authorization code (from initial authentication), OAuth refresh token (from provider), Session identifier (from client), Server registry (static config or dynamic discovery source), Client connection requests with server identifier, Health check responses from remote servers, MCP JSON-RPC request from client (with method, params, id), OAuth token and session context, Request metadata (timestamp, client IP, etc.), MCP requests from client (no authentication headers), OAuth authorization code (from initial setup), Remote server URL and authentication requirements

Produces: Authenticated MCP protocol responses, OAuth access tokens (cached in session), Proxied tool/resource responses from remote server, MCP JSON-RPC messages via stdio, HTTP SSE event streams, Proxied tool responses and resource listings, OAuth access token (cached in session), Token expiration timestamp, Authenticated MCP request headers, Pooled connection to remote server, Server availability status, Connection metrics (latency, error rate), MCP JSON-RPC response from remote server (with result or error), Error responses with context (timeout, network error, server error), Request metrics (latency, success/failure rate), MCP responses to client (transparently authenticated), Authenticated requests to remote server (with OAuth token in headers or body)

UnfragileRank

Adoption75%(30% weight)

Quality22%(25% weight)

Ecosystem45%(25% weight)

Match Graph10%(15% weight)

Freshness75%(5% weight)

UnfragileRank is computed from adoption signals, documentation quality, ecosystem connectivity, match graph feedback, and freshness. No artifact can pay for a higher rank.

Type: MCP Server

6 capabilities

Visit mcp-remote→

Package Details

npm

Registry

0.1.38

Version

279,209

Weekly Downloads

About

Remote proxy for Model Context Protocol, allowing local-only clients to connect to remote servers using oAuth

Alternatives to mcp-remote

IntelliCode50Extension

AI-assisted development

Compare →

GitHub Copilot Chat53Extension

AI chat features powered by Copilot

Compare →

GitHub Copilot52Extension

Your AI pair programmer

Compare →

Claude Code for VS Code52Extension

Claude Code for VS Code: Harness the power of Claude Code without leaving your IDE

Compare →

Are you the builder of mcp-remote?

Claim this artifact to get a verified badge, access match analytics, see which intents users search for, and manage your listing.

Claim this artifact →Verification via email

Get the weekly brief

New tools, rising stars, and what's actually worth your time. No spam.

Data Sources

mcp registry

Looking for something else?

Search →

Capabilities6 decomposed

oauth-authenticated remote mcp server proxying

Medium confidence

Solves for

Best for

Teams running MCP servers in cloud environments (AWS, GCP, Azure) with local development clients

Organizations requiring OAuth-based access control to MCP resources

Developers building multi-tenant MCP deployments where clients need isolated authentication

Requires

Node.js 16+ (typical for npm packages)

OAuth provider with client credentials (e.g., GitHub, Google, custom OIDC server)

Remote MCP server accessible over network (HTTP/HTTPS or stdio-over-network)

Limitations

Adds network round-trip latency for every MCP request (typically 50-200ms depending on network conditions)

OAuth token refresh adds blocking I/O during token expiration — no async token refresh mechanism documented

Requires OAuth provider configuration upstream — no built-in identity provider, only proxy layer

What makes it unique

vs alternatives

Simpler than building OAuth into each MCP client or using a VPN/SSH tunnel, because it centralizes authentication at the proxy boundary and works with unmodified local MCP clients.

dual-transport mcp protocol bridging (stdio ↔ sse)

Medium confidence

Solves for

Best for

Developers integrating legacy stdio-based MCP servers with modern HTTP-based infrastructure

Teams needing to expose local MCP tools to remote clients without rewriting either side

MCP ecosystem projects standardizing on HTTP while maintaining backward compatibility with stdio clients

Requires

Node.js with stream/events API support

MCP client supporting stdio transport (e.g., Claude Desktop)

Remote MCP server exposing HTTP/SSE endpoint

Limitations

SSE is unidirectional (server → client); bidirectional communication requires polling or WebSocket upgrade (not mentioned in docs)

Stdio buffering and message framing differences may cause edge cases with large payloads or rapid message sequences

No built-in message compression — large context payloads over HTTP incur full bandwidth cost

What makes it unique

vs alternatives

More flexible than hardcoding stdio-to-HTTP translation, because the abstraction supports adding new transports (WebSocket, gRPC) without rewriting the core proxy logic.

session-based oauth token lifecycle management

Medium confidence

Solves for

Best for

Multi-user MCP deployments where each client needs isolated OAuth credentials

Long-running MCP sessions where token refresh is inevitable

Teams using OAuth providers with short token lifetimes (< 1 hour)

Requires

OAuth provider supporting refresh token grant (e.g., authorization code flow with refresh token)

Client credentials (client_id, client_secret) for OAuth provider

Session identifier mechanism (cookie, header, or URL parameter) to correlate tokens with clients

Limitations

In-memory token storage is lost on proxy restart — no persistence layer documented

No distributed session store — token cache is local to proxy instance, breaks horizontal scaling

Token refresh is synchronous and blocking — concurrent requests during refresh may queue or timeout

What makes it unique

vs alternatives

mcp server discovery and connection pooling

Medium confidence

Solves for

Best for

Multi-server MCP deployments where clients need dynamic server discovery

High-throughput MCP proxies where connection reuse significantly reduces overhead

Teams running MCP servers in Kubernetes or other dynamic infrastructure where server addresses change

Requires

Remote MCP servers with stable network addresses (or service discovery integration)

Connection pool configuration (pool size, timeout, health check interval)

Network connectivity from proxy to all remote servers

Limitations

Connection pool size is fixed at startup — no dynamic scaling based on load

Health checks add periodic network traffic; too-frequent checks waste bandwidth, too-infrequent checks miss failures

No load balancing across multiple instances of the same server — pool connects to a single endpoint

What makes it unique

vs alternatives

More efficient than creating a new connection per request, and more reliable than relying on TCP keep-alive alone, because it actively monitors connection health and reconnects proactively.

client-to-server request routing with context preservation

Medium confidence

Solves for

Best for

High-concurrency MCP proxies handling multiple simultaneous client requests

Deployments requiring detailed request tracing and debugging

Teams needing to implement custom routing logic (e.g., round-robin across multiple servers)

Requires

Request/response correlation mechanism (e.g., JSON-RPC id field)

Timeout configuration (per-request or global)

Error handling strategy (retry, fail-fast, circuit breaker)

Limitations

Request correlation adds memory overhead — each in-flight request consumes memory for context tracking

Timeout handling is synchronous — no async timeout cancellation, may leave orphaned requests on remote server

Error propagation is best-effort — some network errors may not propagate cleanly back to client

What makes it unique

vs alternatives

More robust than simple request forwarding, because it handles concurrent requests correctly and propagates errors with full context, reducing debugging time when requests fail.

transparent client authentication abstraction

Medium confidence

Solves for

Best for

Organizations deploying MCP to non-technical users who shouldn't manage OAuth tokens

Teams standardizing on a single authentication mechanism across multiple MCP servers

Developers building MCP clients that should work with both local and remote servers transparently

Requires

OAuth provider configuration (client_id, client_secret, token endpoint)

MCP client supporting the proxy's connection protocol (stdio or HTTP/SSE)

Mechanism to obtain initial authorization code (e.g., browser redirect, CLI prompt)

Limitations

Abstraction hides authentication details, making debugging harder when auth fails

Proxy becomes a single point of failure for authentication — if proxy is compromised, all clients are compromised

No per-request authentication override — all requests use the same OAuth token

What makes it unique

vs alternatives

Simpler for end users than managing OAuth tokens in client config, and more secure than embedding credentials in client code, because authentication is centralized and auditable at the proxy.

Capabilities are decomposed by AI analysis. Each maps to specific user intents and improves with match feedback.

Alternatives to mcp-remote

IntelliCode50Extension

AI-assisted development

Compare →

GitHub Copilot Chat53Extension

AI chat features powered by Copilot

Compare →

GitHub Copilot52Extension

Your AI pair programmer

Compare →

Claude Code for VS Code52Extension

Claude Code for VS Code: Harness the power of Claude Code without leaving your IDE

Compare →

mcp-remote

Capabilities6 decomposed

oauth-authenticated remote mcp server proxying

dual-transport mcp protocol bridging (stdio ↔ sse)

session-based oauth token lifecycle management

mcp server discovery and connection pooling

client-to-server request routing with context preservation

transparent client authentication abstraction

Related Artifactssharing capabilities

mcp-auth

Neon

modelcontextprotocol

Neon MCP Server

Cloudflare MCP Server

@mcp-use/cli

Best For

Known Limitations

Requirements

Input / Output

UnfragileRank

Package Details

About

Categories

Alternatives to mcp-remote

Are you the builder of mcp-remote?

Get the weekly brief

Data Sources

mcp-remote

Capabilities6 decomposed

oauth-authenticated remote mcp server proxying

dual-transport mcp protocol bridging (stdio ↔ sse)

session-based oauth token lifecycle management

mcp server discovery and connection pooling

client-to-server request routing with context preservation

transparent client authentication abstraction

Related Artifactssharing capabilities

mcp-auth

Neon

modelcontextprotocol

Neon MCP Server

Cloudflare MCP Server

@mcp-use/cli

Best For

Known Limitations

Requirements

Input / Output

UnfragileRank

Package Details

About

Categories

Alternatives to mcp-remote

Are you the builder of mcp-remote?

Get the weekly brief

Data Sources