Studio block reference

This page explains the purpose, configuration, and outputs of the nine standard blocks. Availability depends on your organization. The palette may also offer other blocks with their own fields and outputs. See the workflow model for basic information, configuration, and links.

Simple message

Returns fixed text or text enriched with variables. Use it for a response without an LLM, a confirmation, a fallback, or temporary diagnostics.

Field	Required	Description
Message	Yes	Returned text; accepts variables and helpers

Output: message, for example {{simpleMessage-1.message}}.

Hello {{userData.givenName}}, your request is: {{userMessage}}

To inspect a value during development:

{{codeblock documents.body}}

Best practices: keep messages short, connect technical failures to a user-friendly message, and remove debug blocks before publication.

Common errors: an empty message, a misspelled variable, an unconnected fallback, or sensitive data exposed by a debug helper.

HTTP request

Calls an internal or external API to query a business service, run a specialized search, or send data.

Current RAG architecture

For RAG document search, use MCP Retriever with MCP - List tools and MCP - Call tools. The HTTP block remains useful for business APIs that do not provide an MCP interface.

HTTP request exchanges

100 %

Dashed boxes represent data, services, or results.

Drag to move. Use + / − to zoom, arrow keys to move, and Home to reset.

Field	Required	Default	Description
URL	Yes	-	API address
HTTP method	Yes	-	GET, POST, PUT, PATCH, or DELETE
HTTP headers	No	{}	JSON object containing headers
Timeout	Yes	30	Timeout in seconds
Stop when request fails	No	true	Triggers the failure branch
Accepted HTTP codes	Yes	[200]	JSON array of successful codes
Request body type	No	raw	raw, formData, or x-www-form-urlencoded
Request body	No	-	Data sent to the API
Response format	No	JSON	JSON, Text, or Binary

Headers:

{
  "Authorization": "Bearer {{customParams.mcpAccessToken}}",
  "Content-Type": "application/json"
}

Accepted codes:

[200, 201, 204]

Search body:

{
  "query": "{{userMessage}}",
  "limit": 5
}

Outputs: body and metadata, for example {{http-1.body}}.

Best practices: test the API outside Studio, use a business alias such as customer-api, add the correct Content-Type, and connect After failure.

Common errors: invalid URL, malformed headers object or codes array, incorrect reference, wrong response format, or a timeout that is too short.

Data Sources

Selects the document or tabular sources to use and prepares their parameters for the block that will consume them.

Field	Required	Description
Embedding model	Yes	Model used by the sources; choose one with an index
Data sources	Yes	One or more sources compatible with the selected model

1. Choose the embedding model first.
2. Select the sources you need from the suggestions.
3. Connect this block to the block that will use the sources, through its Contextual ports section.

A model marked no index provisioned cannot be selected. If no sources are offered, check their compatibility with the chosen model. After a model change, Studio removes sources that are no longer compatible: review the selection again.

The block prepares the selection’s parameters. Searching and answer generation are performed by the blocks or tools that use those parameters.

Outputs: llmConnectorId, dataSourceIds, index, embeddingModel, and dimensions. For example, {{dataSources-1.dataSourceIds}} is the list of selected source identifiers. The index, model name, and dimensions are filled automatically from the chosen model.

For a source connection, one Data Sources block can be connected to the consuming block; it can contain several sources. Follow the source and tool connection guide for the canvas steps.

Variables

Creates or recalculates values to simplify a reference, share data between blocks, or retain it during a conversation.

A single block can define several variables. The block is empty when added: click Add a variable for each value to create, and Delete the variable to remove one.

For each variable:

Field	Required	Default	Description
Scope	Yes	Request	Request or Conversation
Name	Yes	-	Unique variable name
Value	Yes	-	Value or expression to store; accepts several lines

Request limits the value to the current execution. Conversation retains it across several messages.

Variable 1
Scope: Request
Name: userEmail
Value: {{userData.email}}

Variable 2
Scope: Request
Name: supportGuidelines
Value:
Answer in English.
Always cite the source used.

This block directly creates {{userEmail}} and {{supportGuidelines}}. It does not expose traditional outputs prefixed with its identifier.

Best practices: prefer Request, use short names without spaces or special characters, and avoid duplicates, which are reported in the issues panel.

Condition

Selects a route according to one or more rules: data available, sufficient score, authorized profile, or tool calls requested.

Choose a route with a condition

100 %

• After success
• After failure
• Condition
• Else

Drag to move. Use + / − to zoom, arrow keys to move, and Home to reset.

Field	Required	Description
Expression	Yes	Rule to evaluate
Next block	Yes	Destination when the rule is true
Else	Recommended	Destination when no rule matches

The Expression field is not a text template: do not wrap the entire expression in {{ and }}.

Need	Expression
Tool calls are present	gt (length chatCompletion-1.genericToolCalls) 0
Score and email domain	and (gte score 70) (match userData.email "@wikit\\.ai$")
High priority or urgent message	or (eq ticket.priority "high") (contains userMessage "urgent")
Between one and five documents	and (gte (length documents.body) 1) (lte (length documents.body) 5)
No document or low confidence	or (eq (length documents.body) 0) (lt confidenceScore 0.5)

Available operators include equality and inequality, gt/gte/lt/lte, and, or, not, match, and contains. To test for an empty list, compare its length with zero: eq (length myList) 0.

Outputs: hasMatch, matchedIndex, and nextStep.

Best practices: keep rules simple, clearly name destinations, provide an Else case, and test every branch.

LLM instruction

Prepares what is sent to the model: system instruction, history, documents, tools, and token budget. It prepares data but does not generate the final answer.

Prepare an LLM instruction

100 %

Dashed boxes represent data, services, or results.

Drag to move. Use + / − to zoom, arrow keys to move, and Home to reset.

Main field	Required	Description
LLM model	Yes	Model used to prepare and estimate the prompt
LLM connector name	Yes	Filled after selecting the model, or entered as a variable
Instruction	No	System instruction with optional variables

To choose the model at runtime, enter a variable in LLM connector name, for example {{selectedModel}}. The LLM model list is then disabled and shows Defined by variable.

Advanced configuration	Default	Description
Maximum tokens	128000	Prompt budget; accepts a fixed value or a variable
Tools	{{listTools-1.tools}}	Prefilled reference to adapt to the actual catalog or disable without MCP
Document configuration	Disabled	JSON array of documents to inject when needed
Expiration messages	-	Replacement for old documents/tool results

Document configuration is disabled when the block is added. Enable it only when injecting documents from a variable. Example:

[
  {
    "varName": "{{documents.body}}",
    "documentType": "elasticsearch",
    "expiresAfter": 3,
    "maxDocumentsTokens": 16000
  }
]

This configuration remains available for sources already stored in a variable and for legacy integrations. In new RAG workflows, MCP Retriever results are automatically appended to conversationHistory by MCP - Call tools; leave Document configuration disabled.

Tools: {{listTools-1.tools}}.

Outputs: raw, metadata, messages, instruction, tools, model, and maxTokens. A common reference is {{generatePrompt-1.instruction}}, or its alias equivalent. model returns the model used and maxTokens the applied budget, which is useful when these values are defined by a variable.

Answer only from the provided documents.
User question: {{userMessage}}

Best practices: keep the instruction structured, separate rules from dynamic data, and enable documents or tools only when needed.

Common errors: no model selected, wrong document reference, tools enabled without an MCP catalog, invalid JSON, or insufficient token budget.

LLM request

Calls the model with the prepared instruction and produces a text answer or tool requests.

LLM request exchanges

100 %

Dashed boxes represent data, services, or results.

Drag to move. Use + / − to zoom, arrow keys to move, and Home to reset.

Main field	Required	Default	Description
LLM model	Yes	-	Generation model
LLM connector name	Yes	-	Filled after selecting the model, or entered as a variable
Instruction variable	Yes	-	For example {{generatePrompt-1.instruction}}
LLM API URL	Yes	LiteLLM	Call endpoint

As with the LLM instruction, a variable entered in LLM connector name disables the LLM model list, which then shows Defined by variable.

Additional parameters	Default	Description
HTTP headers	-	LLM API headers, as a JSON object
Timeout	60	Timeout in seconds
Temperature	1	Variation between 0 and 2
Maximum number of generated tokens	-	Maximum tokens produced by the model, reasoning included
Reasoning effort	Disabled	none, minimal, low, medium, high, xhigh, or max
Streaming	true	Progressive output
Tools	{{listTools-1.tools}}	Adapt to the actual catalog or disable without MCP
Strict mode	true	Enforces tool schemas

A temperature of 0 suits factual answers; 0.5 favors stability; 1, the default, allows more variation; higher values make answers more creative and unpredictable.

Reasoning effort sets how long models that support it think before answering: higher effort improves complex tasks but increases response time and token usage. Keep Disable if you do not need it. Each model only accepts some of these values: an unsupported value makes the request fail and follow After failure.

Outputs: content, genericToolCalls, and metadata.

Best practices: place an LLM instruction immediately before this block, keep streaming enabled, and change the technical URL only when required.

MCP - List tools

Loads tools from one or more MCP servers so the model can request them later.

Load the MCP catalog

100 %

Dashed boxes represent data, services, or results.

Drag to move. Use + / − to zoom, arrow keys to move, and Home to reset.

For each server:

Field	Required	Default	Description
MCP server name	Yes	-	Business label
MCP server URL	Yes	-	MCP endpoint
MCP server headers	No	{}	Authentication and context
Tools	No	[]	Allowed tools
Meta	No	-	Additional metadata, entered as key/value pairs

Use Get tools to query the server, then allow only the actions required by the workflow. An empty allowed-tools list leaves all of the server’s tools available.

Server headers:

{
  "Authorization": "{{customParams.mcpAuthorization}}"
}

In Meta, click Add Item for each metadata entry to send:

Key	Value
userEmail	{{userData.email}}
channel	{{customParams.source}}

The platform already sends organizationId, conversationId, llmAppId, queryExecutionId, workflowExecutionId, and userData to the server automatically. Do not use these keys in Meta: an entered value would replace the one provided by the platform.

Outputs: tools, toolServerRouting, and metadata.

This block can be placed in a path built one block at a time or connected to a block that offers a port for MCP tools. In the second case, it stays outside the main path; the consuming block prepares the catalog before using it. See the connection guide.

Common errors: wrong URL or token, invalid JSON, unavailable network access, tools not fetched, or an inconsistent selection.

MCP - Call tools

Runs calls requested by an LLM request. It consumes both genericToolCalls and the routing prepared by the tool catalog.

Execute requested tools

100 %

Dashed boxes represent data, services, or results.

Drag to move. Use + / − to zoom, arrow keys to move, and Home to reset.

Field	Required	Default	Description
Tool executions	Yes	-	{{chatCompletion-1.genericToolCalls}}
Tool routing server	Yes	-	{{listTools-1.toolServerRouting}}
Timeout	Yes	60	Tool call timeout

Outputs: metadata and toolCallResults.

Place a condition before this block to confirm calls are present. After execution, return to the LLM instruction block to rebuild the instruction with the results, then to the request that reads it.

Common errors: reference to the wrong LLM or catalog, empty call list, expired token, or a timeout that is too short.