Agent tool ergonomics — MCP, bash, and AXI CLIs

How Miton keeps one tool dispatch path, when to connect MCP servers, and when to prefer agent-ergonomic CLIs (including AXI) via bash.

Product stage: Development build
Last reviewed: 2026-07-31
Successful result: The change is visible in the active project.

What this accomplishes

How Miton keeps one tool dispatch path, when to connect MCP servers, and when to prefer agent-ergonomic CLIs (including AXI) via bash.

Miton gives the agent three ways to reach external capability. They are not equal, and they are not interchangeable protocols.

Path	When to use it	Safety path
First-party tools (`read`, `grep`, `web_fetch`, `run_tests`, …)	Default for anything Miton already models	Injection check → permission → bounded output → activity history
MCP servers	Long-lived typed tool surfaces you approve in Settings	Same stack; each server is a trust boundary
`bash` + agent-ergonomic CLIs	One-shot or dense CLI workflows (including AXI tools such as `gh-axi`)	Same stack — `bash` is still a tool call

Architecture decision: ADR-0218. Miton does not add an AXI client or a second protocol beside MCP.

Current availability

This page documents behaviour verified in Miton development builds. Miton is still pre-release and is not publicly downloadable; invited beta users will receive a signed desktop build with automatic updates.

Before you start

A Miton development build and an active project.
A connected cloud or local model, plus any credentials or local runtime required by this task.

What AXI is (and is not)

AXI is ten design principles for agent-friendly CLIs (compact structured stdout, minimal defaults, truncation with an escape hatch, aggregates, empty states, next-step hints) plus community CLIs built that way. It is not a wire protocol like MCP.

Miton steals the principles for its own tool I/O over time, and may consume AXI CLIs when you install them. It will not replace MCP with AXI.

Prefer structured tools, then AXI CLIs, then raw CLIs

When the agent shells out:

Prefer a first-party tool if one exists (run_tests over npm test, search/grep over rg, git_status over git status).
If the job is GitHub / browser / similar and an AXI-style CLI is installed on the machine (gh-axi, chrome-devtools-axi, …), prefer that over raw gh or a heavy multi-tool MCP for the same task — denser stdout, fewer turns.
Otherwise use the ordinary CLI or an approved MCP server.

You do not need to configure AXI inside Miton. Install the binary on your PATH; the agent reaches it through bash like any other command. Approvals, permissions, truncation, and transcript cards behave as they do for every other shell call.

MCP stays the integration substrate

Connect MCP servers in Settings → MCP as today. See MCP client. Catalogue discovery and install approval remain under ADR-0216 — no auto-trust, no second MCP runtime.

When you connect a Chrome DevTools–class MCP server (the tool set includes navigate_page, take_snapshot, and list_pages), Miton registers one compact facade tool — mcp_devtools — instead of dumping every DevTools schema into context. Combined ops (open = navigate + snapshot, click / fill on snapshot uids, raw escape hatch) still run through the same safety checks, permission policy, bounded-output truncation and activity-history path. Ordinary MCP servers keep per-tool registration.

What success looks like

How Miton keeps one tool dispatch path, when to connect MCP servers, and when to prefer agent-ergonomic CLIs (including AXI) via bash. The result remains attached to the active project when you move to another workspace.

Common failures and recovery

Confirm the correct project and model are active.
Read the exact error and the requested permission before retrying.
Retry only the failed step so completed project work remains intact.

MCP client — connect and manage MCP servers
Permissions — approval modes and project trust
Cost and budget — why token-efficient tool I/O matters
ADR-0218 — locked stance
2026-07-21 AXI tool-ergonomics audit — gaps on first-party tools