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

In your chain JSON, specify which tools the task can use via the execute_config.tools allowlist:

"execute_config": {
  "model": "qwen2.5:7b",
  "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.

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

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

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 code analysis, file editing, report generation. Prefer over local_shell for file ops; the read-before-write contract and sandbox guard against confabulated edits.
• git — prefer over local_shell for repository operations (status, diff, log, commit, branch, restore); each operation is a separate tool the HITL policy can gate individually, rather than one decision for all of git.
• gointel — exact questions about Go code (type, signature, references, implementers). Prefer over grep/local_shell — it answers from a type checker, not text search.
• jq — pull one field or projection out of a JSON/YAML file instead of reading the whole thing.
• workspace — semantic, meaning-based search over an already-built contenox index; approximately right, not exact — use gointel when you need an exact Go-symbol answer.
• goja — imperative logic or multi-tool composition over data you already have, via host.tool(...); reach for jq instead for simple declarative shape-work.
• webtools — when the model needs to call HTTP. Use web_get / web_head for retrieval; mutating verbs trigger HITL approval by default.
• local_shell — full power; use only in trusted, sandboxed environments. Reach for it for build / test scripts, not for cat / grep / sed / git against project files — those have dedicated tools.
• print / echo — inject messages or inspect task output during development
• Remote tools — turn any OpenAPI service into an agent tool; ideal for internal APIs, SaaS integrations, and team-shared tools

Further reading

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