CMDOP Machine Care MCP server

cmdop-care

A small, read-only Model Context Protocol (MCP) stdio server exposing 4 read-only tools over an already-enrolled cmdop machine fleet: roster visibility, machine health, one bounded live diagnostic, and cmdop-owned storage usage.

Published: io.github.commandoperator/cmdop-care · Current version: v0.1.2 · License: Apache-2.0

If you already use cmdop on a machine, this is the conservative MCP entry point: connect an MCP-aware assistant to read fleet health without exposing a shell, arbitrary file reads, or open-ended machine delegation. The host must already be enrolled; credentials stay in the host operating system keyring. For broader machine operations, use the main cmdop MCP server instead.

This is not the full cmdop MCP surface. It intentionally omits askmachine, runcommand, readfile, and listdir — every tool that executes a command, reads an arbitrary file, or delegates an open-ended task to another machine. If you need those, use the main cmdop CLI's own MCP server (cmdop mcp stdio), which is a separate, broader, product-integration surface with its own review requirements. cmdop-care exists specifically to offer a narrower, safer, publishable subset for the official MCP Registry.

Requirement: an already-enrolled cmdop CLI on the host

cmdop-care requires the host machine to already be enrolled via the main cmdop CLI. It does not implement enrollment itself, and it does not accept a relay token via an environment variable or a mounted secret as a primary credential path. On startup it reads:

the OS keyring (macOS Keychain / Linux Secret Service / Windows Credential Manager) when you ran cmdop join ;

• the relay OAuth/enrollment Bearer token the cmdop CLI already stored in

same keyring (e.g. from a prior cmdop connect), for care_diagnose only.

• any per-machine connection PIN the cmdop CLI has already cached in the

If no token is found, every tool responds with a clear "not enrolled" message instead of failing silently or hanging.

This "host-keyring passthrough" model was a deliberate design decision (see security-architecture-2026-07-18.md in this artifact's source repository) to avoid introducing a second, weaker credential-handling path for the product — this binary is not a fully standalone identity; it rides the same enrollment as the CLI already installed on the host.

The 4 tools

list_machines

Lists the machines in the enrolled fleet.

returned** — this is a deliberate redaction decision (the internal relay identifier is dropped before serialization, not merely omitted from rendering).

• Input: none.
• Output: an array of {host, online, os}. **No machine ID/UUID is ever

care_status

Reads the durable Machine Care projection (facts, findings, coverage, freshness) for one enrolled machine.

list_machines.

• Input: machine (string, required) — exact display name from

flags, and reason codes. No raw paths, commands, environment variables, or machine identity.

• Output: aggregate facts/findings with closed-vocabulary codes, coverage

relay-stored projection, not a live round-trip).

• Read-only; works even while the target machine is offline (it reads a

care_diagnose

Runs one bounded, typed process/startup diagnostic on a live enrolled machine — useful for "why is this machine slow?"

• Input: machine (string, required).
• Output: a bounded snapshot of process and startup-item facts.

Two disclosures, read before using this tool:

Shortened. The full README is on GitHub.