MCP environment variables: env, envFile and placeholders
Understand MCP process environments, env and client placeholders. Includes a Cursor example without secrets and a step-by-step check of the effective values.
A variable name in a guide does not establish that your server receives its value. A file, the running editor and the launched process involve distinct handoffs. For a missing setting, trace the path from its origin to its consumer. Start with a non-sensitive value such as a test path. This lets you investigate the handoff without putting personal credentials into error reports or public forms.
Separate three layers
| Layer | Meaning | Question |
|---|---|---|
| Process environment | Values available when a program starts | How was the editor launched? |
| env in the server block | Environment of the launched server | Is the variable name correct? |
| Client placeholder | Resolved by the client | Does it support this syntax? |
Cursor documents ${env:NAME}, ${workspaceFolder} and an envFile option for local stdio servers. These do not establish universal configuration syntax for every MCP client. Check the client reference and documentation for the program you actually launch. A file named .env only takes effect when a component explicitly loads it. A value set in a terminal may not be present in an editor that was already running.
Start with a storage path instead of a key
The Cursor example below sets a non-secret path directly in the server block. Create the test directory and replace the sample value first. This checks the simpler handoff from configuration to server. Only once that works should you introduce another layer of variable resolution. The Memory guide explains how to test the storage file through a write, restart and fresh read.
{
"mcpServers": {
"memory": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-memory"
],
"env": {
"MEMORY_FILE_PATH": "/absolute/path/mcp-test/memory.jsonl"
}
}
}
}
Check each handoff in turn
Record the required variable name from the server documentation. Its spelling and letter case are part of the name.
Launch the server with the explicit test path. Create an invented test object and verify that a fresh read returns it after restart.
Only then replace the fixed path in Cursor with
${env:MCP_TEST_MEMORY_PATH}. Set that variable to the same test path in the environment from which Cursor is launched.Fully reopen the affected client. Repeat the same operation and compare the file actually used. Record the variable name and outcome, keeping secret values out of your notes.
Recognize empty values and mistaken assumptions
Distinguish a missing variable, an empty variable and a variable containing a literal placeholder. These are different findings. Authentication can fail despite a populated variable when the account or permissions do not match; use the troubleshooting navigator for that stage. The converter deliberately rejects client placeholders. It cannot establish whether identical text refers to the same directory or value in a different client.
- Does every server automatically load .env?
- No. Determine which component reads the file, which directory it resolves it from and when loading happens.
- Can I use envFile for an HTTP connection?
- Cursor documents this option for stdio. Do not assume it applies to a remote connection.
- Why is opening another terminal insufficient?
- The existing editor is a different process. Check its launch environment and reopen it for your countercheck.
- Should I publish the value for debugging?
- For secrets record only the name and whether it is missing, empty or set. Test the handoff with a non-sensitive substitute.
Provider documentation checked on 1 October 2026. Verification workflows are editorial suggestions.
- Cursor: variables and envFile
Show retrieval command
curl -s https://cursor.com/docs/mcp - Memory: storage configuration
Show retrieval command
curl -s https://github.com/modelcontextprotocol/servers/tree/main/src/memory