Missing referenced env var

What mcp-scan saw

The secret scanner found a value that is entirely an environment reference, either ${NAME}, $NAME, or the Windows form %NAME%, and that name is not present in the scanning process's environment under either its literal or uppercased form. The match is anchored to the whole value, so --url=${NAME} does not fire here.

Why it fires

The reference resolves to nothing at launch, so the server starts with an empty credential or an empty endpoint and fails in a way that looks like the remote service's problem rather than a config error. Catching it at scan time is cheaper than reading a 401 from the server's logs.

When this is a false positive

• The client injects the variable at launch from a keychain, a secret manager, or a .env the launcher loads. It exists when the server runs and not when the scanner runs.
• The scan is running in CI, or under a different shell profile, where the variable is legitimately absent.
• The variable is exported by a wrapper script that sets up the environment immediately before spawning the server.
• The reference is deliberately optional, for example a debug flag the server treats as off when unset.

How to fix it

1. Check the variable in the shell you scan from: printenv NAME. If it prints nothing, the finding is accurate for that environment.
2. If the launcher injects it, re-scan from the same environment the client uses, since the check reads the scanning process's own environment.
3. If it is genuinely unset, export it in your shell profile or your secret manager under exactly that name, including case.
4. If the variable is optional, give it a literal default in the config rather than an unresolvable reference.
5. Note the difference from env-var-scope-leak: that rule matches ${NAME} anywhere in the text, this one only when the whole value is the reference.