Tool Bindings

A tool binding connects a registered tool endpoint to a specific LLM-response field on a pipeline node. Bindings tell the LLM which tools it may call while it generates that field's value.

Where bindings live

Bindings are keyed by the tuple (pipeline, node, LLM-response field, endpoint).

• Per pipeline, per node, per field. A binding belongs to one LLM field. It isn't shared across fields or pipelines — to use the same tools elsewhere, create another binding there.
• LLM fields only. Bindings are only valid on fields whose input mode is LLM Response. The API rejects bindings on any other field type.
• Multiple endpoints per field. You can bind more than one endpoint to the same LLM field; the LLM sees every tool from every bound endpoint.

Create a tool binding

1. Open the Pipeline Builder and select a node.
2. Click an LLM-response field.
3. In the LLM configuration panel, open Tool Calling. By default the field inherits the node-level tool-calling settings (Use node settings). To give this field its own tool set, switch to Custom, or configure the node-level section if you want the binding to apply to every LLM field on the node.
4. Pick an endpoint from the dropdown. Only active endpoints are selectable. To bind more endpoints to the same field, click Add Endpoint.
5. For each endpoint, open Available Tools and choose:
   • All tools (default) — every tool on the endpoint is available. Tools discovered on that endpoint later (after a refresh) automatically flow through to this binding — no edit or re-save of the pipeline is required, and in-flight and new tasks will see the updated tool list on their next run.
   • Specific tools — uncheck tools you don't want. The LLM only sees the ones that remain checked, and new tools added to the endpoint later are not auto-included. This is the only place you can restrict the tool set for an endpoint — there is no per-tool enable/disable on the endpoint detail page.
6. Max Rounds — how many rounds of tool calls the LLM may take for this field. Default 5. You can set anywhere from 1 to 20 — this is the platform ceiling. Each round can include multiple tool calls in parallel.
7. Save the node.

What the LLM sees

At run time, Pipelines loads every tool from every bound endpoint (filtered by the binding's Specific tools list, if set), converts each to function-calling format (name, description, JSON-Schema parameters), and sends them to the LLM together with the prompt.

Name collisions. If two endpoints expose a tool with the same name, both are auto-prefixed with a sanitized endpoint name — for example myserver__search and other__search — so the LLM can distinguish them. Watch for this when prompts reference tool names directly.

The tool-calling loop

1. The LLM generates a response, possibly including one or more tool calls.
2. Pipelines validates each call against the tool's JSON Schema, routes it to the correct endpoint (MCP / HTTP / Platform), and awaits the result.
   • Per-call timeout: 30 seconds.
   • Per-call result size returned to the LLM: 100 KB (larger results are truncated).
3. Results are appended as tool messages and the LLM is invoked again.
4. The loop ends when the LLM produces a final answer without tool calls, or the binding's Max Tool Rounds is reached — whichever comes first.

Tool calls run on a worker pool dedicated to tool execution, separate from LLM generation, so long-running tool loops don't block other generations.

Who can see what

Every tool call made during a run is recorded against the LLM response log, capturing tool name, arguments, result, latency, and any error.

• Admins (org/project admins) can see every tool call and its payload in the Data Explorer view for a run.
• Taskers and reviewers do not see tool history by default. They see the final LLM output only, with no indication tools ran. To expose tool history to them, enable Tool History on that field in the Pipeline Builder.

Because tool endpoints, credentials, and bindings are admin-managed, pipeline contributors never see which tools are linked to a field or how they're configured — just the outputs admins choose to show.

Common scenarios

• Mix a web search MCP, a code runner, and an internal DB. Register three endpoints, then add three bindings to the same LLM field. The LLM will pick whichever it needs per round.
• Restrict a noisy endpoint. Register the endpoint with all tools, but in the binding pick only the two or three tools you trust for this field. Other pipelines can bind different subsets of the same endpoint.
• Roll out a new tool cautiously. Keep bindings set to a specific tool list so newly discovered tools don't automatically appear. With All tools selected, a refresh that adds new tools on the endpoint will expose them to every existing binding on the next task run — even for pipelines that were authored and saved before the new tools existed. Flip a binding to All tools only when you're ready to accept that behavior.

Removing a binding

1. Open the node and field in the Pipeline Builder.
2. In the Tool Bindings list, click Remove next to the binding.
3. Save the node.

Removing a binding does not delete history — past tool calls remain visible in the LLM response log.

Changing the underlying endpoint

• Restricting the tool set. There's no per-tool toggle on the endpoint. Narrow the tool set by editing each binding and switching from All tools to Specific tools.
• A tool disappears (refresh or upstream change). Bindings referencing the tool by name in their Specific tools list silently drop it — no error is raised. Re-open bindings after major refreshes to confirm the selection still reflects what you want.
• Deleting or deactivating an endpoint. Blocked when any binding still references it. Remove the bindings first, then delete the endpoint.
• Rotating credentials on the endpoint. Bindings need no changes — they follow the endpoint's updated auth automatically.

Debugging checklist

1. LLM didn't call any tool. Confirm the binding is saved and the endpoint is Active. Check the field's prompt actually signals when to use tools.
2. LLM keeps calling the same tool. Increase Max Tool Rounds if multi-step tool flows are expected, or narrow the binding's tool selection.
3. Tool call errored. Open the endpoint's detail page and click Test Connection for the latest server-side error.
4. Results look clipped mid-sentence. The 100 KB per-call cap likely fired — add filters or paging in the tool / API.
5. Two tools with the same name stopped matching your prompt. Check the LLM response log in Data Explorer for the resolved name — endpoint-name prefixes kick in on collisions.