Seeing an MCP server name is only the first check. The agent CLI must load its configuration, connect, pass any required authentication, expose the tool to that session, and choose to use it for the request. Canopy can help inspect supported CLI configurations, but one CLI's server or login does not become another CLI's tool automatically.
Identify which CLI and project are failing
Write down the agent CLI, its version, the current project directory, the server name, and whether the server should be personal or project-wide. In a Canopy workspace, verify which installed CLI owns the active session. Canopy's current-main README describes discovering and inspecting MCP servers across CLI configurations, but that view does not grant another CLI access or prove parity in the installed release. Run the CLI's own status command in the intended environment before editing configuration.
Separate configured from connected
For Codex, `codex mcp list` shows configured servers; the official docs also describe `codex mcp login <server-name>` for servers using OAuth. For Claude Code, `claude mcp list` and `claude mcp get <name>` show status, and `/mcp` checks the server inside an interactive session. Claude's docs distinguish connected, authentication-needed, failed, pending-approval, rejected, and disabled states. A server written to config is not necessarily connected, approved, or usable. Do not paste a token into a chat to fix an authentication problem; use the CLI's documented authorization flow.
| Observation | Check | Next step |
|---|---|---|
| Not listed | CLI, project, user/project scope, config location | Add it to the CLI that will use it |
| Listed but pending or disabled | Project trust and tool settings | Review and enable it in that CLI |
| Authentication needed | Provider account and authorization scope | Use the CLI's supported login flow |
| Connection failed | Server process or URL, network, environment variables | Fix the endpoint or process; inspect status again |
| Connected but unused | Tool available in the live session and task wording | Ask for one specific read-only tool-backed answer |
Try a public read-only server
OpenAI provides a public documentation MCP server at `https://developers.openai.com/mcp`. Its official quickstart gives `codex mcp add openaiDeveloperDocs --url https://developers.openai.com/mcp` and, separately, `claude mcp add --transport http openaiDeveloperDocs https://developers.openai.com/mcp`. Add only to the CLI you intend to test, then run that CLI's `mcp list` command; in Claude Code, also inspect `/mcp`. Ask the agent to use the documentation server to find one specific API field and cite the page. The server provides read-only documentation search and page content; it does not call the OpenAI API for you. This trial isolates MCP discovery without granting access to GitHub, tickets, or a database.
Check scope and approval before copying configuration
Claude Code supports user and project scopes, with project configuration in `.mcp.json`; its current docs describe a workspace-trust and approval step for project servers. Codex has its own MCP configuration and OAuth state. Setting up a server in Claude Code does not add it to Codex, and the two may use different credentials even when they point at the same endpoint. For a team, commit only a safe project-level definition when the CLI supports it, then have each person approve and authenticate separately. Review tool capabilities and permissions before enabling a write-capable server.
Prove the agent used the tool
A plausible answer is not evidence of an MCP call. Ask for a current fact that the server can return, request a direct source link, and inspect the CLI's visible tool activity or transcript. If the answer came from memory, explicitly ask it to use the configured server and recheck availability. If one CLI succeeds and another fails, compare their status output, scope, and authentication rather than blaming Canopy's tab layout. Record the exact CLI and Canopy versions; integrations can differ by release.
Copyable resources
MCP connection diagnosis
Use a read-only server first; keep credential values out of the record.
Canopy release / platform: [ ]
Agent CLI and version: [ ]
Project directory and server name: [ ]
Expected scope (personal or project): [ ]
CLI list/get status: [ ]
Interactive session status and approval: [ ]
Authentication state, without tokens: [ ]
Server URL or process and relevant error: [ ]
One read-only tool request and cited result: [ ]
Next failing boundary and owner: [ ]Frequently asked questions
Why can Claude Code use an MCP server but Codex cannot?
Each CLI loads its own configuration and authentication. Add, approve, and verify the server in Codex separately; Canopy does not transfer Claude Code's tools or credentials.
Does a server in Canopy's MCP view mean an agent can use it?
No. Discovery or inspection is not proof of a live connection, authorization, or tool use. Check the owning CLI's status and a real tool-backed request.
Should I put an MCP token in AGENTS.md or CLAUDE.md?
No. Those files are instructions, not a secret store. Use the CLI's documented credential and MCP configuration flow, and keep committed project files free of tokens.
Is an MCP server the same as a skill?
No. An MCP server supplies live tools or data. A skill describes a repeatable workflow and may tell the agent when to use those tools.