Skip to content

Support/Best Path for Copilot Studio integration via on-prem data gateway #119

@zlucas-netapp

Description

@zlucas-netapp

Looking for guidance on the recommended approach for connecting ONTAP MCP to Microsoft Copilot Studio when the server is behind a corporate firewall and not publicly accessible.

We have a customer running ONTAP MCP on-premises who wants to integrate with Microsoft Copilot Studio. Since the server has a private IP (not internet-reachable), the native MCP wizard in Copilot Studio doesn't work — it requires a public HTTPS endpoint.

Microsoft documents a second path: using a Power Platform custom connector with an on-premises data gateway. The gateway relays HTTP traffic from Copilot Studio to the internal MCP server via Azure Service Bus. We've been working through this integration path and have hit issues around session management.

What we have observed so far:
1.The on-prem gateway successfully relays traffic to the ONTAP MCP server (confirmed via curl from the gateway machine)
2.Microsoft's custom connector spec uses the x-ms-agentic-protocol: mcp-streamable-1.0 Swagger extension to signal MCP support
3.After the initialize handshake, subsequent requests fail because the Mcp-Session-Id header doesn't appear to survive the round-trip through the custom connector → gateway → server → gateway → Copilot Studio pipeline
4.Microsoft's own reference MCP server for Copilot Studio runs in stateless mode (no session ID requirement)

Based on our research into the go-sdk, NewStreamableHTTPHandler accepts a *StreamableHTTPOptions parameter, and the MCP spec supports stateless servers that don't require Mcp-Session-Id tracking:

A --stateless CLI flag (or env var ONTAP_MCP_STATELESS) could allow users to opt into this mode when deploying behind gateways or proxy layers that don't preserve session headers.

We haven't been able to fully validate this end-to-end yet, so unsure if this is the correct fix or if there's a better-supported path. Would appreciate any input from the team on whether this is the right direction and something the MCP could support long term.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions