Toolsets Reference

Toolsets are named bundles of tools that control what the agent can do. They're the primary mechanism for configuring tool availability per platform, per session, or per task.

How Toolsets Work

Every tool belongs to exactly one toolset. When you enable a toolset, all tools in that bundle become available to the agent. Toolsets come in three kinds:

• Core — A single logical group of related tools (e.g., file bundles read_file, write_file, patch, search_files)
• Composite — Combines multiple core toolsets for a common scenario (e.g., debugging bundles file, terminal, and web tools)
• Platform — A complete tool configuration for a specific deployment context (e.g., minerva-cli is the default for interactive CLI sessions)

Configuring Toolsets

Per-session (CLI)

minerva chat --toolsets web,file,terminal
minerva chat --toolsets debugging        # composite — expands to file + terminal + web
minerva chat --toolsets all              # everything

Per-platform (config.yaml)

toolsets:
  - minerva-cli          # default for CLI
  # - minerva-telegram   # override for Telegram gateway

Interactive management

minerva tools                            # curses UI to enable/disable per platform

Or in-session:

/tools list
/tools disable browser
/tools enable video

Core Toolsets

Toolset	Tools	Purpose
bittensor	bittensor_account, bittensor_metagraph, bittensor_subnet, bittensor_subnets	Read-only Bittensor chain data: subnets and their economics, one subnet's hyperparameters, a subnet's metagraph, and an address's balance, stakes and registrations. On by default (part of the core tools). The SDK installs on first use; with security.allow_lazy_installs: false and no SDK installed the tools are hidden. Never signs extrinsics or opens a wallet. See Bittensor Chain Tools.
browser	browser_back, browser_cdp, browser_click, browser_console, browser_dialog, browser_exec, browser_get_images, browser_navigate, browser_press, browser_scroll, browser_snapshot, browser_type, browser_vision	Core browser automation. In the default Browser Use mode (the browser-use CLI is runnable and browser.backend is unset) the agent gets the single browser_exec tool instead of the built-in browser_* tools; browser.backend: off or Camofox keeps the built-in tools. browser_cdp and browser_dialog are gated at runtime — registered only when a CDP endpoint is reachable at session start (via /browser connect, browser.cdp_url config, Browserbase, or Camofox). browser_dialog works together with the pending_dialogs and frame_tree fields that browser_snapshot adds when a CDP supervisor is attached.
clarify	clarify	Ask the user a question when the agent needs clarification.
code_execution	execute_code	Run Python scripts that call Minerva tools programmatically.
coding	composite (file + terminal + search + web + bittensor + skills + browser + todo + memory + session_search + clarify + code_execution + delegation + vision)	Coding-focused bundle for software work: file editing, terminal, search, web docs, skills, browser, delegate, and code execution.
cronjob	cronjob_manage	Schedule and manage recurring tasks.
debugging	composite (file + terminal + web)	Debug bundle — file, process/terminal, web extract/search.
delegation	delegate_task	Spawn isolated subagent instances for parallel work.
discord	discord	Core Discord text/embed/DM actions (gateway-only). Active on the minerva-discord toolset.
discord_admin	discord_admin	Discord moderation (bans, role changes, channel management). Active on the minerva-discord toolset; requires the bot to hold the relevant Discord permissions.
file	patch, read_file, search_files, write_file	File reading, writing, searching, and editing.
computer_use	computer_use	Background desktop control via cua-driver — does not steal cursor/focus. Works with any tool-capable model. macOS, Windows, and Linux; requires cua-driver on $PATH.
context_engine	(varies)	Runtime tools exposed by the active context-engine plugin (empty until a plugin populates it).
image_gen	image_generate	Text-to-image generation via FAL.ai (with opt-in OpenAI / xAI backends).
kanban	kanban_attach, kanban_attach_url, kanban_attachments, kanban_block, kanban_comment, kanban_complete, kanban_create, kanban_heartbeat, kanban_link, kanban_list, kanban_request_changes, kanban_request_review, kanban_show, kanban_unblock	Multi-agent coordination tools. Registered for dispatcher-spawned task workers (MINERVA_KANBAN_TASK) and for profiles that explicitly list the kanban toolset by name (the all/* wildcard does not enable it). Workers mark tasks done, request first-class review, block, heartbeat, comment, and create/link follow-up tasks; orchestrator profiles additionally get board-routing tools like list/unblock. delegate_task children are not Kanban run owners: their schema strips/disables this toolset and runtime guards reject direct board mutations, even if parent MINERVA_KANBAN_* env vars are present.
memory	memory	Persistent cross-session memory management.
desktop_ui	annotate_preview, apply_layout, close_terminal, desktop_preview, drive_preview, focus_pane, gui_tour, react_to_message, read_terminal, read_window_below, setup_mcp, show_tip	Affordances that act on the Minerva desktop app itself — read/close the embedded terminal pane, open, read, close (desktop_preview), interact with, and annotate the in-app browser, identify the OS window behind the app, reveal a pane or apply a saved layout preset, react to a message, propose an MCP server as an install/enable/authorize card, run a guided tour or show a one-line tip anchored to a UI element (gui_tour and show_tip withdraw themselves when tours or tips are turned off). Enabled for sessions whose source is the desktop app, whichever backend it's connected to (local, remote URL, or SSH). Never present on CLI, TUI, messaging, or cron sessions.
project	desktop_project	Create, list, and switch desktop Projects (named, multi-folder workspaces). GUI / desktop sessions only.
safe	image_generate, vision_analyze, web_extract, web_search (via includes)	Read-only research + media generation. No file writes, no terminal, no code execution.
search	web_search	Web search only (without extract).
session_search	session_search	Search past conversation sessions.
skills	skill_manage, skill_view, skills_list	Skill CRUD and browsing.
terminal	process_manage, terminal	Shell command execution and background process management.
todo	todo_list	Task list management within a session.
tts	text_to_speech	Text-to-speech audio generation.
vision	vision_analyze	Image analysis via vision-capable models.
video	video_analyze	Video analysis and understanding tools (opt-in, not in the default toolset — add explicitly via --toolsets).
web	web_extract, web_search	Web search and page content extraction.
x_search	x_search	Read-only public X discovery via xAI's built-in x_search Responses tool; no authenticated X API reads or account actions. Off by default; opt in via minerva tools. Schema only registered when xAI credentials (SuperGrok OAuth or XAI_API_KEY) are configured.

Platform Toolsets

Platform toolsets define the complete tool configuration for a deployment target. Most messaging platforms use the same set as minerva-cli:

Toolset	Differences from minerva-cli
minerva-cli	Full toolset — the default for interactive CLI sessions. Includes file, terminal, web, bittensor, browser, memory, skills, vision, image_gen, todo, tts, delegation, code_execution, cronjob, session_search, clarify, computer_use, and the kanban tools (all check_fn-gated at runtime).
minerva-acp	Drops clarify, cronjob_manage, image_generate, text_to_speech, computer_use, and the kanban tools. Focused on coding tasks in IDE context.
minerva-api-server	Drops clarify, text_to_speech, computer_use, and the kanban tools. Keeps everything else — suitable for programmatic access where user interaction isn't possible.
minerva-cron	Same as minerva-cli.
minerva-telegram	Same as minerva-cli.
minerva-discord	Adds discord and discord_admin on top of minerva-cli.
minerva-slack	Same as minerva-cli.
minerva-webhook	Restricted safe subset — only web_search, web_extract, vision_analyze, and clarify. Webhook-triggered runs get no terminal, file, or browser access.
minerva-gateway	Internal gateway orchestrator toolset — union of the four messaging platform toolsets (minerva-telegram, minerva-discord, minerva-slack, minerva-webhook). It does not include minerva-cli, minerva-acp, minerva-api-server or minerva-cron. Used when the gateway needs to accept any message source.

Dynamic Toolsets

MCP server toolsets

Each configured MCP server generates a mcp-<server> toolset at runtime. For example, if you configure a github MCP server, a mcp-github toolset is created containing all tools that server exposes.

# config.yaml
mcp_servers:
  github:
    command: npx
    args: ["-y", "@modelcontextprotocol/server-github"]

This creates a mcp-github toolset you can reference in --toolsets or platform configs. The bare server name (github) works as an alias. If a server is named like a built-in toolset (browser, web), that name resolves to the built-in tools plus the server's mcp__<server>__* tools; neither side shadows the other.

Browser backend toolsets

Two browser toolsets are registered by the tools themselves rather than declared in toolsets.py, so they only exist when their backend does:

Toolset	Tools	Registered when
browser-cdp	browser_cdp, browser_dialog	a CDP endpoint is reachable at session start (/browser connect, browser.cdp_url, Browserbase, or Camofox)
browser-use	browser_exec	the browser-use CLI is runnable and browser.backend is unset or browser-use

Plugin toolsets

Plugins can register their own toolsets via ctx.register_tool() during plugin initialization. These appear alongside built-in toolsets and can be enabled/disabled the same way.

Project-specific bundles

There is no custom_toolsets: key. toolsets: in config.yaml (and --toolsets on the command line) takes a list of existing toolset names — built-in, mcp-<server>, plugin- registered, or all/* — which are unioned together. To get a project-specific bundle, list the pieces you want:

# config.yaml
toolsets:
  - file
  - terminal
  - code_execution
  - web
  - vision

A genuinely new named toolset comes from a plugin: register tools under a toolset name with ctx.register_tool() and it resolves like any built-in.

Wildcards

• all or * — expands to every registered toolset (built-in + dynamic + plugin)

A handful of tools have an additional availability check on top of toolset membership and are not turned on by all/* alone:

• Capability-gated tools (browser, computer_use, code_execution, cronjob) appear only when their backend/credential prerequisite is configured.
• Workflow-gated tools — the kanban toolset — are deliberately opt-in. all/* does not enable kanban. The gate (tools/kanban_tools.py) reads the toolsets: list in config.yaml only, so kanban must be listed there — a --toolsets kanban command-line flag does not satisfy it. The other way in is to be a dispatcher-spawned worker with MINERVA_KANBAN_TASK set. Kanban tools mutate shared board state, so they stay off by default even under all.

Relationship to minerva tools

The minerva tools command provides a curses-based UI for toggling individual tools on or off per platform. This operates at the tool level (finer than toolsets) and persists to config.yaml. Disabled tools are filtered out even if their toolset is enabled.

See also: Tools Reference for the complete list of individual tools and their parameters.