External MCP tools
Give a Cmdop agent tools published by another MCP server. Nothing runs until you have seen the exact command and approved the exact tools it offers.
This is the opposite of registering Cmdop with your own assistant — for that, see Claude Code and Codex.
The five steps
Every server goes through the same sequence, in the console or on the command line:
- Add the server. It is saved disabled; adding never runs its command.
- Review the command. You see the complete command vector and grant consent to it.
- Test the connection. Cmdop runs one contained probe, completes the MCP handshake, records what the server offered, and stops the process.
- Review the tools. You approve the exact catalogue the test recorded.
- Enable. Approved tools become available to agents; the server itself stays stopped until an agent first calls one.
Consent to a command and approval of tools are separate on purpose. A server whose command you trust can still offer a tool you do not want.
On the command line the same sequence is:
cmdop mcp servers add playwright --command npx --arg=-y --arg @playwright/mcp
cmdop mcp servers test playwright
cmdop mcp servers enable playwright --candidate <digest-from-test> --approveThe test prints the candidate digest and the tool definitions to read. enable
approves only that candidate; it does not start the command again.
States you will see
| State | What it means |
|---|---|
| Off | Added and saved, not yet consented or approved. |
| Available | Approved and enabled. The process is not running, because nothing has called a tool yet. |
| Active now | An agent called a tool, so the server is running. |
| Needs attention | Cmdop stopped using the server and is waiting for you. Most often its tool list changed — see below. |
“Enabled but stopped” is the normal resting state, not a fault.
Local and hosted servers
The console labels each entry by how Cmdop reaches it:
- Local (stdio) — a command Cmdop runs on the machine. You review the command vector.
- Hosted (HTTP) — a remote server Cmdop connects to over HTTPS. You review the verified URL and supply any required header or API-key values. Those values are write-only: they go to the machine’s OS keyring and never appear in a configuration file, in command output, or in discovery output.
A hosted server that answers its first test with “authentication required” is behaving normally — supply the key and test again.
The transport describes how Cmdop reaches the MCP server. It has nothing to do with how that machine reaches its relay.
When an approved server changes its tools
An enabled server can change the tools it offers while it is running. When that happens Cmdop stops using it immediately, moves it to Needs attention, and waits for you to review the replacement. Nothing calls the new tools until you approve them. A server you approved last week can stop working on its own for exactly this reason.
The review groups the differences:
| Group | What it means |
|---|---|
| Added | A tool that was not in the catalogue you approved. |
| Changed | Same tool name, different description or input schema. Read this group carefully — the name is familiar, the behavior may not be. |
| Removed | A tool you approved that the server no longer offers. Anything relying on it will now fail. |
| Unchanged | Identical to what you already approved. |
If you see no change groups at all, this is a first inspection — not a server that changed nothing. A comparison exists only when there is an earlier approved catalogue to compare against, so a brand-new server has none. Read the full tool list in that case, because nothing is being filtered for you.
Re-testing before you approve keeps the comparison anchored to the catalogue you originally approved, not to the previous probe.
Where the definitions live
Managed definitions, consent, approval, secrets, and runtime state stay on the machine that runs the server. They are not held by the marketplace and they do not travel with a catalogue listing.
A definition Cmdop discovered in another client’s configuration still belongs to that client until you explicitly import it. Cmdop never edits a foreign client’s files.
Command reference
cmdop mcp servers list
cmdop mcp servers disable <name>
cmdop mcp servers remove <name>
cmdop mcp discoverUse cmdop mcp servers --help for the exact flags in your installed version.
For secrets, put an input reference in the definition (--env 'TOKEN=${input:my-token}' --secret my-token) and let Cmdop prompt for the value
without echoing it.
Related
- MCP integration — the other job MCP does here.
- MCP troubleshooting
Common questions
How do I let a Cmdop agent use an external MCP server?
Add the server disabled, review the exact command or hosted URL, run one test, review the exact tool catalogue, then enable only the approved candidate. The server stays stopped until an agent calls one of its tools.
Does adding an MCP server run it immediately?
No. Adding saves the definition disabled. Testing runs one contained probe, and an enabled server still rests stopped until a real tool call starts it.
What happens if an MCP server changes its tools?
Cmdop stops using it, moves it to Needs attention, and waits for you to review and approve the replacement catalogue. New or changed tools are not called automatically.
Cmdop