Tools and capabilities
A capability reaches a Cmdop conversation through one of four surfaces: built-in tools, Skills, external MCP software connected to an agent, and your fleet exposed to an outside MCP client. They look alike in a menu but differ in ownership, approval, and lifecycle — and the first two add capability inward while fleet MCP exposes access outward.
Cmdop has four ways a capability reaches a conversation. They look similar in a menu and are genuinely different in ownership, approval, and lifecycle. Keeping them apart is how you reason about what a machine can actually do.
Capability surfaces
| Surface | What it is | Direction | Its boundary |
|---|---|---|---|
| Built-in tools | Cmdop’s own actions on the selected machine or fleet | Inside-out | Runtime permission policy and machine access |
| Skills | Cmdop-authored task capabilities | Inside-out | Authoring, release, and isolation, each with its own lifecycle |
| External MCP | Third-party MCP software connected to a Cmdop agent | Inbound capability | Per-machine consent and review; processes start lazily |
| Fleet MCP | Your Cmdop fleet exposed to an external MCP client | Outbound exposure | Rides existing fleet access; adds no new credential |
Built-in tools include browser control
Built-in tools cover the machine’s own actions — running commands, reading and writing files, searching the web, capturing the screen, scheduling and watching for changes, and more. One built-in family worth calling out is browser control: the agent can act on the web inside the user’s own, already-signed-in Chrome, so it reaches pages behind a login without being handed any passwords.
Browser control is attach-only. The agent never launches a browser; the user
opens one for it by running cmdop browser, which reopens their everyday Chrome
for automation. The trade is explicit: while that browser is open for the agent,
the agent can act on any tab in it. Close it to end that access.
The direction is the thing to get right
External MCP adds capability to your agent: you are letting other software act inside your machine’s boundary, so it is gated by consent and review on that machine.
Fleet MCP does the opposite: it exposes your fleet to a client you already trust, such as Claude Code. It inherits the local agent’s existing access rather than minting a new credential, and per-target connection PINs still apply to the machines it reaches.
Confusing the two leads to the wrong mental model of where the trust boundary sits.
They do not share one installation model
There is no single “add a capability” flow that covers all four. Skills and MCP are not two labels for one package format or one approval path, and they stay visibly distinct in the product for that reason. Installing an MCP server does not publish a Skill, and authoring a Skill does not grant it runtime availability.
Common questions
What is the difference between external MCP and fleet MCP?
External MCP adds a tool source to a Cmdop agent. Fleet MCP exposes your Cmdop fleet to an external client such as Claude Code or Codex. One adds capability inward to a machine; the other lets a trusted assistant reach machines through existing fleet access.
Does installing an MCP server install a Cmdop Skill?
No. MCP servers and Skills have different package shapes, approval paths, and runtime lifecycles. Installing or approving one does not publish or install the other.
Which capability path should I use for a remote AI assistant?
Use fleet MCP when Claude Code, Codex, or another MCP client should operate joined machines. Use external MCP when a Cmdop agent needs approved tools from another local or network service.
Cmdop