How-To · 15 min

Krew tools & building your own

Krew is Kaptain's toolbelt: everything a model can do beyond talking. This page maps the families, explains the switches and the approval gate, and shows the supported paths to adding your own tools.

The tool families

Family	Tools
Code intelligence (KodeGraph)	`kodegraph_search / _explore / _context / _callers / _callees / _impact / _node / _files / _index / _status`
Files	`file_read / file_search / file_write / file_edit / patch_apply`
Shell · tests · git	`cli_exec / test_run / git_op`
Web	`web_search / web_fetch / web_fetch_raw / web_extract`
Delegation (local models)	`delegate / delegate_batch / delegate_status / assemble`
Skills	`skill_list / skill_load`
Memory · session	`remember / session_recall`
Agents (A2A)	`agent_list / invoke_agent` + `agent_<name>` per granted sub-agent
Workflow · misc	`todo / time_now / ask_user / agent_cards / vision_analyze`
Models	`kaptain_models / kaptain_chat`

The same belt is what kaptain mcp serves to external CLIs as kaptain-engine (MCP guide).

Switches and the approval gate

Per-tool switches: Krew view ▸ Native Tools — every tool (built-in or from a connected MCP server) has an on/off toggle; the off-list persists.
The gate: risky calls pass a four-mode approval — Ask (popup), Read-only (mutations denied), Auto-approve in workspace, Full access. Set per model (⚙ popover) or per kapsule; a kapsule's trusted_scopes pre-approve specific targets (a path, one MCP server, one web host) without widening anything else.

How tools appear to models

Local and cloud models: plain names, exactly as listed above; tools from connected MCP servers join under their own raw names.
CLI harnesses (Claude/Codex): external-server tools are namespaced ext__<server>__<tool>, so nothing can collide inside the harness.

Build your own tools

Your tool is a program that speaks MCP — any language, any SDK. Three supported ways to plug it in:

Connect it as an MCP server — the standard path. kaptain mcp add mytool -- /path/to/mytool (or the Krew UI). Local stdio or hosted HTTP both work. Full walkthrough: Connect MCP servers.
Ship it inside a Kapsule — give the kapsule an mcp section ({"mcp":{"command":["/path/to/mytool"]}}) and the folder becomes a self-contained unit: your tool server, plus optionally the agent and skills that use it, dropped into kapsules/ as one reviewable piece.
Drop an executable into plugins/ in the data folder — Kaptain runs it as <binary> mcp and registers whatever it serves. The zero-ceremony path for a quick local tool (kept for compatibility; prefer 1 or 2).

However they arrive, your tools land in the same catalog, get the same per-tool switch, and pass the same approval gate as the built-ins — a model can't tell the difference, and neither has to.

What doesn't exist (on purpose)

No inline "paste a shell script as a tool" — a tool is a real program behind a real protocol, so it can be versioned, reviewed, and gated.
The built-in catalog itself isn't user-editable — you toggle built-ins, you don't rewrite them.

Agent-readable version: index.md · Every claim on this page was exercised on a real install before being written. Something missing that cost you time? That is a documentation bug — tell us.