[EPIC] Sovereign, Hybrid, and Non-Public Cloud Parity

Nobody has claimed this yet.

## Problem statement

Azure MCP Server and related MCP packages must operate consistently outside the Azure public cloud. Current gaps span sovereign cloud configuration, tenant and cloud selection, endpoint construction, service availability, authentication, packaging, and continuous validation. These gaps surface independently across Azure Government, Azure China, GCC, and Azure Arc, making parity difficult to measure and maintain.

## Vision

Users can deploy and operate supported MCP servers in sovereign, hybrid, and non-public environments using explicit cloud configuration, correct endpoints and identity authorities, documented capability boundaries, and continuously validated representative scenarios.

## Current open work

- [ ] microsoft/mcp-pr#297, complete the sovereign cloud test pipeline
- [ ] #3028, expose cloud and tenant configuration through MCP Bundles
- [ ] #3024, support the M365 MCP Server in GCC
- [ ] #2274, correct Azure China behavior across Redis, File Shares, and Event Grid
- [ ] #1591, support Azure Arc and hybrid environments

## Completed foundation

- #1593 evaluated non-public cloud support
- #1608 established government-cloud test tenant requirements
- #137 tracked the original Azure Government capability effort
- Recent sovereign-cloud fixes established patterns for endpoint, identity, and service-specific corrections

## Goals (in scope)

- Define the supported sovereign, hybrid, and non-public environment matrix
- Make cloud and tenant selection explicit across server, package, and deployment surfaces
- Validate authentication, endpoint resolution, telemetry, and representative data-plane operations
- Document intentional capability differences and unsupported services
- Run continuous tests that prevent public-cloud assumptions from regressing parity

## Non-goals (out of scope)

- Claiming parity for Azure services unavailable in a target cloud
- Hiding service-specific limitations behind success-shaped responses
- Treating every cloud-specific feature request as part of this epic without a shared parity outcome

## Success criteria

- [ ] A documented environment and service coverage matrix exists
- [ ] Supported packages and deployments expose the required cloud and tenant configuration
- [ ] Authentication and endpoint construction use the selected cloud consistently
- [ ] Representative sovereign-cloud scenarios run continuously
- [ ] Known service gaps return explicit, actionable behavior

## Dependencies

- Sovereign-cloud tenants, subscriptions, and CI infrastructure
- Microsoft identity authorities and Azure environment metadata
- Azure service availability and SDK support in each target cloud
- Packaging and deployment surfaces that expose cloud configuration safely

Start by reviewing the linked open work (#297, #3028, #3024, #2274, and #1591) and the completed foundation issues to understand existing parity patterns. Use the stated goals and success criteria as the definition of done: an environment matrix, explicit cloud and tenant configuration, consistent authentication and endpoints, continuous representative scenarios, and actionable service gaps.

Written by the indexing model from the issue text.