Tools Reference

This page curates the model-facing tools users and plugin developers most often need to know about. The exhaustive source is the generated tool catalog, which boots each tool plugin on a real context and records the exact name, description, and JSON Schema the model receives.

This page describes purpose in plain language and deliberately does not reproduce signatures or schemas. A registered name can be a load-time config (for example @deepseek-ai/dsh-tool-subagent's toolName), so a deployment may expose a package under a different or additional name; where shipped aliases exist — subagent_fork is the fork backend's binding of subagent — they are listed here.

Which tools a session actually sees depends on its composition: an agent preset contributes its own tool rows, so a minimal preset exposes far fewer tools than the default web composition.

Tool lookup

How the groups fit together

The groups below overlap on purpose: report and the job_* tools are shared across delegation and command execution, and exit_plan_mode sits at the boundary between planning and interaction.

File operations

read, write, edit, read_image, glob, and grep form the file toolkit. A read-before-write/edit observation policy backs write and edit; glob and grep spawn the packaged ripgrep binary through the subprocess seam, so they never need a host rg install and never go through the shell layer.

Command execution

bash runs each call in a fresh process. Passing run_in_background: true registers the run with the job runtime, where the job_output/job_kill/job_list tools read, stop, and list it — the same three tools also govern background subagents and PTY sends.

Delegation & orchestration

subagent and subagent_fork delegate self-contained work to children; report, send_message, list_agents, and interrupt_agent manage those children; workflow and ralph orchestrate many agents at once. See Subagents & workflows.

Goals, todos & plans

create_goal/get_goal/update_goal drive a persisted same-session objective, todo_write tracks its steps, and exit_plan_mode hands a plan to the user for approval. See Skills & goals.

Plugin development

The cordis_* tools are an opt-in set: a running dynamic plugin reaches the real runtime, so none ship in a default tree until a composition mounts @deepseek-ai/dsh-cordis-host-runner. See Cordis primer.

Interaction, web & planning

ask_user_question pauses the tool call until a human answers through the UI; web_search and web_fetch keep provider selection behind the web seam so their schemas stay stable across backend swaps; exit_plan_mode presents the plan over the user-questions seam and rejects calls outside plan mode.

Also available, opt-in

Several shipped tools are not in the default surface but load on request — each needs a provider, a platform (Windows or a PTY backend), or a deliberate composition choice. They are catalogued in the tool catalog but sit outside this curated set:

• the six terminal_* tools (terminal_open, terminal_send, terminal_read, terminal_signal, terminal_list, terminal_close) for persistent PTY sessions;
• lsp for language-server queries;
• the five read-only session_event_read, session_event_search, session_event_trace, session_search, and session_trace tools for session-log inspection;
• the schedule_create, schedule_delete, and schedule_list reminder tools;
• the code-mode transport run_code, the standalone str_replace_editor, and the Windows pwsh command tool.

Everything in the lookup table above ships in the default surface; the opt-in tools here require an explicit composition addition.

Next steps