Never paste a token into an MCP config file that lives in a repository. Reference an environment variable or an input prompt instead, so the file can be committed while the secret stays on each developer's machine. Claude Code, Cursor and VS Code each support this in slightly different syntax.
Why this keeps going wrong
MCP setup guides often show a key inline for brevity. Copy it, commit the file, and the key is in history. Project level files such as a repo root MCP config exist precisely to be shared, which makes mistakes spread to the team.
GitHub's own Copilot guide notes that its examples place a personal access token directly in the JSON file and says to treat that file as sensitive. The safer habit is to avoid putting the value there at all.
Claude Code
The project config format supports variable expansion in the command, arguments, environment, URL and headers, with an optional default.
{
"mcpServers": {
"api-server": {
"type": "http",
"url": "${API_BASE_URL:-https://api.example.com}/mcp",
"headers": { "Authorization": "Bearer ${API_KEY}" }
}
}
}
Anthropic's docs add that credential variables such as the Anthropic API key read as empty in remote URLs and headers, so a project cannot exfiltrate them. If you need one, copy it into a variable with your own name. An unset variable without a default loads as literal text and shows a warning.
Cursor
Cursor resolves its own interpolation syntax in command, arguments, environment, URL and headers.
{
"mcpServers": {
"remote-server": {
"url": "https://api.example.com/mcp",
"headers": { "Authorization": "Bearer ${env:MY_SERVICE_TOKEN}" }
}
}
}
For local servers it also supports a path to an env file. Per the docs, remote servers do not support that option, so read secrets from the shell or system environment.
VS Code
The VS Code docs recommend input variables or env files for API keys rather than hardcoding them. An input variable prompts the user when the server starts, so nothing is stored in the file.
A short routine
- Search the repo for tokens before you commit, including config folders.
- Keep a sample file with variable names and no values.
- Use the narrowest token scope the server needs.
- Rotate any token that was ever committed, even briefly.
- Prefer OAuth where the server supports it, since the client stores the token for you.
What to do if a secret slipped in
Treat it as exposed. Revoke the token at the provider first, issue a new one, and update the variable on each machine. Then check whether the file was pushed anywhere shared, including forks and CI logs. Rewriting history can help later, but it does not undo exposure, so rotation is the step that actually closes the risk.
Quick check
Is it fine to commit an MCP config with a placeholder token?
Yes if it is truly a placeholder. The risk is someone replacing it with a real value. A variable reference is safer.
What if a key was already committed?
Revoke and rotate it. Removing the file from the latest commit does not remove it from history.
Sources
Last reviewed: 19 October 2026.
