Copilot Studio Custom Connector - How to persist MCP Session ID header between actions?

(0) Share

Report

Posted on by DN-15062022-0

Hi everyone,

I’m integrating a remote vendor MCP server with Microsoft Copilot Studio using a Power Platform Custom Connector.

Current status:

The initialize MCP call succeeds.

Copilot Studio can successfully invoke the connector.

Vendor receives the request and returns a valid response.

The MCP server returns an mcp-session-id response header.

The issue occurs on subsequent MCP calls such as:

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/list",
  "params": {
  }
}

These calls fail with:

HTTP 403 Authorization Error
ConnectorAuthorizationError

According to the MCP server vendor, every request after initialize must include:

mcp-session-id

as a request header.

I created separate actions:

POST /initialize
POST /message

and exposed the response header in Swagger:

responses:

 '200':

   headers:

     mcp-session-id:

       type: string

However, I cannot find a supported way in Copilot Studio to:

Capture a response header from Action A (initialize)

Store it in agent memory/variables

Pass it as a request header to Action B (message)

Questions:

Has anyone successfully implemented an MCP protocol server that requires session header persistence in Copilot Studio?

Can response headers be mapped into agent variables?

Can a custom connector dynamically populate request headers from outputs of previous actions?

Is an Azure Function / APIM proxy the recommended approach for managing MCP sessions?

Architecture:

Copilot Studio

     ↓
Power Platform Custom Connector
     ↓
Third Party Vendor MCP Server

Any examples or guidance would be greatly appreciated.

Thanks!

Categories:

Calling actions from Copilot Studio

Model context protocol

I have the same question (0)

All responses (3)

Answers (0)

Sort by

Suggested answer

Assisted by AI

Sunil Kumar Pashikanti 2,318 Moderator on at

Like
a
(0)

Report
Copy link

Link copied!

Hi @DN-15062022-0,

The Root Cause

Copilot Studio and custom connectors work best with stateless APIs. They currently have a hard limitation: you cannot extract a custom header from an API response and dynamically map it into a variable to use downstream.

Even if you define the headers in your Swagger file, Copilot Studio cannot pass that session state across different actions.

Direct Answers

Can response headers be mapped to agent variables?

No, not natively today.

Can a custom connector dynamically populate request headers from outputs of previous actions?

You can pass inputs into request headers if they are explicitly defined as parameters, but since you cannot capture the response header from the previous step, you cannot pass it dynamically.

Is an Azure Function / APIM proxy the recommended approach for managing MCP sessions?

Yes. For any stateful or session-based protocol like Model Context Protocol (MCP), an external layer is the standard pattern.

Recommended Architectures

Option 1: Use an Azure Function or APIM Proxy (Best Practice)

Let a proxy layer handle the state. Copilot Studio talks to the proxy, and the proxy manages the session with the MCP server:

Copilot Studio > Custom Connector > Azure Function > MCP Server

The Azure Function handles the initialize call, catches and stores the mcp-session-id, and automatically attaches it to all subsequent backend requests. Copilot Studio stays completely stateless.

Option 2: Return the Session ID in the Response Body

If you have control over the API design, ask the developers to return the mcp-session-id inside the JSON response body instead of the header. Once it is in the body, Copilot Studio can easily parse it, store it in a topic variable, and pass it as an input parameter to the next action.

Summary
The moment an API requires cross-call session continuity via headers, you need to lift that state management out of Copilot Studio. Go with the Azure Function proxy pattern for the cleanest, production-ready setup.

https://microsoft.github.io/mcscatblog/posts/mcp-custom-headers/

✅ If this answer helped resolve your issue, please mark it as Accepted so it can help others with the same problem.
👍 Feel free to Like the post if you found it useful.

Sunil Kumar Pashikanti, Moderator
Blog: https://sunilpashikanti.com/posts/

Was this reply helpful? Yes No
Suggested answer

Sayali-MSFT Microsoft Employee on at

Like
a
(0)

Report
Copy link

Link copied!

Hello @DN-15062022-0,

Based on the current documented behavior, I wouldn’t rely on Copilot Studio custom connector actions to persist mcp-session-id from the initialize response header and automatically pass it into later MCP requests. Custom connector policies can add or override headers, but I don’t see official documentation showing response-header-to-agent-variable-to-next-request-header mapping for this scenario. Since your vendor MCP server requires mcp-session-id on every request after initialize, the most reliable approach is to add an Azure Function/APIM/lightweight proxy between Copilot Studio and the vendor MCP server. The proxy can handle initialize, store the returned session ID per session/user, and inject it into all subsequent MCP calls such as tools/list or tools/call.
Also, where possible, use the Copilot Studio MCP onboarding wizard/streamable MCP path since that is the documented recommended MCP integration path.

Reference Document-
1. Connect your agent to an existing Model Context Protocol (MCP) server - Microsoft Copilot Studio | Microsoft Learn
2. Set HTTP Header | Microsoft Learn
3. Make HTTP requests - Microsoft Copilot Studio | Microsoft Learn

Was this reply helpful? Yes No
Suggested answer

11manish 3,333 on at

Like
a
(0)

Report
Copy link

Link copied!
Copilot Studio cannot currently persist and replay arbitrary HTTP response headers (such as mcp-session-id) between connector actions.

This makes stateful MCP implementations difficult to implement directly through a standard Custom Connector.

I would strongly recommend moving to:

Copilot Studio + Custom Connector + Azure Function / APIM Session Broker + Vendor MCP Server

because today:

Response headers cannot be captured into agent variables.

Custom connectors cannot dynamically reuse response headers.

Copilot Studio does not support session persistence based on HTTP headers.

A stateful proxy (Azure Function or APIM) that manages the mcp-session-id on behalf of Copilot Studio is currently the most robust and recommended solution for

integrating stateful MCP servers with Copilot Studio.

Was this reply helpful? Yes No