Tool Discovery & Tool Hub

Applies to: ChengOS v0.1.0+ ｜ Last verified: 2026-08-12 ｜ Source: crates/cheng-nodes/src/nodes/builtin/tools/tool_hub, tools/runtime, tools/mcp_hub.rs, tools/skills_hub

Connecting tool nodes directly to an agent works until it does not. Every tool adds a function definition to the model's context, so a dozen tools means a dozen schemas in every single request — expensive, and increasingly likely to confuse the model about which tool to reach for.

Tool Hub (tools/tool_hub) solves that by putting one stable function in front of many tools.

What Tool Hub is, and is not

Tool Hub is not a second tool runtime. It is the workflow-facing discovery, configuration, and command-routing layer over the existing ToolRuntime. Execution still goes through the shared runtime's policy, constraint, and approval pipeline — Tool Hub decides what may run and routes the call; the runtime does the running.

The model sees one wrapper function with two actions:

Every command is validated against a trusted allowlist before dispatch.

The security property that matters

Configuration is static and the LLM can never write it. The workflow author decides the tool scope in the property panel; the model can only select from within it. An LLM-supplied name is a lookup key, never authority.

That single rule is what makes it safe to hand a model one generic execute function instead of individually wired tools. Without it, a general-purpose executor would be an arbitrary-code gadget.

Two modes

user mode

The workflow author enables tools in the property panel via enabled_tools. list_tools returns exactly those rows, and execute accepts only commands inside that configured scope.

Use this when you are designing the agent's capabilities yourself.

skill mode

The selected Skill's canonical tool_hub.tools declaration defines what may execute. Two details are load-bearing:

• list_tools is unavailable. The model learns the tool surface from Skills Hub describe instead. There is no second, possibly-stale discovery path.
• The Skill's current canonical spec is re-resolved on every execute. A skill name the model supplies is only a key for that lookup, so an edited Skill takes effect immediately and a model cannot pin an older, more permissive version.

skill_name may be omitted when exactly one trusted active-Skill binding was established by a prior Skills Hub describe in the same loop. Zero bindings or several distinct ones are ambiguous and rejected rather than guessed — an agent that has described two skills must say which one it means.

The other hubs

Tool Hub is one of four aggregators, each fronting a different source:

They compose: an agent can have Tool Hub, MCP Hub, and Skills Hub connected at once, and their definitions are merged into one tool surface.

MCP servers

tools/mcp_hub connects external MCP servers over stdio, SSE, or HTTP. Tools, prompts, and resources the server exposes are discovered automatically — adding a server adds capabilities without any node authoring.

Configure servers visually in the admin console, or inject rules in bulk through the environment. MCP servers needing authentication take credentials from the vault like any other tool, so keys stay out of the model's context.

Skills

A Skill is a packaged capability: a manifest, instructions, and optional code. Installed Skills are discoverable through tools/skills_hub, where describe returns a Skill's canonical tool surface — which is also what establishes the active-Skill binding Tool Hub's skill mode relies on.

Skills are imported through a pipeline that parses the source, validates it (tools/validate_skill_spec), takes an approval, and writes it transactionally (tools/write_skill_package); a file watcher hot-loads the result. Sources can be natural language, a URL, a Git repository, or a standard SKILL.md.

Choosing an approach

Next steps

• ReAct agent guide — the loop that consumes these tools.
• Model configuration — native function calling support by provider.