Tbh I find self-documenting CLIs (e.g. with a `--help` flag, and printing correct usage examples when LLMs make things up) plus a skill that's auto invoked to be pretty reliable. CLIs can do OAuth dances too just fine.

MCP's remaining moats I think are:

- No-install product integrations (just paste in mcp config into app)

- Non-developer end users / no shell needed (no terminal)

- Multi-tenant auth (many users, dynamic OAuth)

- Security sandboxing (restrict what agents can do), credential sandboxing (agents never see secrets)

- Compliance/audit (structured logs, schema enforcement)?

If you're a developer building for developers though, CLI seems to be a clear winner right

▲

quotemstr 10 hours ago | parent [-]

Imagine if, in addition to local MCP "servers", the MCP people had nurtured a structured CLI-based --help-equivalent consumable by LLMs and shell completion engines alike. Doing so, you unify "CLI" (trivial deployment; human accessibility) and MCP-style (structured and discoverable tool calling) in a single DWIM artifact.

But since when has this industry done the right thing informed by wisdom and hindsight?

▲

rsalus 9 hours ago | parent [-]

that's a pretty interesting idea. It would be nice if there was such a standard. the approach I'm taking right now: a CLI that accepts structured JSON as input, with an 'mcp' subcommand that starts a stdio server. I bundle a 'help' command with a 'describe' action for self-service guidance scoped to a particular feature/tool.

	▲	yammosk 6 hours ago \| parent [-]
		There are actually a lot of great things you can to to make CLIs more helpful to agents. I use a structured help called '--capabilities' but there is a ton of JIT context you can do from the CLI as well https://keyboardsdown.com/posts/01-agent-first-clis/