Integration boundaries
Cmdop exposes four separate public surfaces: MCP for letting an assistant work across your fleet, Skills for packaging reusable instructions, the CLI for terminals and scripts, and the SDK for building Cmdop into a Python or Node program. They are distinct contracts — none of them is a broader version of another.
Cmdop has four public surfaces. They are separate contracts with separate installation models — none of them is a general-purpose version of another.
Pick the integration surface
| Surface | Use it when |
|---|---|
| MCP | You want an assistant to work across your fleet, or a Cmdop agent to call an outside tool. |
| Skills | You want to package an instruction capability and reuse it. |
| CLI | You want to operate a machine, a relay, or the fleet from a terminal or a script. |
| SDK | You want to build Cmdop into a Python or Node program. |
Picking the wrong one is the usual source of confusion: adding an MCP server does not install a Skill, and a Skill in the marketplace is not a tool an agent can call until it is installed on the machine. See Marketplace and installed state.
Related
Common questions
Which Cmdop integration surface should I use?
Use MCP for assistants, Skills for reusable instructions, the CLI for terminals and scripts, and the SDK for Python or Node applications. They are separate contracts, not levels of one generic API.
Does installing an MCP server install a Skill?
No. MCP servers supply tools and Skills supply instructions. Adding one does not install, approve, or publish the other.
Should an AI assistant use the SDK?
Usually no. When the caller is an assistant, register Cmdop through MCP so it gets fleet tools. Use the SDK when your own program owns the integration.
Cmdop