MCP Configuration by Client: Codex, Claude Code, Cursor, and VS Code

Start with the server's actual contract

Before editing a client configuration, confirm:

• The canonical source or registry identity.
• Whether the server is local stdio or remote HTTP.
• The exact command, arguments, URL, and required runtime.
• The supported client and protocol version.
• Required credentials and their minimum scopes.
• Which tools read, write, or perform destructive actions.

Do not copy a configuration merely because it resembles another client's format. Names, top-level keys, scopes, authentication, and trust prompts differ.

Codex

Codex clients share MCP configuration in ~/.codex/config.toml; trusted repositories can also use .codex/config.toml. The official Codex MCP guide documents the current CLI and configuration fields.

Add a local stdio server:

codex mcp add example -- npx -y @example/mcp-server

A corresponding TOML entry can declare the command, arguments, and forwarded environment-variable names:

[mcp_servers.example]
command = "npx"
args = ["-y", "@example/mcp-server"]
env_vars = ["EXAMPLE_API_KEY"]

For a remote HTTP server:

[mcp_servers.example_remote]
url = "https://mcp.example.com/mcp"
bearer_token_env_var = "EXAMPLE_MCP_TOKEN"
default_tools_approval_mode = "prompt"

Use codex mcp list to inspect configuration, codex mcp login <name> for supported OAuth servers, and /mcp in the terminal UI to inspect active connections. Prefer environment-backed headers to static secrets in TOML.

Claude Code

Claude Code provides claude mcp add and three scopes:

• Local: current project, private to you.
• Project: current project, shared through a root .mcp.json.
• User: all projects for the current user.

Add a remote HTTP server:

claude mcp add --transport http --scope local example https://mcp.example.com/mcp

Add a local stdio server:

claude mcp add --transport stdio --env EXAMPLE_API_KEY=YOUR_VALUE example -- npx -y @example/mcp-server

Use claude mcp list, claude mcp get <name>, and /mcp to inspect or authenticate. The Claude Code MCP guide notes that shared project configuration is stored in .mcp.json and is approval-gated before use. Keep credentials outside version control and use environment expansion where supported.

Cursor

Cursor supports project configuration in .cursor/mcp.json and global configuration in ~/.cursor/mcp.json. Its MCP documentation describes local commands, remote endpoints, OAuth, tool toggles, and approval behavior.

A local configuration uses the client-specific mcpServers key:

{
  "mcpServers": {
    "example": {
      "command": "npx",
      "args": ["-y", "@example/mcp-server"]
    }
  }
}

Add credentials only through the environment or secret integration documented for your installed Cursor release; do not commit secret values in a shared file. Keep the server disabled until its source and requested tools have been reviewed.

Visual Studio Code

VS Code stores workspace MCP configuration in .vscode/mcp.json; user-profile configuration is managed separately. The current VS Code MCP guide also supports gallery installation, command-line installation, trust prompts, server logs, and optional sandbox controls on supported platforms.

A workspace-local server uses a servers object:

{
  "servers": {
    "example": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@example/mcp-server"]
    }
  }
}

That top-level key differs from Cursor and Claude Code examples. Use the editor's schema and IntelliSense instead of translating configuration by visual similarity.

Client differences that commonly break setup

Paths and features can change. Recheck the linked client documentation when copying a setup from an older article.

Verify after configuration

1. Restart or reload the client when its documentation requires it.
2. Confirm the server appears by the expected name.
3. Inspect the discovered tools before invoking one.
4. Run a read-only health or listing operation.
5. Verify the server receives only the intended environment variables.
6. Confirm write and destructive tools still require the chosen approval behavior.
7. Review logs for command paths, authentication failures, and unexpected outbound access.

A connected status proves transport initialization. It does not prove that the server is trustworthy, correctly scoped, or safe for production data.