Document private MCP hosting support for App Service Private Endpoints versus internal Container Apps

Problem

The Template 19 testing guide explains Azure Functions/App Service networking scenarios, but users evaluating a private MCP server hosted on App Service still need a concise support matrix for Foundry Data Proxy reachability.

The key distinction is easy to miss:

• Container Apps in an internal environment can be reached over the injected VNet path.
• App Service/Functions VNet Integration controls outbound traffic.
• An App Service Private Endpoint controls inbound traffic and may not be equivalent to an internal Container Apps endpoint for Foundry-hosted tool calls.

This ambiguity leads users to assume that "VNet integrated" or "has a Private Endpoint" automatically means a private MCP endpoint is supported by Foundry Agent Service.

Suggested improvement

Add an explicit hosting/support matrix for private MCP and OpenAPI tools covering at least:

Please include the recommended pattern for customers whose existing MCP server is on App Service with a Private Endpoint, and state whether Container Apps is currently the preferred private hosting target.

Context

A clean Template 19 deployment with internal Azure Container Apps passed private DNS, direct MCP, and Foundry agent enumeration/invocation. A sanitized probe is available at:

https://github.com/doruit/foundry-private-mcp-probe

Start with the Template 19 testing guide and the sanitized probe at https://github.com/doruit/foundry-private-mcp-probe. Verify the three hosting patterns, including private DNS, agent MCP calls, HTTP status, and agent traces, then document the support matrix, current limitations, recommended App Service guidance, and whether internal Container Apps is preferred.