Getting the saved details for a configured Model Context Protocol (MCP) server shows exactly what Codex will launch or connect to for that server name. That helps confirm the right endpoint, launcher, and enablement state before a session tries to use the integration.
The current codex mcp get subcommand reads a named MCP entry from ~/.codex/config.toml, and that MCP configuration is shared between the Codex CLI and IDE extension. The default view prints a short human-readable summary, while --json returns the same server record in machine-readable form.
Server details can include local commands, arguments, remote URLs, and bearer-token environment variable names, so treat the output as configuration data rather than something to paste into public tickets or screenshots. If the exact server name is unknown, run codex mcp list first and use the value from the Name column.
Related: How to list Codex MCP servers
Related: How to add a URL-based MCP server to Codex
Related: How to remove a Codex MCP server
Steps to get Codex MCP server details:
- List the configured MCP servers and note the exact server name.
$ codex mcp list Name Command Args Env Cwd Status Auth iterm npx -y iterm-mcp - - enabled Unsupported
The Name value must match exactly in the next command. Remote HTTP servers appear in a separate table with Url and bearer-token columns when they are present.
- Retrieve the saved details for the named server in the default human-readable view.
$ codex mcp get iterm iterm enabled: true transport: stdio command: npx args: -y iterm-mcp cwd: - env: - remove: codex mcp remove iterm
The default output is the quickest way to confirm the saved transport and target. Remote entries show fields such as url and bearer_token_env_var here instead of a local launcher command.
- Print the same server details as JSON when another tool or script needs the full record.
$ codex mcp get iterm --json { "name": "iterm", "enabled": true, "disabled_reason": null, "transport": { "type": "stdio", "command": "npx", "args": [ "-y", "iterm-mcp" ], "env": null, "env_vars": [], "cwd": null }, "enabled_tools": null, "disabled_tools": null, "startup_timeout_sec": null, "tool_timeout_sec": null }Use the transport object to confirm what Codex will actually use. Local launchers expose command, args, cwd, and optional environment settings, while remote entries expose fields such as url and bearer_token_env_var.
- Save the JSON output to a file when comparing configs or attaching a private debug artifact.
$ codex mcp get iterm --json > iterm-mcp.json
Review the saved file before sharing it, because MCP records can expose internal endpoints, launch arguments, or environment variable names that do not belong in public issue trackers.
Mohd Shakir Zakaria is a cloud architect with deep roots in software development and open-source advocacy. Certified in AWS, Red Hat, VMware, ITIL, and Linux, he specializes in designing and managing robust cloud and on-premises infrastructures.
