Guide · October 16, 2026 · Updated October 18, 2026 · 7 min read

Krew and MCP: how models get their tools

A model on its own can only write text. Tools let it read files, run commands and search the web. This guide explains what a tool call is, why the open Model Context Protocol matters, and how Krew gives every model in Kaptain the same tools behind the same approval gate.

What a tool call is

A language model reads text and writes text. It cannot open a file, run a command or fetch a web page by itself. A tool call is how it asks for one of those things. The exchange goes like this:

1. The program running the model sends, with each request, a list of the tools on offer: a name, a description and the parameters each one takes.
2. When the model decides a tool would help, it replies with a structured request instead of prose: which tool, with which arguments.
3. The program checks the request, runs the tool and sends the result back.
4. The model reads the result, then calls another tool or writes its answer.

A request to read a file can be as small as this:

file_read  {"path": "docs/notes.md"}

Kaptain’s file_read answers with numbered lines, one page at a time sized to the model’s context window (about 380 lines at a 32K window), and tells the model the offset to continue from.

Two things follow. First, the model never touches your machine directly. Every action passes through the program that runs the tools, and that is where you decide what is allowed. Second, each round sends the conversation back to the model, which costs time and tokens. That is why a new Kaptain chat starts with its Tools switch off. A kapsule run always has tools.

Some models write their calls as plain text instead of the native format. The Tool calls setting in a model’s ⚙ handles this: Auto switches to a taught text format when it sees that happen.

What MCP is

For a model to use a tool, the program running the model has to know how to talk to the program that provides the tool. Without a shared format, each assistant needs its own plugin system, and a tool written for one does not work in another.

MCP, the Model Context Protocol, is an open standard for connecting tools to models. A tool provider writes an MCP server: a program that lists its tools and runs them when asked. Any MCP client, meaning any assistant that speaks the protocol, can then use that server. A server runs on your machine as a command, talking over standard input and output (stdio), or remotely over HTTP.

An open protocol matters for three reasons:

• Your tools outlive your assistant. A server you rely on keeps working when you change the program that runs the model.
• Tools are real programs. They can be reviewed, versioned and switched off like any other software. Kaptain deliberately offers no way to paste a shell script as a tool, for this reason.
• Anyone can write one. A tool is a program that speaks MCP, in any language.

Krew: one gateway for every model

Krew is Kaptain’s toolbelt: everything a model can do besides talk. It is also a gateway. Every tool is connected, switched and gated in one place, whichever model is answering.

• Built-in tools. Kaptain ships 36, in families: code search through KodeGraph, files, shell, web, skills, memory, workflow, delegation, vision and agents. Each has its own switch under Krew › Native Tools, and nothing is off by default.
• Your MCP servers. Their tools join the same catalogue, for every model, behind the same switches.
• One way in for every route. Local and cloud models call Krew’s tools directly. Claude Code and Codex reach them through an MCP server named kaptain-engine, which Kaptain attaches to every turn with the chat’s project, approval mode and grants. The servers you connected are passed through to the CLIs as well.

The gateway changes where you set things up. A server you added to Claude Code yourself is Claude’s alone: by default Claude still loads it inside Kaptain, but no other model can use it. Connect it to Kaptain instead, once, and your local model, your cloud model and both CLIs can use it under one set of rules.

It works in the other direction too. kaptain mcp register claude adds kaptain-engine to your own Claude Code setup outside Kaptain. There it offers only Kaptain’s reading tools, because no Kaptain approval prompt exists to gate the rest.

Adding your own MCP servers

Install the server’s own runtime first, for example Node for a server started with npx. Then open Krew › MCP Servers:

• + Add from JSON takes the {"mcpServers": {...}} block from the server’s README, as it is.
• Add manually takes a lowercase name, then a local command with its arguments or a remote URL. Add one KEY=VALUE per line: environment variables for a local server, headers for a remote one. For servers that need a sign-in, How does this server authenticate? offers OAuth.

Each row shows the server’s status, its tool count and any error. If a server crashes or fails its handshake, the status says how it ended and the last lines it wrote. Connected tools appear in Native Tools with their own switches.

The same from a terminal:

$ kaptain mcp add notes --env 'NOTES_TOKEN=${NOTES_TOKEN}' -- npx -y <server-package>
$ kaptain mcp add tracker --url https://tracker.example.com/mcp --oauth
$ kaptain mcp list

Keep the single quotes around ${NOTES_TOKEN}. Kaptain stores the variable, not its value, and reads it from its own environment each time the server connects, so the secret never lands in a config file. Servers are saved in mcp_servers.json in the data folder, and OAuth tokens are kept in a file of their own. A local command that is not installed is refused before anything is saved.

Two more ways in land in the same catalogue: a server shipped inside a kapsule with its mcp entry, or an executable dropped into plugins/ in the data folder.

Why approvals exist

Giving a model tools means letting it act on your machine. A model can misread a task, act on a wrong guess, or follow instructions hidden in a page or file it was asked to read.

The approval gate is where Kaptain draws that line. Every tool call that could change something passes one gate: built-in tools, MCP tools and shell commands alike. Each model has a mode in its ⚙ settings, and each kapsule can set its own:

On local and cloud models the last two behave the same. They differ for Claude Code and Codex, which have their own permission systems; Kaptain maps each mode onto them. Read-only, for example, becomes Claude Code’s plan mode and Codex’s read-only sandbox.

Some rules hold whatever the mode:

• Reading inside the project never asks. Neither do read-only shell commands such as ls, git status or git diff.
• Running tests always asks in Ask mode.
• Writing outside the project is refused, unless a kapsule’s allowed paths grant that folder.
• Every call to an MCP server’s tools asks in Ask mode, read-only or not, unless a kapsule pre-approves that server. Connect only servers you trust.
• A command that runs sudo opens a pop-up in Kaptain, whichever model or CLI runs it, and the first one in a task asks for your computer password; in Read-only it is not run. The password goes to sudo and never to the model. Turn the Sudo requests switch off, under Settings › Model Handling, and such commands are not run at all.
• An approval waits 300 seconds once shown. When a run is unattended and nobody can answer, the model is told so, rather than told you refused, and it does what it can without that step.

The gate is what makes real tools safe to hand over: nothing risky happens outside the rules you set.

Where to go next

Kaptain Docs has the details: Tools and approvals, Approval modes, the Krew tools reference, Connect an MCP server, Kaptain as an MCP server and the Security model.

This is the second guide in a series, after Choose your parts. The third, What is a kapsule?, puts tools, permissions and memory together into an agent.