What the agent can do

Every action Nemocode takes in a mission is a call to one tool. This page lists them all: what each is for, what stops it, and what you see when it runs.

One tool, one thing

Each tool does exactly one job. Reading three files is three read_file calls, not one call with a list. The agent sends the calls that do not depend on each other together in a single answer, so they run side by side — three reads, two searches and a test run can all be in flight at once. Calls that depend on an earlier result wait for it. You see each call as its own line in the transcript.

By default the agent has all of its tools from the first request on. If you switch Lazy tools on (Settings, or NEMOCODE_LAZY_TOOLS=on), a mission starts with a small core set and the agent loads the rest with load_tools the moment it needs them. That keeps every request shorter; it changes nothing about what the agent may do.

Not every tool is offered in every situation. advisor is there only when you switched the advisor on; describe_image only when the main model cannot see images and you assigned a vision model; send_to_session only with NEMOCODE_CROSS_SESSION_TALK=1; web_search only when a search provider is available; query_pum only once the project memory has content; and remember only with NEMOCODE_REMEMBER_TOOL=1 — otherwise the agent proposes a fact with a <remember> block in its reply, with the same effect. To change existing files the main agent uses edit_files; edit_file is what subagents use.

What stops a tool

Whether a call runs, asks you, or is refused depends on the mode you are in and on your own allow, ask and deny rules:

Mode	Reading and searching	Editing files	Commands
Read only	runs	refused	refused
Plan	runs	refused until the plan is approved	refused until the plan is approved
Ask	runs	asks	asks
Accept edits	runs	runs	asks
Auto	runs	runs	runs

Handing work to a subagent counts as writing: delegate_task and run_workflow are refused in Read only and Plan, and run_workflow asks you first in every mode. create_agent, schedule_task and send_to_session are refused in Read only and Plan as well, because each has a lasting effect. A deny rule beats an ask rule, and an ask rule beats an allow rule. Tools from MCP servers are refused in Read only and Plan, too.

Some limits hold in every mode. The agent cannot write to Nemocode's own project data, and in the .nemocode folder of a project only .nemocode/scratch/ is writable — that is where temporary files and tool caches go. Paths outside the project are refused until you grant them; see Permissions & safety.

Reading and searching

Tool	What it does
`read_file`	Read one file, up to 2,000 lines at a time. `offset` and `limit` page through a longer one. Lines come numbered; the numbers are not part of the file. A file that is already in the conversation and unchanged is not sent again. A file larger than 256 KB, or a binary file, is refused; the agent searches it instead.
`find_files`	Find files by name pattern, such as `*/.spec.ts`, optionally below one folder. It also lists a folder.
`search_code`	Search file contents with a regular expression. `include` limits it to matching files, for example `*.{ts,tsx}`; `paths` limits it to folders. This is the agent's first move when it looks for code.
`lsp`	Ask a real language server: go to a definition, find references, hover, list the symbols of a file or the whole project, implementations, call hierarchy, and `diagnostics` for compiler and type errors. It works for Python, TypeScript/JavaScript, Go and Rust, as far as the language server is installed (`pyright`, `typescript-language-server`, `gopls`, `rust-analyzer`); `nemocode doctor` shows which it finds and how to install the others. Without one for the language, the agent falls back to `search_code`.
`web_fetch`	Fetch one web page as plain text. Read only, no scripts run. Pages behind a login or a paywall are not bypassed.
`web_search`	Search the web: titles, links and snippets for one query. The agent then fetches the promising pages.
`search_history`	Search the text of this project's earlier sessions and missions — your messages, tool calls and results, goals — also for things that were compacted away. Other projects are searched only if you allowed it for this project.
`describe_image`	Have a vision model look at an image the agent cannot see itself, such as a screenshot it took, and answer a specific question about it. Images you attach yourself need no tool.

Changing things

Tool	What it does
`edit_file`	Replace one exact piece of text in a file. The text must occur exactly once unless `replace_all` is set. Small misses in whitespace are retried and the result says so.
`edit_files`	Apply one patch that may change any number of existing files: edit, delete and rename in a single call. A patch that was already applied is recognised and not applied twice.
`create_file`	Create one new file. It does not overwrite unless `overwrite` is set, and the agent is told to prefer changing an existing file — and not to create documentation files nobody asked for.
`update_status`	Rewrite `NEMOCODE.md`, the short status note of the project (where things stand, how to run it, open points). At most once per mission, and only if something lasting changed.

Every file change can be reverted with /undo. If a file changed on disk since the agent read it — a formatter, a build, you — the edit is refused and the agent reads it again first, so nothing is overwritten silently.

Running things

Tool	What it does
`run_command`	Run one shell command, with a short reason that you see in the approval. Dependent steps are chained with `&&`; independent commands are separate calls. A command that is still running after about ten seconds moves to the background instead of being killed, and the agent gets a shell id to wait on. There is no terminal: commands that ask questions or open an editor cannot work. Long output is saved to a file and the agent searches it.
`run_background`	Start something that keeps running — a dev server, a watcher, a long install — and return its first output, so starting and checking is one call. It survives the end of the mission. Its output reaches the agent when it exits.
`background`	Look after those background commands: `list` them, show their `output`, `kill` one, or `wait` until the output matches a pattern or the command exits — instead of sleeping and checking.

Commands follow the mode table above. A small list of destructive commands is refused in every mode, and risky but legitimate ones — a force push, publishing a package, piping a download into a shell — always ask. See What Nemocode refuses, always. The agent is also told to avoid history-rewriting git commands and to commit or push only when you ask.

Planning and asking

Tool	What it does
`update_plan`	Keep the visible plan current: each item is pending, in progress, done or cancelled. You watch it change live. The mission is not finished while items are open.
`enter_plan_mode`	The agent proposes planning first for a big or hard-to-reverse job. You are asked; only a yes switches to Plan mode (read-only), and a no means it builds without a plan.
`exit_plan_mode`	Presents the finished plan to you. If you approve, writing and commands switch on and the same agent builds it in the same mission. If you refuse, it stays in plan mode and revises. The plan is saved with the project. With Auto-approve plans switched on, the plan is still written down and the build starts at once.
`ask_user`	Ask one to three related multiple-choice questions when the request is vague or a real choice cannot be settled from the code. The first option is the agent's recommendation. You can always answer in free text. Your answers are kept as project knowledge.
`advisor`	Consult a stronger model at a decision point — before a large change, after two failed attempts, before declaring done when unsure. It gives judgement and does nothing itself. Choose its model under Settings ▸ Models.
`dashboard_widget`	Pins a small live display to the project dashboard: a number, a progress bar, a list, a table or a short note. Data only, no HTML. The agent keeps one widget per thing it tracks and updates it; you remove one with the × on its card. At most 12 per project.
`ideas`	The project's list for later: bugs, features, notes and questions that came up but are not part of this mission. `add`, `list`, `close`, `drop`. It belongs to the project, so later sessions see it. Also on `/ideas`.
`request_path_access`	Ask you for a folder outside the project when a path was refused. The approval names the folder and the reason. Granted for good, the folder becomes a root the agent can address.
`use_skill`	Load the full instructions of an installed skill when it fits the task.
`skill_manage`	Only the curator in a harvest session has it, and only while skill learning is on. It creates and improves personal skills in `~/.nemocode/skills`. It can change only skills it wrote itself; deleting archives. See skills.
`load_tools`	Activate tools that are not in the starting set. Cheap; they stay available for the rest of the mission.

Project knowledge

These read from and write to the project memory. The agent can read it freely; it can only propose additions, and nothing enters the memory without you.

Tool	What it does
`query_pum`	Read the project memory (the Project Understanding Map). `search` for a topic in plain words, `node` for one fact in full with its pointer into the code, `relations` for what is linked to it, `grep` for an exact pattern, `conflicts`, `pending` for what waits at the gate, and `proofs` for evidence awaiting review. Facts with a low weight are treated as hypotheses to check, not as truth.
`remember`	Propose one lasting fact: a decision and its reason, a contract between files, a convention, a pitfall. It points at the code instead of pasting it, and it waits at the gate for your decision. Activity logs do not belong here.

Subagents and other sessions

Tool	What it does
`explore`	Give a codebase question to a read-only subagent; only its conclusion comes back, so the main conversation stays small. It runs in the background and several can run at once (`thoroughness`: quick, medium or thorough). It answers; it never changes anything.
`delegate_task`	Hand an independent, well-scoped piece of a build to a subagent with write access. It cannot see the conversation, so the task must be self-contained. In a git project each one works in its own worktree that is merged back; up to four run at once. The agent must not also do the same piece itself.
`run_workflow`	Run several subagents as a graph: fan-out over a list, branches, loops, waiting for all or any. It always asks you first, because a graph can start many agents. See Workflows.
`create_agent`	Save a reusable custom agent — a named role with its own instructions — for recurring work. It is saved as a file and used through the read-only `explore` tool, or by making a session run as it.
`send_to_session`	Send a message to another session of yours, for a second opinion from another role. You approve every message, and chains of messages stop after a few hops.
`schedule_task`	Schedule a mission for later — once (in 20 minutes, at 18:27) or repeating (daily, at least every minute). The server runs it, so it needs the server to be running. See Scheduled tasks.

Anything you add through MCP appears next to these under the server's name, as mcp__server__tool. They are refused in Read only and Plan; otherwise they run without asking, and your allow, ask and deny rules do not apply to them.