Overview
The asyncmcp proxy bridges standard MCP transports (StreamableHTTP/stdio) to asyncmcp’s asynchronous transports (SQS, SNS+SQS, Webhook). This enables existing MCP clients to connect to services running on async transports without modification.The proxy exposes a standard MCP StreamableHTTP endpoint and forwards requests to configured async backend transports, streaming responses back via Server-Sent Events (SSE).
When to Use
✅ Use the proxy when:- Existing MCP clients need to connect to async transport servers
- Gradual migration from sync to async transports
- Standard clients (Claude, Cursor) need async backend access
- Building new clients with direct async transport support
- Both client and server support the same async transport
- Low-latency requirements (adds proxy overhead)
Quick Start
Basic Usage
Configuration
Type of backend transport: “sqs”, “sns_sqs”, “webhook”, or “hybrid”
Configuration object for the selected backend transport
AWS clients or other backend-specific clients needed by the transport
Port for the proxy server to listen on
Optional authentication token for client connections
Running the Proxy
Command Line
Docker
Client Connection
Standard MCP clients connect using StreamableHTTP:Key Limitation
Session Correlation Challenge: The proxy has limited support for multiple concurrent sessions from the same proxy instance when using async transports.
The Problem
- Session IDs are generated by the server, not the client
- With async transports, responses arrive out of order
- Can’t reliably match initialize responses to proxy sessions
Impact
- Each proxy session needs its own backend connection
- Can’t share a single queue across multiple sessions
- Resource usage scales with concurrent sessions