[playb0t]

Description

Each container's entry point runs uv run, which reads tool.uv.sources again at startup and stops with "oracle-mcp-common references a workspace in tool.uv.sources ... but is not a workspace member", because the workspace member ../common is outside the build context. The build already installs the application into /app/.venv with uv sync --no-sources --all-extras --no-editable (#421), so the entry point now runs that installed console script directly.

Changes:

• src/oci-api-mcp-server/Containerfile: ENTRYPOINT ["/app/.venv/bin/oracle.oci-api-mcp-server"] and its comment line
• src/oci-cloud-mcp-server/Containerfile: ENTRYPOINT ["/app/.venv/bin/oracle.oci-cloud-mcp-server"] and its comment line
• An entry under Unreleased / Fixed in each server's CHANGELOG.md

No Python code changes. No new dependencies. These are the only two images with both a uv run entry point and a workspace source.

Fixes #540

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

Two stages, both on main e75013f9.

The commands as written, default log level, no settings beyond those shown:

• API, unmodified Containerfile: podman run --rm -i --network=none oci-api-mcp exits 2 with the uv error quoted in OCI API and OCI Cloud MCP server containers exit before initialize: uv run re-reads the workspace source at startup #540; stdout stays empty.
• API, this change: podman run --rm -i --network=none -e OCI_CLI_AUTH=api_key oci-api-mcp waits on stdin; the MCP Python SDK 1.30.0 client gets initialize and list_tools (2 tools); on EOF the container exits 0 and --rm removes it.
• Cloud, unmodified Containerfile: podman run --rm -i --network=none oci-cloud-mcp exits 2 with the same error for oracle-oci-cloud-mcp-server==2.2.3.
• Cloud, this change: the same command waits on stdin; initialize and list_tools (5 tools); exit 0 on EOF, removed by --rm.
• At the default log level the only warning on stderr of both patched servers is the authlib one below.

One image, both entry points, so the result does not depend on a rebuild picking up different packages. Every run used --network=none, no host mounts and no OCI profile, with these settings: -e FASTMCP_CHECK_FOR_UPDATES=off -e FASTMCP_LOG_LEVEL=ERROR -e OCI_CLI_AUTH=api_key -e OCI_MCP_AUTH_TYPE=api_key -e OCI_CONFIG_FILE=<a path that does not exist>. With OCI_CLI_AUTH set, the server passes no auth arguments to the CLI, so --version runs without a profile.

• The original uv run entry point (--entrypoint set back to it on this image): the uv workspace error quoted in OCI API and OCI Cloud MCP server containers exit before initialize: uv run re-reads the workspace source at startup #540, before initialize.
• The new default entry point (no --entrypoint override, no UV_* variables): MCP initialize and list_tools succeed with the MCP Python SDK 1.30.0 client over stdio; the oci-api-commands resource returns the CLI help; run_oci_command with --version returns OCI CLI 3.92.0; get_oci_command_help for a service that does not exist returns a handled error, and the next call succeeds.
• The container runs as oracle (UID 1000) and is removed by --rm when the client disconnects.
• OCI Cloud, one image built from its Containerfile with this change, --network=none, no host mounts, -e FASTMCP_CHECK_FOR_UPDATES=off -e FASTMCP_LOG_LEVEL=ERROR -e OCI_CONFIG_FILE=<a path that does not exist>: the original entry point stops with the same uv error before initialize; the new default entry point passes initialize, lists all 5 tools, answers list_client_operations (a metadata call, no OCI client is created), returns a handled error for limit=0, and repeats the first call with the same result. Both containers are removed by --rm.

To verify (for Cloud: src/oci-cloud-mcp-server, tag oci-cloud-mcp, no -e needed):

cd src/oci-api-mcp-server
podman build -t oci-api-mcp -f Containerfile .
# before this change: exits 2 at once with the uv error
# after: keeps running, waiting for an MCP client on stdio
podman run --rm -i --network=none -e OCI_CLI_AUTH=api_key oci-api-mcp

On startup the server prints an AuthlibDeprecationWarning from authlib's httpx client. It comes from the dependency, not from this change.

Test Configuration:

• Base image: ghcr.io/oracle/oraclelinux:9-slim@sha256:1950389c... (unchanged)
• Toolchain: Podman 5.7.0, rootful, in WSL2 Ubuntu; the MCP client runs on Windows
• SDK: MCP Python SDK 1.30.0 client; the API image contains Python 3.13.16, FastMCP 3.4.10, MCP 1.30.0, OCI CLI 3.92.0 and oracle-mcp-common 0.1.4; the Cloud image contains Python 3.13.16, Cloud 2.2.3, FastMCP 3.4.10, MCP 1.30.0, OCI SDK 2.185.1 and oracle-mcp-common 0.1.4

Not run: the Python unit suites and the Moon wrapper (no Python code changed); rootless Podman; Docker.

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas (the Containerfile comment states why)
• I have made corresponding changes to the documentation (CHANGELOG entry; the README's container steps stay correct)
• My changes generate no new warnings (the authlib warning above predates this change)
• I have added tests that prove my fix is effective or that my feature works (no container test exists in the repo; tested by hand as above)
• New and existing unit tests pass locally with my changes (not run; no Python code changed)
• Any dependent changes have been merged and published in downstream modules (none needed)

[oracle-contributor-agreement]

Thank you for your pull request and welcome to our community! To contribute, please sign the Oracle Contributor Agreement (OCA).
The following contributors of this PR have not signed the OCA:

• PR author: playb0t
• w0rldlogic.0point@proton.me (@playb0t)

To sign the OCA, please create an Oracle account and sign the OCA in Oracle's Contributor Agreement Application.

When signing the OCA, please provide your GitHub username. After signing the OCA and getting an OCA approval from Oracle, this PR will be automatically updated.

If you are an Oracle employee, please make sure that you are a member of the main Oracle GitHub organization, and your membership in this organization is public.