Skip to main content

​
Tool Node

Purpose: Execute operations, call APIs, run code, and integrate with external services Tool nodes enable LLMs to take actions in the real world.
Tool node visual representation
Tool node visual representation

​
Configuration

The Tool Node configuration varies based on the selected Tool Type. All tool types share a common field:
Description: A user-defined name to identify this tool node in your workflow.Type: StringRequired: YesExample:
"Send Email Tool"
"GitHub API Tool"
"Search Database"
Description: Defines what kind of tool this node represents.Type: SelectRequired: YesOptions:
  • Operations - Platform integrations (APIs, databases, services)
  • MCP - Model Context Protocol servers
  • Custom - Custom code execution
  • Workflow - Call other workflows as tools
What Changes: Different tool types show different configuration fields. See sections below for details.

​
Operations Tools Configuration

Use operations tools to integrate with external platforms and services.
Description: Select which platform this tool connects to.Type: Select (Dynamic)Required: YesVisibility: Only when Tool Type = “Operations”Options: Shows platforms where you have active integrations:
  • Splox (internal operations)
  • Sandbox (E2B sandbox operations)
  • Remote Server (SSH operations)
  • Local Machine (desktop automation)
  • Any other connected platforms
Setup:
  1. Go to Integrations page
  2. Connect the platform you need
  3. It appears in this dropdown
Only platforms with active integrations are shown. The list is filtered to your connected platforms.
Description: Select which specific integration to use for this tool.Type: Select (Dynamic)Required: YesVisibility: Only after Platform is selectedOptions: Shows your integrations for the selected platformExample:
  • If Platform = “Slack” → Shows your Slack workspaces
  • If Platform = “Sandbox” → Shows your sandbox templates
Description: Select the specific operation to execute.Type: Select or Multi-Select (Dynamic)Required: YesVisibility: Only after Integration is selectedDisplay:
  • Single Select: When tool is NOT exposed to LLM (manual execution)
  • Multi Select: When tool IS exposed to LLM (LLM chooses from list)
Options: Dynamically loaded operations for the selected platform, grouped by categoryExample Operations:
  • Splox Platform: API Request, KV Store, Vector Search, DateTime operations
  • Sandbox: Execute Command, Read File, Write File, Upload to S3
  • Remote Server: SSH commands, file operations, Morph editing
Operations are grouped by category for easier navigation. Each operation has its own input schema.
Description: Configure the input parameters for the selected operation.Type: Input Schema (Dynamic)Required: NoVisibility: Only when tool is NOT exposed to LLMHow It Works:
  • Schema changes based on selected operation
  • Each operation has different required/optional parameters
  • Supports template variables: {{variable_name}}
Example (API Request):
{
  "url": "https://api.example.com/users/{{user_id}}",
  "method": "GET",
  "headers": {
    "Authorization": "Bearer {{api_token}}"
  }
}
Description: Select which sandbox template to use for operations.Type: Select (Dynamic)Required: ConditionalVisibility: Only when Platform = “Sandbox”Options: Your user-defined sandbox templatesSetup: Create sandbox templates in Settings to reuse configurations across workflows.
Description: Specify which sandbox instance to use for commands.Type: Editor (supports template variables)Required: ConditionalVisibility: Only when Platform = “Sandbox”How It Works:
  • Use template variables to reference sandbox IDs from previous nodes
  • Enables persistent sandbox usage across multiple tool calls
Example:
{{sandbox_instance.id}}

​
MCP Tools Configuration

Use MCP (Model Context Protocol) tools for standardized server-side tool execution.
Description: How the MCP server is launched and accessed.Type: SelectRequired: YesVisibility: Only when Tool Type = “MCP”Options:
  • Remote - Connect to an existing MCP server via URL
  • Sandbox - Launch MCP server in E2B sandbox
When to Use:
  • Remote: Server is already running (self-hosted or cloud)
  • Sandbox: Need isolated, temporary MCP server instance
Description: Communication protocol for the MCP server.Type: SelectRequired: YesVisibility: Only when Launch Method = “Remote”Options:
  • HTTP - RESTful API communication
  • SSE - Server-Sent Events (streaming)
  • stdio - Standard input/output (for local processes)
Recommendation:
  • Use HTTP for most remote servers
  • Use SSE for real-time streaming responses
Description: The URL endpoint of your MCP server.Type: StringRequired: YesVisibility: Only when Launch Method = “Remote”Example:
https://mcp-server.example.com/api
http://localhost:3000/mcp
Description: Bearer token for authenticating with the MCP server.Type: StringRequired: NoVisibility: Only when Launch Method = “Remote”Format:
your-bearer-token-here
Tokens are stored securely but visible in workflow configuration. Use environment-specific tokens for security.
Description: Sandbox template for launching MCP server.Type: Select (Dynamic)Required: YesVisibility: Only when Launch Method = “Sandbox”How It Works: MCP server runs inside the sandbox, isolated from other processes.
Description: Sandbox instance ID to use.Type: EditorRequired: YesVisibility: Only when Launch Method = “Sandbox”Example:
{{sandbox_instance.id}}
Description: Restrict which MCP tools are available to the LLM.Type: Multi-Select (Dynamic)Required: NoVisibility: Only when Launch Method = “Remote” or “Sandbox”Default Behavior:
  • Empty = All tools allowed
  • Selected = Only specified tools allowed
Use Cases:
  • Limit LLM access to specific operations
  • Prevent dangerous tool calls
  • Optimize for specific tasks
Description: Where to store MCP tool execution outputs.Type: SelectRequired: NoVisibility: Only when Tool Type = “MCP”Options:
  • S3 - Store in S3 bucket (for large outputs, files)
  • Memory - Store in workflow memory (for small data)
  • Sandbox - Keep in sandbox filesystem (for subsequent commands)
When to Use:
  • S3: Large files, images, documents
  • Memory: Small JSON data, text results
  • Sandbox: Temporary files for multi-step processes

​
Workflow Tools Configuration

Call other workflows as tools, enabling modular and reusable workflow components.
Description: Choose which workflow to execute as a tool.Type: Select (Dynamic)Required: YesVisibility: Only when Tool Type = “Workflow”Options: Your draft workflows (only draft versions can be called)Use Cases:
  • Modular workflows (reusable components)
  • Multi-agent systems (each workflow = one agent)
  • Parallel processing (call multiple workflows)
Description: Choose which start node of the workflow to trigger.Type: Select (Dynamic)Required: YesVisibility: Only after Workflow is selectedOptions: Start nodes from the selected workflow (with trigger_type = “internal”)Why Multiple Start Nodes: One workflow can have multiple entry points for different use cases.
Description: Name of the tool as seen by the LLM.Type: StringRequired: ConditionalVisibility: Only when tool is exposed to LLMExample:
search_knowledge_base
create_support_ticket
analyze_sentiment
Use descriptive, snake_case names that clearly indicate the tool’s purpose.
Description: Describe what the tool does for the LLM to understand when to use it.Type: EditorRequired: ConditionalVisibility: Only when tool is exposed to LLMBest Practices:
  • Be specific about inputs and outputs
  • Mention when to use this tool
  • Include examples if helpful
Example:
Search the company knowledge base for relevant documentation.

Input: search_query (string) - The search term or question
Output: list of relevant documents with titles and summaries

Use this when the user asks questions about company policies,
procedures, or product documentation.
Description: The message/data to send to the workflow.Type: Editor (supports template variables)Required: ConditionalVisibility: Only when tool is NOT exposed to LLMExample:
{
  "user_id": "{{user.id}}",
  "action": "process_order",
  "order_data": {{order_details}}
}
Description: Define the schema of what this tool returns to the LLM.Type: Schema BuilderRequired: ConditionalVisibility: Only when tool is exposed to LLMExample:
{
  "type": "object",
  "properties": {
    "results": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "title": { "type": "string" },
          "content": { "type": "string" },
          "relevance_score": { "type": "number" }
        }
      }
    },
    "total_found": { "type": "integer" }
  }
}

​
Custom Tools Configuration

Execute custom logic with user-defined code.
Description: Name of the custom tool.Type: StringRequired: ConditionalVisibility: Only when Tool Type = “Custom”Example:
calculate_discount
validate_input
transform_data
Description: Describe what the custom tool does.Type: EditorRequired: YesVisibility: Only when Tool Type = “Custom”
Description: The custom code or logic to execute.Type: EditorRequired: ConditionalVisibility: Only when tool is NOT exposed to LLM
Description: Schema of the tool’s output.Type: Schema BuilderRequired: ConditionalVisibility: Only when tool is exposed to LLM

​
Scheduling Configuration

Schedule when workflows execute (only for non-LLM workflow tools).
Description: How to schedule the workflow execution.Type: SelectRequired: NoVisibility: Only when Tool Type = “Workflow” and NOT exposed to LLMOptions:
  • Cron - Recurring schedule using cron expressions
  • Once At - Execute once at a specific time
  • None - No automatic scheduling
Description: Who controls the scheduling.Type: SelectRequired: NoVisibility: Only when Tool Type = “Workflow” and IS exposed to LLMOptions:
  • Agent - LLM decides when to schedule
  • None - No scheduling
Description: Cron expression defining the recurring schedule.Type: EditorRequired: ConditionalVisibility: Only when Schedule Type = “Cron”Format:
* * * * *
│ │ │ │ │
│ │ │ │ └─ Day of week (0-7)
│ │ │ └─── Month (1-12)
│ │ └───── Day of month (1-31)
│ └─────── Hour (0-23)
└───────── Minute (0-59)
Examples:
0 9 * * *        # Every day at 9 AM
*/15 * * * *     # Every 15 minutes
0 0 * * 1        # Every Monday at midnight
Description: Number of seconds from now to execute.Type: EditorRequired: NoVisibility: Only when Schedule Type = “Once At”Example:
3600    # Execute in 1 hour
86400   # Execute in 24 hours
Description: Timezone for scheduled execution.Type: StringRequired: NoVisibility: Only when Schedule Type = “Once At”Example:
America/New_York
Europe/London
Asia/Tokyo
UTC

​
Node Handles

Left Side - Tool Call InputReceives tool call requests from LLM nodes or other workflow nodes.Accepts:
  • Tool call parameters from LLM
  • Direct invocation data
  • Workflow context variables

​
Tool Types

Execute platform-specific operations (API calls, database queries, etc.)Features:
  • OAuth integration support
  • Dynamic credential management
  • Input/output schema validation
  • Rate limiting and retry logic
Example: Send email, create ticket, query database
Execute custom JavaScript/Python code with user-defined logicFeatures:
  • Full language support
  • Access to workflow context
  • Timeout protection
  • Error handling and logging
Example: Data transformation, custom validation, calculations
Model Context Protocol servers for standardized tool interfacesFeatures:
  • Server-side tool execution
  • Stateful connections
  • Resource access patterns
  • Prompt injection protection
Example: File system access, terminal execution, API wrappers
Trigger other workflows as sub-tasksFeatures:
  • Specify target workflow and start node
  • Pass input data programmatically
  • Wait for completion or run async
  • Access sub-workflow outputs
Example: Multi-agent systems, modular workflows, parallel processing
Execute code in isolated E2B sandboxesFeatures:
  • User-defined sandbox templates
  • Persistent sandbox instances
  • File system access
  • Package installation
  • Automatic inactivity pausing
Example: Code execution, data science pipelines, test environments

​
LLM Tool Integration

When connected to an LLM node, tools become automatically available to the AI model. The LLM decides which tools to use and when.
In subflows with loops (agent patterns), LLMs can call multiple tools sequentially. Outside subflows, tool execution is one-directional without feedback.

​
What’s Next?

LLM Node

Learn how LLMs call tools automatically

Subflow Node

Create agent loops for multi-tool workflows

End & Stop Nodes

Control tool execution flow in subflows

Integrations

Explore available operations and integrations