Tool availability
DataMind Oda is assembled from parts, and its tools come from those parts: a chat can use only the tools its installation provides. Some tool families are opt-in, and one tool needs a service that not every installation has. This page, for the people who build, ship or debug Oda, covers which tools can be missing, what a missing tool looks like, and the rules that keep tool sets predictable.
A tool that is not mounted never appears
- Tools are contributed by the parts an installation loads, so the tool set is a property of the installation. When the part that provides a tool is not loaded, the tool never appears: a chat cannot call it, and the model is never sent its description.
- A call that names a tool the chat cannot use fails as an ordinary error (
UNKNOWN_TOOL); it does not run, and the task can continue. Tool catalog and session events describes the codes a step's record can carry.
- Absence at the installation level is only one reason a tool can be missing. A restriction can narrow the tools one agent inherits, and code-call mode offers only the code tool. Those causes are per agent, not per installation, and are on Tools and how they are offered.
Which tool families are opt-in
Three families are opt-in: they are part of the set only where an installation includes them.
- Terminal tools. The six tools that work in a terminal session (open, send, read, signal, close and list) are opt-in. An installation that does not carry them shows no terminal tool at all. Terminal tools is the reference for the six.
- Team tools. The team tools arrive as one optional feature bundle, kept switched off in the shipped set. The whole set moves together: switching the bundle on brings the tools in, and switching it off takes them back. Subagents and Agent Teams covers the bundle and how it is turned on.
- Chat-reading tools. Five read-only tools read chats and their records, and they are opt-in: only a deployment that enables the set carries them. Where the set is on, every answer is authorised from the chat that asked for it, and the set never exposes its internal paging cursors. How Oda stores chats covers the reading surfaces.
The image read tool needs image storage
- An installation that provides no image storage does not register the image read tool at all: there is no image read tool to call, and a chat cannot read an image there.
- Where the tool is registered, its shape is route-independent: the same tool for every model. The outcome is decided per call: a read runs only when the exact model answering the chat declares image input. Otherwise the read is refused, the message names the model and asks for one that accepts images, and switching the chat to an image-capable model fixes it.
- An installation can also refuse an image format outright, even when the tool is registered and the model accepts images. Read, write and edit files lists the messages an image read can meet.
Tools that stay and refuse at call time
Not every missing capability shows up as a missing tool. Some tools are kept in place and report at call time instead.
- Web search and page reading. The tools stay visible when their provider is missing or misconfigured, and the failure appears when a search or a read runs, not in the tool list. Which provider answers sits behind the tools' surface, so the model-visible schemas stay stable across backend swaps (Web search providers).
- Code navigation. A query with no registered provider returns the structured
LSP_UNAVAILABLE error rather than changing the schema. The tool keeps its shape, and the refusal is a code a caller can tell apart (Language servers).
When the offered set is decided
- Some support is settled when a tool registers rather than at call time: where background sending is off, the send tool registers without its background field, and the field is simply not offered. A call that asks for it anyway is refused (Terminal tools).
- So availability reaches a chat in one of two shapes: a tool that is never offered, or a call that is refused with a reason. A tool that is present is not quietly reshaped while it runs.
There is no compact tool
- Shortening a long chat is never a tool the model calls: the set has no model-facing compact tool, and nothing offers one.
- Compaction is arranged by the app itself, on its own or from your
/compact command. Chat compaction covers when it runs and what the summary keeps.
Questions, answered
Why is a tool present in one installation and missing in another?
Tool sets are a property of the installation: a tool whose part is not loaded is not offered at all, so two installations can differ. The opt-in families are the terminal tools, the team tools and the chat-reading tools; the image read tool needs image storage. A call that names a tool the chat cannot use fails as an ordinary error, and the task can continue.
Why do some installations have no terminal tools?
The terminal tools are opt-in: they are part of the set only where the installation includes them. An installation without them shows no terminal tool at all. Terminal tools is the reference for the six.
Does the image read tool change with the model I use?
No. Its shape is route-independent: the same tool for every model. The outcome is decided per call: a read runs only when the exact model answering the chat declares image input, and otherwise it is refused with a message that asks for an image-capable model. Switching the chat to one fixes it.
Why does a missing capability sometimes appear as an error rather than a missing tool?
Two designs, both deliberate. A tool that is not mounted never appears at all. Tools whose provider may be missing are kept in place and report at call time: web search and page reading fail with the call, and a code-navigation query with no provider returns the structured LSP_UNAVAILABLE error, instead of a tool that quietly changes shape.
Why is there no compact tool?
Because compaction is not offered to the model: no model-facing compact tool exists, and the model cannot shorten a chat by calling one. The app compacts a chat on its own, or when you send /compact (Chat compaction).
Why is a field missing from a tool in some installations?
Some support is settled when a tool registers, not at call time. For example, where background sending is off, the send tool registers without its background field, and a call that asks for it anyway is refused (Terminal tools).
What does LSP_UNAVAILABLE mean?
It is the structured error a code-navigation query meets when no provider is registered to serve it. The tool is not removed or reshaped: the refusal comes as this code so a caller can tell it apart. Language servers covers how servers are chosen, installed and limited.
Do web tools change when the search provider changes?
No. Web search and page reading keep provider selection behind their surfaces, so the model-visible schemas stay stable across backend swaps. The tools also stay visible when their provider is missing; the failure appears when a search or a read runs (Web search providers).