Tools Overview

Pipelines lets LLM-generated fields call external services while they generate. The LLM receives a list of available tools, decides when to call them, and the platform executes each call and feeds the result back into the prompt. This page explains the concepts. For hands-on steps, see the per-protocol pages linked below.

Core concepts

Pipelines organizes tool support into three layers:

1. Tool endpoints — registered sources of tools. An endpoint can be an MCP server, an HTTP / OpenAPI API, or a built-in Platform endpoint (see below). Endpoints are org-scoped and managed by admins.
2. Tools — individual capabilities discovered from an endpoint (for example, search_web, fetch_url, query_db). They are listed on the endpoint's detail page for reference. You don't toggle tools on or off at the endpoint level — the full discovered set is always available. Which tools the LLM can actually call is decided per binding, where you pick either "all tools" or a specific subset for that field.
3. Tool bindings — the link between one or more endpoints and a specific LLM-response field on a pipeline node. Bindings decide which tools a given LLM call can invoke. See Tool Bindings.

Where to find tools in the app

• Sidebar → MCP Servers. This page lists every tool endpoint in your org (MCP, HTTP, and Platform) plus a gallery of pre-configured providers you can connect with one click.
• Pipeline Builder → any LLM field → Tool Bindings. Where you attach tools to a specific LLM-generated field.

Endpoint types

Platform-supported tools

Every org gets a built-in endpoint named Platform Tools (URL platform://run_code). It's created automatically and shows up alongside your MCP and HTTP endpoints on the MCP Servers page.

Today it exposes a single tool:

• run_code — executes Python code inside a sandboxed interpreter, powered by E2B. The LLM can use it to crunch numbers, parse data, or run short analyses during generation. Results from earlier calls in the same round are available in later calls within the same sandbox session.

We're planning to expand the set of built-in Platform tools soon — expect more first-party capabilities (file handling, search, structured extraction, and more) to appear under the same Platform Tools endpoint over the coming releases.

Like any other endpoint, the Platform endpoint needs an explicit binding on an LLM field before the LLM can invoke its tools. If you don't want pipelines to use it, toggle the endpoint Active switch off on the MCP Servers page, or simply never bind it.

How tool-calling works at run time

When an LLM field with bindings is evaluated:

1. The LLM receives the prompt plus the JSON Schemas of all tools it has access to (from every bound endpoint).
2. The LLM may emit one or more tool calls. The platform validates the arguments against the schema and routes each call to the correct endpoint: MCP servers via the MCP client, HTTP endpoints via a direct HTTP request, and Platform tools internally.
3. Tool results are appended to the conversation and the LLM is invoked again.
4. The loop continues until the LLM produces a final answer without tool calls, or the binding's round limit is reached. This limit, Max Tool Rounds, is configurable on each binding — the default is 5 and you can set it anywhere from 1 up to the platform ceiling of 20.

Tool execution runs on a dedicated worker pool, separate from LLM generation, so a slow tool call doesn't block other generations.

Visibility to taskers and reviewers

Tool calls made during a run are always recorded for admin visibility:

• Data Explorer (admin view) always shows every tool call for a run — tool name, arguments, result, latency, and any errors.
• Tasker and reviewer views do not show tool history by default. If you want taskers or reviewers to see what tools were called for a given field, enable Tool History on that field in the Pipeline Builder. With it off, taskers and reviewers see the final LLM output only, with no indication that tools ran.

Large tool results are truncated before being logged to keep runs readable (see Limits).

Limits and constraints

Security

• Endpoint credentials are encrypted at rest.
• When you reopen a saved endpoint to edit it, secret fields (API keys, bearer tokens) show a redacted preview of the stored value as a placeholder — the real secret is never sent back to the browser. To rotate a secret, type the new value over the placeholder and save. To keep the existing one, leave the field blank.

Managing endpoints

On the MCP Servers page you can:

• Click Add Tool Endpoint to register a new MCP or HTTP endpoint.
• Click a provider tile in the gallery for a one-click connect flow (see the provider list in MCP Server Integration).
• On each endpoint row: toggle Active, Edit, Test connection, Refresh tools, or Delete.

Permissions

Further reading

• MCP Server Integration
• HTTP / OpenAPI Tool Integration
• OAuth for Tools
• Tool Bindings