cmdhubInstall
Cmdhub Local CLIs for real workflows

Predictable commands for everyday SaaS tools.

Cmdhub gives agents and humans a consistent command layer for mail, calendar, files, tasks, chat, docs, and structured transforms.

curl -fsSL https://cmdhub.run/install.sh | bash
Helper ready
cmdhub session
$ cmdhub get gmail gcal gdrive mscal msdrive mstodo msoutlook slack notion agent
[plan] install adapters: gmail, gcal, gdrive, mscal, msdrive, mstodo, msoutlook, slack, notion, agent
[ok] binaries ready
[next] run provider auth only for the tools your workflow needs
$ gmail message get m1 --jsonl | agent adapt --to "gcal event create"
{
  "status": "validated",
  "source_schema": "gmail.message.v1",
  "target_schema": "gcal.event.create.input.v1",
  "next": "pipe into gcal event create"
}
$

Brittle scripts vs. structured control.

Most SaaS automation becomes a mix of provider SDKs, local scripts, auth edge cases, and inconsistent output. Cmdhub makes the command contract explicit.

  • The old way
    Hard-coded tokens, inconsistent errors, and manual data reshaping.
  • The cmdhub way
    Shared auth, JSON/JSONL streams, command schemas, and doctor checks.
Ad hoc script python3 ./utils/gmail_to_calendar.py --token "$GOOGLE_TOKEN" --raw-json
arrow_downward
cmdhub command chain gmail message get m1 --jsonl | agent adapt --to "gcal event create"
Product contract

CLIs that agents can use without extra ceremony.

Cmdhub adapters are shaped around high-value workflows, not provider endpoint checklists. The target is a command surface that is obvious, inspectable, safe, and compact enough for agents and humans to keep in working memory.

  1. 01

    Agent-native command grammar

    Command families, nouns, aliases, examples, and help screens line up with how agents naturally try to use tools.

  2. 02

    Workflow-first scope

    Adapters cover the jobs users actually need: read, search, inspect, create, update, recover, and safely clean up.

  3. 03

    Information-dense output

    Default output is terse and readable, with rich enough fields for fast decisions and JSON or JSONL when full fidelity matters.

  4. 04

    Short refs instead of opaque IDs

    Lists return memorable refs like m1, f1, and c1 so follow-up commands do not depend on long provider IDs.

  5. 05

    Safety by default

    Catastrophic admin actions stay out of scope. Normal destructive actions require preview, dry-run, recovery context, or an explicit --yes.

  6. 06

    Exact next steps

    Useful screens end with command-shaped follow-ups, using the refs and profiles already visible in the output.

  7. 07

    Inspectable auth

    Each provider makes setup, scopes, status, profile selection, and whoami checks explicit before an agent acts.

  8. 08

    Reference-quality terminal screens

    List, detail, empty, error, auth, and mutation screens are designed as product surfaces, not incidental logs.

Native adapters

The current release focuses on the tools people already live in: mail, calendar, files, tasks, chat, docs, and schema-aware transforms.

Gmail GCal MSCal GDrive MSDrive MSTodo Outlook Slack Notion Agent cmdhub

account_tree Schema-aware transforms

`agent adapt` sits between deterministic CLIs. It transforms one typed contract into another, validates the result, and leaves side effects to the destination CLI.

gmail message get m1 --jsonl | agent adapt --to "gcal event create" | gcal event create

shield_lock Shared auth

Use `cmdhub auth login` for the hub account and each provider CLI's auth commands for service credentials.

gmail auth status --profile work

health_and_safety Doctor checks

Verify install state, credential storage, provider links, and tool-specific health before workflows fail.

data_object JSON and JSONL output

Human-readable output is the default. Switch to machine-readable JSON or streaming JSONL when a script, CI job, or agent needs to consume the result.

Technical Q&A

Is cmdhub an agent?

No. Cmdhub is the command layer. Agents can use it, but deterministic CLIs own the real app actions.

Is this an MCP server?

Not primarily. The CLI contract is the durable primitive. MCP can be one transport later.

Is everything hosted?

No. The CLIs run locally. The hosted app handles account login, registry, docs, and provider auth flows where useful.

What is still changing?

The product is still being tightened around install, auth, schemas, docs, and a small set of reliable workflows.