asyncmcp provides custom transport implementations for the Model Context Protocol that enable non-blocking, queue-based, and webhook-driven communication patterns.

Why Async Transports?

Traditional MCP Limitations

Standard MCP transports (stdio, Streamable HTTP) follow a synchronous request-response pattern: This works well for immediate operations but becomes problematic for:
  • Long-running computations
  • Batch processing jobs
  • External API calls with variable latency
  • Resource-intensive operations

Async Transport Benefits

Non-Blocking

Clients can send requests and continue working while servers process asynchronously

Scalability

Distribute work across multiple workers and scale horizontally based on load

Reliability

Built-in message persistence and retry mechanisms ensure delivery

Decoupling

Clients and servers don’t need direct connections, reducing dependencies

How Async Transports Work

Async transports separate request submission from response delivery:

How asyncmcp Implements MCP Transports

Custom Initialization Protocol

asyncmcp implements custom initialization protocols to establish async transport connections. Each transport uses the params field in the initialize request to communicate transport-specific configuration:
The client includes its response queue URL in the initialize request:
{
  "jsonrpc": "2.0",
  "method": "initialize",
  "params": {
    "response_queue_url": "https://sqs.region.amazonaws.com/account/client-responses",
    "clientInfo": {
      "name": "example-client",
      "version": "1.0.0"
    }
  }
}
The server extracts this URL to send responses back to the client’s specific queue.

Session Management

Each transport maintains session state through:
  • Session IDs: Unique identifiers for each client connection
  • Client IDs: Persistent identifiers across reconnections
  • Protocol versioning: Ensures compatibility between client and server
These are transmitted via transport-specific message attributes (SQS/SNS) or HTTP headers (Webhook).

Next Steps