Tool Capabilities
A tool is a structured action an agent can perform. The model proposes which tool to call and which arguments to provide. Captain Who verifies that the tool exists, that the current task has permission to use it, whether approval is required, and how to return the result safely to the model and interface.
Current tool categories
| Category | Common uses |
|---|---|
| Workspace and attachments | List files, search code, and read text, image, and Office content |
| File writing | Apply patches and create or stream writes to files |
| Commands and Git | Run non-interactive commands, wait for long-running tasks, and inspect Git status and diffs |
| Network | Search with Tavily and read web pages |
| History | Find older messages, tool results, and archived fragments in the current conversation |
| Skills | Activate skills, read resources, run reviewed scripts, and prepare installation |
| Office and images | Inspect, render, and create documents through skills, and generate or edit images |
| MCP and browser | Call external MCP tools and control the managed browser |
| Collaboration | Create, notify, follow up with, wait for, or interrupt subagents |
Not every run has every tool. The actual set of tools available to a model request is determined by the project, permissions, model, configuration, activated skills, MCP servers, and built-in capabilities. Activating a skill or browser capability can update the tool set on the next model request.
How users work with tools
You usually do not need to remember tool names or write call syntax. State the goal, scope, and acceptance criteria clearly. For example:
Find every place in the current project that reads APP_ENV and explain how each is used. Read only and do not run commands.When you want the agent to use a specific approach, say so directly:
Run the existing unit tests before making changes. Do not install dependencies. When finished, list the changes from the Git diff.
The agent displays tool activity in the timeline. High-impact operations involving files, commands, MCP, browser, Office, and similar capabilities may pause for approval.
How one tool call completes
- The model proposes a tool and arguments.
- Captain Who checks the arguments, paths, current permissions, and tool version.
- Safe read-only actions run directly; other actions enter approval or are denied.
- The tool returns a structured result, and the agent uses it to choose the next step.
- The call and result are recorded in the current task history.
A tool card in the interface is a safety-oriented summary and may not contain all raw output. Large results are paginated, truncated, or reduced to their beginning and end. The agent can retrieve some text later through history tools when needed.
Command tools are not the right-sidebar Terminal
Agent commands are intended for non-interactive work such as builds, tests, queries, and scripts:
- They do not support arbitrary interactive input.
- An ordinary command waits briefly first. If it is still running, it becomes a managed command session.
- The agent can wait for a result or request an interruption. A managed command session does not accept arbitrary interactive input.
- After an app restart, the session cannot reattach to the old operating-system process, and an uncertain outcome is not rerun automatically.
The right-sidebar Terminal is controlled directly by you, is not included in agent history, and cannot be taken over implicitly by an agent.
Approvals and stopping
An approval is bound to one specific, frozen action. If the target file or critical state changes after approval, execution may fail with a conflict instead of applying blindly to the new content.
Stopping a run cancels subsequent work but cannot guarantee that completed actions are reversed. For form submissions, network requests, external-tool launches, or paid image generation, verify the external system before deciding whether to retry when the interface says “Result pending confirmation.”
Common misconceptions
- A tool appearing in the catalog does not mean the current task has permission to call it.
- A model describing an action as “read-only” is not a safety decision; Captain Who checks independently.
- Full permissions do not disable every safety check.
- A tool-result summary is not a complete log and does not guarantee that an upstream source was not already truncated.
- Skills and MCP can add tools, but they cannot bypass existing project and permission boundaries.