Server-Side Tool Use
Catalog → Hierarchies → Bindings: the trio that adds agentic tool use to gateway requests.
Orchestration gives a gateway chat request MCP tools via Trellis: when the model asks for a tool call, the gateway itself — not your IDE — executes it and feeds the result back to the model to finish the answer. It is built from three separate steps: registering an MCP server in the Catalog, composing those servers (with an optional access order) into a Hierarchy, and finally binding that Hierarchy to a user/group/scope with a Binding.
#Three pages
The registry of available MCP servers — over stdio, http, sse or docker transport. Servers you generated yourself and external servers sit in the same list, tagged by source.
Composes catalog servers into a single "gated" MCP endpoint: nested servers unlock only after their parents have been used.
Binds a Hierarchy to a target (user, model group, workspace, node, model, mapping, or global) — that target's requests now run through the server-side agent loop.
#When a binding actually activates the loop
Having an enabled binding is not enough on its own. Right before the request goes upstream, three conditions must all hold: the target model must support tool calls, the client must NOT have sent its own `tools` field (a client managing its own tool universe — e.g. an IDE agent — is never interfered with), and the request body must carry a non-empty `messages` list. If any of these fails, the binding is silently inactive for that request — it proceeds down the normal, non-agentic path.