MCP SSE affinity intercepts the session ID from the first SSE response to route requests with the same session ID to the same instance. This ensures context consistency for hosted MCP Server scenarios.-Function Compute(FC)-阿里云帮助中心

MCP SSE affinity keeps all requests from the same Model Context Protocol (MCP) session routed to the same function instance. Without it, each request in a session may land on a different instance, breaking context continuity. The feature works by intercepting the session ID from the first Server-Sent Events (SSE) response and binding all subsequent requests carrying that session ID to the same instance.

When to use MCP SSE affinity

Use MCP SSE affinity when your function hosts an MCP Server that maintains per-session state — for example, a server that tracks conversation history, holds tool execution context, or accumulates intermediate results across multiple tool calls.

If your MCP Server is stateless (each tool call is independent with no shared context), you do not need to enable session affinity.

Limitations

Before configuring, review the following constraints:

Category	Constraint
Runtime support	Built-in runtimes do not support MCP SSE affinity. MCP runtimes support only MCP affinity (including SSE). Other runtimes have no restrictions.
Client requirement	Requests must come from an official MCP client or SDK. Non-standard clients cannot complete the handshake required to extract and carry the session ID.
Session lifecycle	A session's maximum duration equals the function's maximum timeout period. When the timeout is reached, the server disconnects. Reconnection generates a new session ID and is not guaranteed to route to the original instance.
Access method	Only HTTP triggers and custom domain names are supported.
Concurrency	When session affinity is enabled, Concurrency Per Instance is automatically set to 200 and cannot be changed. A persistent SSE connection uses one concurrency unit; each message request uses additional units. SSE connections and message requests share the 200-unit quota.
First SSE request	The first SSE request does not support query parameters.
SessionAPI management	Not supported.
General limits	See General limits and principles of session affinity for limits that apply to all session affinity types.

Prerequisites

Before you begin, ensure that you have:

A Function Compute function accessible via an HTTP trigger or custom domain name
Function code that implements the MCP protocol specification
An official MCP client or SDK for verification

Enable MCP SSE affinity

Log on to the Function Compute console.
In the function list, select a function or create a function.
When creating a function, configure Isolation and Affinity in the Advanced Configuration section before completing the creation.
On the function details page, click the Configuration tab.
In the Advanced Configuration section, click Isolation and Affinity to expand the panel.
Turn on the Session Affinity switch.
Select the MCP SSE Affinity radio button.
In the SSE Path text box, enter the path used to establish SSE connections.
- Default: /sse — use this unless your function code registers a different path.
- If you customize the path, keep it consistent with the path in your function code.
Set Concurrent Sessions Per Instance to the maximum number of sessions a single instance handles simultaneously. Start with a lower value (such as 10) for testing, then adjust based on observed load in production.
Setting
Value
Default
20
Range
1–200
Click Deploy.

After you establish an SSE connection with an official MCP client, the system automatically extracts the session ID and routes all subsequent requests in that session to the same instance.

Verify the configuration

Use the MCP Inspector to confirm that session affinity is working:

Start the MCP Inspector:

npx @modelcontextprotocol/inspector@latest

In the MCP Inspector, enter your function's HTTP trigger URL or custom domain name (for example, https://<your-domain>/sse), and click Connect.
Confirm that the inspector displays a session ID returned in the endpoint event. This session ID will be carried in all subsequent requests.
Run List Tools to send a follow-up request and confirm that it succeeds. A successful response confirms that the session is bound to an instance and affinity routing is working.

Alternatively, verify the SSE connection directly with curl:

curl -N https://<your-domain>/sse

The first response should be an endpoint event containing a sessionId:

event: endpoint
data: {"sessionId": "abc123", "version": "2025-06-18"}

FAQ

Affinity routing is not working after enabling MCP SSE affinity

The most common cause is that the client is not sending requests through an official MCP client or SDK. Non-standard clients cannot complete the handshake required to extract and carry the session ID.

Check the following:

Confirm you are using the official MCP client or SDK.
Check that the SSE path in the console matches the path in your function code — a mismatch prevents the system from intercepting the session ID from the initial SSE response.
Confirm your function code correctly implements the MCP protocol specification, including returning a valid endpoint event on the initial SSE connection.

Which SSE path should I use?

Use /sse (the default). This is the standard path for MCP SSE transport, and most MCP clients connect to /sse by default. Only customize it if your function code explicitly registers a different path.

Appendix: MCP SSE protocol reference

SSE event format

Field	Required	Description
`event`	Yes	Event type: `endpoint`, `message`, or `error`
`data`	Yes	Data body (JSON or text)
`id`	No	Unique event identifier; used to resume after disconnection
`retry`	No	Reconnection interval after disconnection, in milliseconds

Example:

event: endpoint
data: {"sessionId": "abc123", "version": "2025-06-18"}

How MCP uses SSE

MCP uses two separate channels:

SSE connection (GET /sse): A persistent connection that the server uses to push responses to the client.
HTTP POST requests: Short-lived requests the client uses to send commands.

All responses are returned through the original SSE connection, not the HTTP POST response body.

Typical request sequence

Client sends GET /sse — establishes a persistent SSE connection (Connection1).
Server returns event: endpoint, data: {"sessionId": "abc123"}.
Client sends POST /message?sessionId=abc123 (Connection2).
Server returns 202 Accepted (no body).
Server pushes the actual response through Connection1.
Client sends POST /initialized?sessionId=abc123 (Connection3).
Server returns 202 Accepted.
Client sends POST /list tools?sessionId=abc123 (Connection4).
Server returns 202 Accepted.
Server pushes the tool list through Connection1.
Client sends POST /call tool?sessionId=abc123 (Connection5).
Server returns 202 Accepted.
Server pushes the call result through Connection1.

Connection1 is the persistent SSE connection for receiving server-pushed responses. Connections 2–5 are the HTTP POST requests for sending instructions.

What's next

General limits and principles of session affinity
Build an MCP client — official MCP documentation
Create a function

Setting	Value
Default	20
Range	1–200