[BUG] Azure MCP Server 2.0.0-beta.7 fails to start in Azure Container Apps — no runtime logs, immediate ContainerBackOff

[jpsantoscosta]

Describe the bug

When deploying Azure MCP Server 2.0.0-beta.7 as a remote MCP HTTP server inside Azure Container Apps, the container fails immediately with ContainerBackOff.

No logs from the MCP server are produced (stdout/stderr completely empty), and ACA only reports generic startup probe failures and back-off events.

This happens with both:

• mcr.microsoft.com/azure-sdk/azure-mcp:latest (v1)
• mcr.microsoft.com/azure-sdk/azure-mcp:2.0.0-beta.7 (v2)

This prevents Azure AI Foundry agents from invoking MCP tools hosted in Azure Container Apps.

Additional Notes
Attempted Fixes (all unsuccessful)

• Using latest instead of 2.0.0-beta.7
• Explicit command overrides
• Minimal arguments (azmcp server start with no flags)
• Switching transports between http and default (stdio)
• Rebuilding environment from scratch
• Ensuring identity, RBAC, and network configuration were correct

Expected behavior

• The MCP Server should start successfully using:

azmcp server start --transport http --namespace storage --read-only

• Server should listen on port 3000 (or documented port)
• Console logs should show CLI messages (Starting Azure MCP Server…, etc.)
• Startup probe should succeed
• Foundry should be able to reach it as a Remote MCP server via HTTPS

Actual behavior

• Container immediately exits before writing ANY logs
• No stdout or stderr from MCP server
• ACA only reports:

startup probe failed: connection refused
ContainerBackOff

• Browser access to the MCP endpoint results in stream timeout after several minutes
• Foundry cannot connect to the MCP server

Reproduction Steps

1. Deploy Azure MCP Server via azd up

• From the official sample (servers/Azure.Mcp.Server/samples/foundry):

azd up

Deployment succeeds:

• Container Apps Environment created
• Container App created
• All role assignments succeed
• azd reports success

2. Switch container image to beta version (per docs)

Update Container App revision to use:

mcr.microsoft.com/azure-sdk/azure-mcp:2.0.0-beta.7

3. Configure explicit command override (to avoid v1 entrypoint flags)

Command: azmcp
Args: server start --transport http --namespace storage --read-only

A new revision (azure-mcp-storage-server--beta7-http) is created successfully.

4. Observe container status

Container immediately enters:

1/1 Container Crashing
ContainerBackOff

5. Check logs
   Console logs (stdout/stderr)

Only shows ACA wrapper messages:

Connecting to the container 'azure-mcp-storage-server'...
Successfully Connected to container ...

No logs from azmcp appear at all.

System logs

Repeated failures:

startup probe failed: connection refused
Persistent Failure to start container
Reason: ContainerBackOff

as well as repeated image pulls:

Pulling image "mcr.microsoft.com/azure-sdk/azure-mcp:2.0.0-beta.7"

There are no MCP server logs, no exception, no error text from the process itself.

Environment

• Azure Container Apps (Linux consumption)
• Azure AI Foundry project used as the MCP client
• Storage account used for --namespace storage
• System-assigned managed identity enabled for Container App
• Deployed using azd up from the official sample template

[JasonYeMSFT]

@jpsantoscosta When using --transport=http and --outgoing-auth-strategy is not specified, our code will use on-behalf-of (OBO) as the default outgoing authentication strategy. This code path requires more configurations that than managed identity path. This template doesn't provision all the resources to make the OBO flow work. When we authored the template, Microsoft Foundry doesn't support OBO because it doesn't support custom OAuth flow. We'll investigate if that's supported now.

If you would like to try the managed identity way of running the MCP server, could you please try adding this argument --outgoing-auth-strategy UseHostingEnvironmentIdentity and see if the container app still crashes? Alternatively, if you go to the container app in Azure Portal and open an interactive shell of the docker image, you may manually run the mcp-server/server-binary using the same command. The stdout/stderr may tell you why it failed to start.

[jpsantoscosta]

@JasonYeMSFT I tried the managed identity startup command as suggested.

Image: mcr.microsoft.com/azure-sdk/azure-mcp:2.0.0-beta.7

Command override:
azmcp
Args override:
server start --transport http --outgoing-auth-strategy UseHostingEnvironmentIdentity --namespace storage --read-only

New revision name: azure-mcp-storage-server--beta7-mi
The revision deploys, but the container still goes into ContainerBackOff.

Console logs:

{"TimeStamp": "2025-12-10T10:26:33.95216", "Log": "Connecting to the container 'azure-mcp-storage-server'..."}
{"TimeStamp": "2025-12-10T10:26:34.00229", "Log": "Successfully Connected to container: 'azure-mcp-storage-server' [Revision: 'azure-mcp-storage-server--beta7-mi', Replica: 'azure-mcp-storage-server--beta7-mi-7bf555cdbb-kh5wj']"}

There is no additional stdout/stderr from azmcp itself.

I also tried to follow your suggestion to open an interactive shell in the container and run the same command manually. However, the exec console fails with:
ERROR: {"Error":{"Code":"ClusterExecEndpointWebSocketConnectionError","Message":"Failed to establish WebSocket connection with the container, error is Failed to establish WebSocket connection with Managed Environment exec endpoint, error: The server returned status code '750' when status code '7101' was expected..","Details":null,"Target":null,"AdditionalInfo":null,"TraceId":null}}

So at the moment I’m not able to attach an interactive shell long enough to manually run azmcp and capture its output. The revision is still reported as 1/1 container crashing.

Happy to try additional flags or diagnostics if you have a recommended way to get more detailed logs from the 2.0.0-beta.7 image in Container Apps.

[JasonYeMSFT]

@jpsantoscosta Could you try leaving command override as empty and make a new revision? When we build the docker image, we give exec permission to a renamed executable. It's not named as azmcp. I believe the error you get from the console tab is due to the container failing to start.

[jpsantoscosta]

Hi @JasonYeMSFT ,

Thanks for the quick response — that unblocked the deployment.

I followed your recommendation to remove the command override entirely and redeployed the Container App. After doing this, the container started correctly and the /mcp-server executable launched without errors. The previous failure was indeed caused by trying to invoke azmcp, which does not exist in the container (the binary has been renamed during image build).

Here is the relevant log output confirming successful startup:

Application started. Press Ctrl+C to shut down.
Hosting environment: Production
Content root path: /mcp-server

Confirmation

• Leaving the command override empty fixes the crash.
• The MCP Server is now running successfully in Azure Container Apps.

Suggested Documentation Fix

The documentation currently instructs users to run commands such as:

i.e.: azmcp server start --transport=http --outgoing-auth-strategy UseHostingEnvironmentIdentity

…but the container image does not contain an executable named azmcp. This leads users to unintentionally override the startup command in Azure Container Apps with a non-existent binary — which causes container startup failure.

It would be helpful for others if the docs clarified:

1. That Container App deployments must NOT override the command, because the built-in entrypoint already starts the server
2. How to pass parameters (if supported) or whether configuration must be done via environment variables instead

Happy to test any preview updates.

Thanks again for the fast help — much appreciated!

I've proposed documentation change PR #1353