It is not a vulnerability claim. The point is simpler than that: most bad MCP setups are not dramatic exploits. They are small convenience choices that quietly widen trust.
Source material
- VS Code: Add and manage MCP servers
- VS Code: MCP configuration reference
- Model Context Protocol: Security Best Practices
- Model Context Protocol: Understanding Authorization in MCP
The common mistake
A rushed mcp.json usually goes wrong in one of three ways:
- it puts secrets directly in the file
- it makes a local server broader than it needs to be
- it treats a quick-start example as if it were a production-ready daily setup
What a low-ceremony safe setup looks like
1. Put the server in the right place
VS Code supports mcp.json in your workspace and in your user profile. That is not just an organizational choice. It changes where the server runs and who inherits it.
- Workspace config is the right place for team-shared server definitions that really belong with the repo
- User-profile config is better for personal or machine-specific servers that should not quietly follow the repo around
Preflight take: if a server is personal, host-specific, or secret-heavy, do not drop it into shared workspace config just because that is the first file you found.
2. Keep secrets out of the file
VS Code is very direct about this: avoid hardcoding sensitive information like API keys. Use input variables or environment files instead.
Preflight take: if a token appears directly in mcp.json, the config is already too trusting.
3. Keep local servers narrow
The MCP security guidance treats local servers as a serious trust boundary because they run on the same machine as the client and can have direct access to the local system.
- small path scope instead of whole-home-directory access
- explicit environment variables instead of broad forwarding
- reviewed commands instead of opaque wrapper chains
- only the network access the server actually needs
If you are on macOS or Linux, VS Code now supports sandboxEnabled plus filesystem and network rules in mcp.json. That is one of the easiest high-value hardening moves available today.
Preflight take: the safest local MCP config is the one that feels slightly constrained, not the one that can touch everything.
4. Keep remote auth explicit
The MCP docs are equally clear on the remote side: token passthrough is a forbidden anti-pattern, MCP servers must not accept tokens that were not explicitly issued for the MCP server, and authorization endpoints must be served over HTTPS.
Preflight take: remote MCP auth should look boring and explicit. If it looks clever, review it again.
5. Treat trust prompts as real review points
VS Code asks you to trust a server when you add or change one in workspace configuration and start it for the first time. That is useful, but it is not a substitute for reading the config.
Preflight take: read the command, args, URL, headers, and scope before the first start. Do not outsource that judgment to the existence of a dialog box.
What MCP Preflight would usually flag in a rushed mcp.json
- raw credentials or secrets in config
- token passthrough or auth-review patterns on remote servers
- insecure
http://remote URLs that are not obviously local - ephemeral launchers in day-to-day setups
- broad environment inheritance
- local servers with write or network scope that is much wider than the task
- missing sandboxing where a constrained local setup would be possible
A short checklist
- should this server live in workspace config or only in my user profile?
- did I keep secrets out of the file?
- is the command pinned and understandable?
- is the local path and network scope narrower than "whatever works"?
- is remote auth explicit and HTTPS-based where it should be?
- am I actually reading the config, or just clicking through startup?
The next action is simple: open your current mcp.json and read it like a permission grant, not like a convenience file.