What are Tools?

Tools are the mechanism by which Contenox gives a model access to real-world actions. Instead of generating text, the model calls a tools to read files, run commands, query APIs, or fire HTTP requests — and gets the result back as context for its next reply.

How it works

Chain starts
  └─ FetchTools: each listed tools returns its tool schemas
       └─ Schemas are sent to the model alongside the prompt
            └─ Model returns a tool call
                 └─ execute_tool_calls runs the tools
                      └─ Result appended to history → model continues

An agent declaration names its tools on one line — tools: Read, Glob, Grep — and omitting the line inherits every tool. That is where most tool scoping happens.

In the chain behind it, and in a chain you author yourself, the same allowlist is execute_config.tools, per task:

"execute_config": {
  "model": "qwen3:8b",
  "provider": "ollama",
  "tools": ["local_fs", "nws", "local_shell"]
}

Pattern support:

Unknown names in an exact list are silently ignored — if local_shell is disabled the chain still runs.

"*" admits everything this machine has connected: the toolsets contenox hosts, the native- in-process ones, every MCP server and OpenAPI service you registered, and the decl- sources an agent declaration brought with it. Those prefixes are namespaces — they stop a declared source from colliding with an in-process toolset — and never a hidden exclusion. To leave one out, say so: "!native-git" removes it, and an exclusion wins over "*" wherever the two appear in the list.

Use {{tools}} in your system_instruction to inject the live tool manifest. It respects the task’s tools allowlist — the model only sees what the task permits:

"system_instruction": "You are a helpful assistant. Available tools: {{tools}}."

Nothing is added to a system_instruction that it does not declare.

Template variables

System instructions and prompt_template fields support the following macros:

Tools types

Contenox ships with built-in local tools and supports unlimited remote tools:

Choosing the right tools

• local_fs — best for reading, writing, and editing a file whose path you already know. The read-before-write contract and sandbox guard against confabulated edits.
• local_shell — for everything else on the machine: listing directories, searching/grepping, globbing, and running build or test commands. Use only in trusted, sandboxed environments.
• MCP servers — attach any MCP-compatible server for retrieval, memory, or a SaaS integration; see Model Context Protocol.
• Remote tools — turn any OpenAPI service into an agent tool; ideal for internal APIs and team-shared tools without an MCP server.

Further reading

• Remote Tools — register external APIs as agent tools
• Local Tools — built-in in-process tools reference