microsoft-foundry / microsoft-foundry/foundry-samples
mcpServerSettings is silently dropped for CustomContainer session pools — code-interpreter-custom sample cannot work
@achauhan-scc is already working on this.
Since Jul 29, 2026.
- Dominant language
- Bicep
- Stars
- 445
- Forks
- 494
- Avg merge
- 11h 35m
- Merged PRs (30d)
- 38
Description
Summary
The code-interpreter-custom sample (and the Custom code interpreter tool for agents doc that walks through it) deploys a Microsoft.App/sessionPools resource with containerType: 'CustomContainer' and mcpServerSettings: { isMcpServerEnabled: true }, then reads sessionPool.properties.mcpServerSettings.mcpServerEndpoint and calls fetchMCPServerCredentials.
In practice, the ARM RP accepts and silently drops mcpServerSettings for CustomContainer pools: the deployment succeeds, but a GET on the pool returns mcpServerSettings: null, mcpServerEndpoint is never issued, and fetchMCPServerCredentials fails with:
ERROR: Bad Request({"error":{"code":"SessionMCPServerNotEnabled","message":"Session pool '<pool>' does not have MCP Server enabled.","traceId":"fc0fd0d9859c929e74c91f49dbe563c0"}})
The identical mcpServerSettings block on a containerType: 'Shell' pool works immediately (MCP endpoint issued), so this is specific to the CustomContainer + MCP combination — the exact combination this sample is built on.
What we tested (2026-07-17)
SessionPoolsSupportMCP AFEC feature Registered, Microsoft.App provider re-registered (state Registered) well before all tests. All pools reached provisioningState: Succeeded.
| # | containerType | Region | API version | Created via | mcpServerSettings after deploy |
|---|---|---|---|---|---|
| 1 | CustomContainer | eastus2 | 2025-10-02-preview | Bicep (sample-equivalent template) | ❌ null |
| 2 | Shell | eastus2 | 2025-10-02-preview | ARM PUT (tutorial template) | ✅ enabled, mcpServerEndpoint issued |
| 3 | CustomContainer | eastus2 | 2025-10-02-preview | ARM PUT, fresh pool | ❌ null |
| 4 | CustomContainer | westus2 | 2025-10-02-preview | ARM PUT, fresh pool | ❌ null |
| 5 | CustomContainer | eastus2 | 2025-02-02-preview | ARM PUT, fresh pool | ❌ null |
Also ruled out:
- Property casing: both
isMcpServerEnabled(as in the sample'sinfra.bicep) andisMCPServerEnabled(as in the Container Apps MCP tutorials) behave identically — dropped on CustomContainer, honored on Shell. - Update vs. create: PATCH/PUT with
mcpServerSettingson an existing CustomContainer pool returns success (provisioningState: Succeeded) but the property remainsnull. Freshly created pools behave the same, so it is not an update-only limitation. - Region: reproduced in both eastus2 and westus2 (the region used in the tutorials).
- Other feature flags:
az feature list --namespace Microsoft.Appshows no other MCP-related gate;SessionPoolsSupportMCPis the only one and it isRegistered.
The CustomContainer test pools used the same image and configuration as the sample (mcr.microsoft.com/k8se/services/codeinterpreter:0.9.18-python3.12, the four SYS_RUNTIME_SANDBOX/AZURE_CODE_EXEC_ENV/AZURECONTAINERAPPS_SESSIONS_SANDBOX_VERSION/JUPYTER_TOKEN env vars, ingress targetPort: 6000).
Minimal repro
# Feature registered, provider re-registered beforehand:
az feature show --namespace Microsoft.App --name SessionPoolsSupportMCP --query properties.state # Registered
az provider show -n Microsoft.App --query registrationState # Registered
# Shell pool — MCP works:
az rest --method put \
--url "/subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.App/sessionPools/mcpshell?api-version=2025-10-02-preview" \
--body '{"location":"eastus2","properties":{"poolManagementType":"Dynamic","containerType":"Shell","scaleConfiguration":{"maxConcurrentSessions":5},"sessionNetworkConfiguration":{"status":"EgressEnabled"},"dynamicPoolConfiguration":{"lifecycleConfiguration":{"lifecycleType":"Timed","cooldownPeriodInSeconds":300}},"mcpServerSettings":{"isMCPServerEnabled":true}}}'
# GET afterwards -> "mcpServerSettings": { "isMCPServerEnabled": true, "mcpServerEndpoint": "https://eastus2.dynamicsessions.io/..." }
# CustomContainer pool (sample-equivalent) — mcpServerSettings silently dropped:
az rest --method put \
--url "/subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.App/sessionPools/mcpcustom?api-version=2025-10-02-preview" \
--body '{"location":"eastus2","properties":{"environmentId":"<managed-environment-id>","poolManagementType":"Dynamic","containerType":"CustomContainer","scaleConfiguration":{"maxConcurrentSessions":5,"readySessionInstances":1},"sessionNetworkConfiguration":{"status":"EgressEnabled"},"dynamicPoolConfiguration":{"lifecycleConfiguration":{"lifecycleType":"Timed","cooldownPeriodInSeconds":300}},"customContainerTemplate":{"containers":[{"name":"codeinterpreter","image":"mcr.microsoft.com/k8se/services/codeinterpreter:0.9.18-python3.12","env":[{"name":"SYS_RUNTIME_SANDBOX","value":"AzureContainerApps-DynamicSessions"},{"name":"AZURE_CODE_EXEC_ENV","value":"AzureContainerApps-DynamicSessions-Py3.12"},{"name":"AZURECONTAINERAPPS_SESSIONS_SANDBOX_VERSION","value":"7758"},{"name":"JUPYTER_TOKEN","value":"AzureContainerApps-DynamicSessions"}],"resources":{"cpu":1,"memory":"2Gi"}}],"ingress":{"targetPort":6000}},"mcpServerSettings":{"isMCPServerEnabled":true}}}'
# GET afterwards -> "mcpServerSettings": null, provisioningState Succeeded
Impact on the sample
Because mcpServerSettings never persists on the CustomContainer pool:
sessionPool.properties.mcpServerSettings.mcpServerEndpointininfra.bicepevaluates to null and the Foundry connection target is empty/invalid.- The deployment script's
az rest --method post --url "$SESSION_POOL_ID/fetchMCPServerCredentials?..."fails withSessionMCPServerNotEnabled, so the wholeaz deployment group createrun fails.
Documentation cross-references
- Custom code interpreter tool for agents (preview) — declares this scenario ("create an agent that uses a custom code interpreter MCP server"), requires only the
SessionPoolsSupportMCPfeature registration, and points at this sample'sinfra.bicep. - Azure Container Apps custom container sessions — does not mention the platform-managed MCP server at all.
- The platform-managed MCP tutorials only cover
ShellandPythonLTSpool types.
Questions
- Is the platform-managed MCP server actually supported for
containerType: 'CustomContainer'session pools today? If yes, what is missing beyondSessionPoolsSupportMCPregistration (extra gate, allow-list, specific regions)? - If it is not yet rolled out, can the sample and the custom-code-interpreter doc be updated to say so — and ideally can the RP reject
mcpServerSettingson unsupported pool types instead of silently dropping it? The silent drop turns a configuration error into a late, confusingSessionMCPServerNotEnabledfailure.
Environment
- Date tested: 2026-07-17
- Regions: eastus2, westus2
- API versions: 2025-02-02-preview, 2025-10-02-preview
SessionPoolsSupportMCP: Registered;Microsoft.Appprovider: Registered- Example failure traceId:
fc0fd0d9859c929e74c91f49dbe563c0(eastus2,fetchMcpServerCredentials→SessionMCPServerNotEnabled)
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.