From --help to a reviewed spec
- Draft. Paste the tool's
--helpinto your own AI assistant with the bastn authoring guide. It drafts a spec: which subcommands become actions, which arguments each takes, which values are allowed, and whether the action reads, writes or is destructive. - Review. Read the spec like a pull request. Remove what agents should not have. Tighten patterns and enums.
- Approve. The approved spec becomes tools on every host whose connector has that program on its allowlist.
What a spec looks like
Excerpt from the read-only Linux pack, packs/linux/ip.yaml.
tools:
- name: route_get
effect: read
description: Show the route the kernel would use to reach an address, as JSON
fixed: ["-j"]
argv: ["{fixed}", "route", "get", "{address}", "{flags}"]
args:
address: { type: string, required: true, description: "Destination IPv4 or IPv6 address" }The pattern on address is omitted here. The agent sees a tool called route_get with one typed argument. It does not see a free-form ip command, and it cannot add flags the spec does not define.
Why not wrap the CLI yourself?
Open-source projects already turn a CLI's --help into MCP tools for a local agent (any-cli-mcp-server, cli2mcp). That is a start on a laptop. For a fleet you also need an identity per agent, a different set of tools per agent, argument validation before anything runs, approvals for destructive actions, a connector on each host, and an audit trail. bastn is those parts.
Scripts too
A script becomes an action the same way. When no action fits a job, an agent can submit a new script. It is held until someone reviews it, approval pins its hash, and the connector re-checks the hash before every run, with a 60-second cap.
Services with a spec
Internal services with an OpenAPI spec can be imported as tools under the same policy. See internal APIs as tools.
Different tools per agent, same CLI
The spec defines what can exist. Each agent's policy picks its slice: one agent gets status, another gets status and rollback on staging, held for approval.