Subject: How to handle dynamic environment variables for Docker‑based MCP servers in Cursor Team Settings

Description:

We are using Cursor Dashboard → Team Settings → MCP Configuration to control which MCP servers are available to our team, so that team members cannot use unauthorized MCP servers.

For URL‑based MCP servers, this works well.
However, we are facing a challenge with the Command‑based MCP configuration.

We have an MCP server that is containerized and runs via a Docker command.
This MCP server requires environment variables such as Azure DevOps org URL, PAT, and default project.

Example MCP configuration we want to enforce at the team level:

"azureDevopsACR": {

  "disabled": false,

  "command": "docker",

  "args": [

    "run",

    "-i",

    "--rm",

    "my-docker-image-url/azure-devops:latest"

  ],

  "env": {

    "AZURE_DEVOPS_ORG_URL": "ENTER_URL",

    "AZURE_DEVOPS_AUTH_METHOD": "pat",

    "AZURE_DEVOPS_PAT": "ENTER_PERSONAL_PAT",

    "AZURE_DEVOPS_DEFAULT_PROJECT": "ENTER_PROJECT_NAME"

  }

}

Problem:

The required environment variables are not static and vary per team or user (for example, PATs, org URLs, or default projects).

The Command text box in the Cursor MCP configuration does not clearly support:

  • Dynamic or per‑user environment variables

  • Secure injection of secrets (like PATs)

  • Parameterization without hard‑coding values

Because of this:

  • We cannot centrally enforce the MCP server and

  • Avoid hard‑coding sensitive or team‑specific values

Questions:

  1. What is the recommended way to pass dynamic environment variables to a Docker‑based MCP server when using the Command option?

  2. Is there support for:

    • Referencing environment variables already present on the user’s machine?

    • Secure secret injection (instead of plain text)?

  3. If dynamic variables are not supported in Command‑based MCPs, is the recommended approach to expose the MCP server via a URL instead?

  4. Are there best practices for enforcing team‑approved MCP servers while still allowing team‑specific configuration?

Any guidance or recommended patterns would be greatly appreciated.

I am able to solve it using system var. Thanks