Enabling, running and understanding the limits of tools available to the model.
With a model that supports tools, ZeroChat can alternate model requests and executions: the model requests a tool, receives its result and decides the next step. A tool may run in the browser, on the local server or in an MCP service.
When the provider has no native tool calling, as with WebLLM, tools are described in the prompt and the model requests them with <tool_call> blocks in its text. ZeroChat also interprets those blocks when a provider returns them as text instead of native calls.
Enable the tools you need in Settings and review their permissions. The agent has no step limit: it continues while the model requests tools. It only stops by itself if it repeats the same call 5 times in a row or alternates two calls 5 times without writing anything new for you; it then shows a notice and does not request a summary. To stop it earlier, use the stop button; completed actions are not undone.
For long projects, the agent can keep the plan, milestones and decisions across chats: see Project management.
In Settings → Agent, each tool uses a soft background without nested frames. Descriptions adapt to the available width and each switch stays beside its tool.
Native and MCP tools share collapsible cards grouped by execution. On mobile, the status appears below the name. Charts remain open outside the groups. The subagent also stays outside, in its own card, because it groups inside it the calls of each step below that step's text; MCP screenshots can keep their card open to display the image.
Automatic collapsing affects only the tool that has just finished: groups and previous executions you opened stay open.
| Tool | Use and limits |
|---|---|
execute_javascript | Calculations and transformations in an isolated browser environment. |
search_web | DuckDuckGo search through the local server or, without it, Jina Reader. Blocks or limits from DuckDuckGo or Jina can cause failures. |
fetch_web_page | Retrieves text and images from public pages; it does not replace a signed-in browser. |
download_doc | Downloads a PDF or an office document (DOCX, XLSX, PPTX, ODT, ODS, ODP) and extracts readable text, subject to reader limitations. |
download_image | Downloads a web image (PNG, JPEG, WebP, GIF) up to 10 MB and feeds it as multimodal input to the model for visual inspection. Requires a vision-capable model. |
render_chart | Displays data in SVG charts; it does not validate data or calculations. |
list_documents, search_knowledge_base, read_knowledge_chunk, read_knowledge_image | Query active RAG branches. |
ask_user | Asks you a question with 2 to 4 options when it needs your decision, and ends its turn. Choosing an option sends it as your next message, together with anything you had typed; you can also reply by typing. Only the latest unanswered question accepts a choice. |
delegate_task | Hands a research task to a read-only subagent with its own context; only its report comes back to the conversation. See section 4. |
Almost no website lets a page read it from the browser (CORS), so web tools go through an intermediary. With the local ZeroChat server connected, all of them use the local server. Without it, search_web and fetch_web_page use Jina Reader (r.jina.ai), a public service that downloads the page for you: URLs and queries go through Jina, which allows about 20 requests a minute without an account and sometimes blocks some domains temporarily. download_doc and download_image download directly with no intermediary, so without the local server they only work with sites that allow CORS. Office documents and PDFs are read locally in the browser. Local network, loopback and cloud metadata URLs are blocked, also when a redirect leads to them. Do not send private URLs or URLs with credentials to these tools.
File, terminal and browser automation tools need the local server. Their calls include authorization and a temporary single-use signature; this does not protect against a compromised interface with session access.
execute_javascript runs code using an iframe with an isolated origin, network restrictions and a Web Worker. Time and output limits apply; the aim is to perform calculations without giving code direct access to chat or disk. It is not a security boundary: it is meant for model calculations under your supervision, not for running untrusted code.
Enable it when you need this processing and can review what it does. Isolation does not guarantee correct results or eliminate every resource risk. System commands use separate tools on the local server.
With delegate_task the agent hands a task to a subagent: another run of the same model, in the same tab, that starts with an empty context. If there is a profile named “Subagent” (or “Subagente”), the subagent uses its connection and model instead of the main agent's, without asking; the card then shows that model next to the title. The subagent does not see the conversation, only the task the agent writes for it, and works until it writes a report. That report is the only thing that comes back to the conversation; the pages, files and chunks it read take up none of the main agent's context.
It pays off in investigations that need many reads to reach a short conclusion: exploring a project, comparing several web pages or going through the knowledge base. It does not pay off for lookups of one or two calls, and overall it usually uses more tokens than doing the work directly, because the subagent has to gather again the context it needs.
The subagent is read-only. It only gets the enabled tools that read: web search, reading pages and documents, execute_javascript, the knowledge base tools and, from the local server, read_file, list_directory, search_files and get_diagnostics. It can never write or edit files, run commands, use external MCP servers, ask you with ask_user or start other subagents; if it asks for a tool it does not have, the call is rejected without running it. Reads outside the project directory ask for your authorization as usual, inside its card.
Its card shows the task, the current step, the tools it uses and the final report. The stop button stops it too. When you reopen the conversation the task and the report are kept, but not its intermediate steps. Several delegations in the same response run one after another. You can turn it off in Settings → Agent.
Consecutive calls are grouped in one “Tool calls” line. While running it shows the active calls; when finished it is collapsed and can be expanded to inspect the cards with status, arguments and results. Saved cards are restored when opening history.
Review paths, commands and web destinations before authorizing. A successful execution status means the call completed, not that the user's task was solved correctly. Errors or cancellation can leave partial effects: check affected files or services before repeating.