Use case: CLI + integrations, end to end

The complete loop: connect a tool, let an agent decide to act, watch the action land in the approval queue, and approve it from the CLI — at which point it really happens in the connected system. This is the same control plane an agent uses via MCP; the CLI is the human seat at it.

This walks through one realistic scenario with connectors and the miqro CLI. It assumes you've run miqro login.

The scenario

A ServiceNow-connected support agent wants to create an incident for a customer issue. Creating an incident is an action (a write), so it is not executed silently — it routes through the approval gate, and a human approves it with one command.

 connect ServiceNow ──▶ agent reads context ──▶ agent proposes "create_incident"
                                                        │
                                          lands in the action queue (awaiting approval)
                                                        │
                              miqro queue approve  ◀── you review it in the CLI
                                                        │
                              executor runs it ──▶ incident created in ServiceNow

Step 1 — see the capability before you wire it

Inspect exactly what the connector can do, and which operations require approval:

miqro connectors show servicenow

provider    servicenow
name        ServiceNow
...
Actions (action_send):
OP               API                           RISK    APPROVAL
create_incident  POST /api/now/table/incident  medium  yes
add_work_note    PATCH /api/now/table/...       low     no

create_incident is APPROVAL: yes — that's the contract the queue will enforce. (This is the connector's declared capability manifest; the agent cannot exceed it.)

Step 2 — connect the tool

Paste-key providers connect in one command. The credential is live-validated against the provider before anything is stored, then the secret goes to Railway (never the database) and the capability is armed:

miqro connect servicenow --tenant "$TENANT" \
  --config instance_url=https://acme.service-now.com
# → prompts for the credential (hidden), then:
#   provider  servicenow
#   status    connected
#   ✓ connected

OAuth providers (Slack, HubSpot, Jira, …) connect through the dashboard authorize flow instead — miqro connect is for paste-key/token providers.

Step 3 — an agent proposes an action

When an agent decides to create the incident, it does not call ServiceNow directly. It enqueues a proposal, which appears in the queue awaiting a human:

miqro queue ls --status awaiting_confirmation --tenant "$TENANT"

ID        STATUS                  KIND                     PROVIDER    OP               TIER
act_01HZ  awaiting_confirmation   integration.action_send  servicenow  create_incident  review_high

Inspect the exact payload before you decide:

miqro queue ls --status awaiting_confirmation --tenant "$TENANT" --json \
  | jq '.[0] | {id, op: .target_ref.op, payload}'

Step 4 — approve (or reject) from the CLI

miqro queue approve act_01HZ        # → status: queued; the executor now runs it
# or
miqro queue reject  act_01HZ        # → status: cancelled; nothing happens in ServiceNow

On approve, the executor picks up the row, calls the ServiceNow connector, creates the incident, and writes the outcome to the audit log. Your email is recorded as the approver.

Step 5 — confirm it ran

miqro queue ls --status succeeded --tenant "$TENANT" --json | jq '.[0].result'

Why this matters

The same four moving parts — connector capability, agent proposal, approval gate, executor — are what the agentic MCP control model uses. The CLI doesn't bypass any of them; it gives a human a fast, scriptable seat at the exact same table. An operator approving act_01HZ in the terminal and an agent staging a write through MCP are operating one control plane.

A note on safe automation

You can script approvals (miqro queue ls … --json | jq -r '.[].id' | xargs -n1 miqro queue approve --yes), but auto-approving collapses the human gate. Reserve batch-approve for action kinds you have explicitly reviewed and trust; keep create_incident-class writes (anything APPROVAL: yes / review_high) on a human.