Tools

Tools are the capabilities the agent uses to get work done. They're exposed to the agent through the tool broker, which keeps tool use within controlled boundaries. The agent decides which tools to use for a task; you approve the sensitive ones.

Nothing in the agent bypasses the broker — built-in tools, MCP integrations, and plugin tools all flow through the same mediated layer.

Tool categories

Category	Purpose	Examples
Repository	Read and modify files in the working repository	`read`, `write`, `edit`, `grep`, `glob`
Terminal	Run shell commands (build, test, git) with approval	`bash` — npm, pnpm, git, test runners
Browser	Perform web/browser checks and validation	`web_fetch`, browser automation via plugins
MCP	Call external tools via the Model Context Protocol	Linear, Datadog, Supabase, custom servers
Workspace	Workspace-level context and operations	Skills, todos, subagent delegation

Repository tools

Repository tools are the primary way the agent reads and changes code. Prefer these over shell equivalents — they respect workspace boundaries and produce reviewable diffs.

Tool	Use for	Avoid using bash for
`read`	Read file contents with optional line offset/limit	`cat`, `head`, `tail`
`write`	Create or overwrite a file	`echo >`, heredocs
`edit`	Targeted search-and-replace edits	`sed`, `awk`
`grep`	Search file contents by pattern	`grep` / `rg` in terminal
`glob`	Find files by name pattern	`find` in terminal

Sensitive file reads

Reading .env files and other sensitive paths requires your approval even though the operation is read-only. Keep secrets out of the repo and in .gitignore.

Terminal tools

The bash tool runs non-interactive shell commands in your project directory.

Typical auto-approved	Typically requires approval
`pnpm test`, `npm run lint`, `go test ./...`	`rm -rf`, destructive `find`, disk operations
`git status`, `git diff`, read-only git	Commands touching `.env`, SSH keys, credentials
Package installs in the project	`git push`, force operations, global config changes

Commands run with a timeout (~2 minutes) and truncated output. Use the cwd parameter for monorepo subdirectories instead of embedding cd in the command string.

# Good: agent uses cwd parameter for apps/web
pnpm test
 
# Avoid: unnecessary cd prefixes — the broker sets the working directory
cd /full/path && pnpm test

For long-running dev servers, the agent can start detached processes (e.g. npm run dev) that return immediately while the server keeps running in the background.

Browser tools

Browser capabilities let the agent validate UI behavior, fetch public documentation, or interact with web apps:

Capability	Purpose
`web_fetch`	Fetch and summarize public URLs (docs, API references)
Browser plugins	Full automation — navigate, click, forms, screenshots (e.g. Browserbase Browse)

Browser and network access is especially constrained on cloud agents, where egress policies define what hosts are reachable.

MCP tools

MCP servers expose external tools — issue trackers, observability, databases, cloud APIs — that the broker registers alongside built-in tools. Install a marketplace plugin or configure a custom server to add MCP tools.

MCP calls are governed the same way as built-in tools: scoped credentials, approval when required, and auditable through the broker.

Workspace tools

Tool	Purpose
`todo_write`	Track multi-step progress within a session
`task`	Delegate focused work to a subagent with a bounded step budget
`skill`	Load domain guidance from installed plugin skills
`ask_user_question`	Clarify ambiguous requirements before acting

Subagents spawned via task run autonomously and return a summary — the parent conversation does not see their internal tool calls.

Runtime tool registry

The shared agent in packages/agents-core registers these built-in tools with the model on every run: read, write, edit, grep, glob, bash, web_fetch, todo_write, task, skill, and ask_user_question. Cloud runs add enterprise tools such as query_enterprise_data and canvas builders on top of the same core set. The main agent loop stops after 50 steps; subagents spawned by task inherit the core tools but operate under a separate 100-step budget and cannot call task recursively from within a subagent session.

External tools (MCP) and plugins

You can extend the agent with external tools via MCP, and add ready-made integrations from the plugin marketplace. Plugins may bundle:

MCP server definitions (mcp.json)
Skills and rules for domain-specific guidance
Hooks for lifecycle events (e.g. validate before submit)
Optional agents for specialized workflows

Once installed and connected, plugin tools appear to the agent like any other MCP category tool.

Approvals

Anything that can change your system or reach the network typically requires approval. You can approve a single action or, for trusted commands, allow them for the session.

Review the request
Read the proposed command or file change before approving. Check paths, flags, and targets.
Approve or deny
Deny if something looks wrong; the agent can try a safer alternative.
Session allow (optional)
For repetitive trusted commands (e.g. a test runner), allow for the session to reduce friction.

Review terminal commands

Read commands before approving them — especially ones that delete files, push to remotes, or modify global state.

Scoping tools for your task

Goal	Prompt hint
Local fix only	"Don't push or open a PR"
Read-only investigation	"Inspect only; no file edits"
Use a specific integration	"Use the Linear MCP to file the bug"
Avoid network	"Work offline; no web_fetch or MCP"

Admins can further restrict models, budgets, and cloud network access — see Agent security and Tool broker.

Tool broker

How tool access is mediated, bounded, and audited.

MCP

Connect external systems through the Model Context Protocol.

Plugins

Browse the marketplace for ready-made MCP and skill integrations.