Studio block reference

This page explains the purpose, configuration, and outputs of the eight main blocks. They all share the basic information, advanced configuration, and output 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.

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.

Variables

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

Field	Required	Default	Description
Scope	Yes	REQUEST	REQUEST or CONVERSATION
Name	Yes	-	Unique variable name
Value	Yes	-	Value or expression to store

REQUEST limits the value to the current execution. CONVERSATION retains it across several messages.

Scope: REQUEST
Name: userEmail
Value: {{userData.email}}

This block directly creates {{userEmail}}; 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.

Condition

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

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 (isEmpty documents.body) (lt confidenceScore 0.5)

Available operators include equality and inequality, gt/gte/lt/lte, and, or, not, match, contains, and isEmpty.

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.

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

Advanced configuration	Default	Description
Maximum tokens	128000	Prompt budget
Tools	null	Reference to MCP tools
Document configuration	null	JSON array of documents to inject
Expiration messages	-	Replacement for old documents/tool results

Document configuration:

[
  {
    "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, and tools. A common reference is {{generatePrompt-1.instruction}}, or its alias equivalent.

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.

Main field	Required	Default	Description
LLM model	Yes	-	Generation model
LLM connector name	Yes	-	Filled automatically
Instruction variable	Yes	-	For example {{generatePrompt-1.instruction}}
LLM API URL	Yes	LiteLLM	Call endpoint

Advanced configuration	Default	Description
HTTP headers	{}	LLM API headers
Timeout	60	Timeout in seconds
Temperature	0.5	Variation between 0 and 2
Token limit	-	Maximum generated tokens
Streaming	true	Progressive output
Tools	null	For example {{listTools-1.tools}}
Strict mode	true	Enforces tool schemas

A temperature of 0 suits factual answers; 0.5 balances stability and variation; 1 or more increases creativity and unpredictability.

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.

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

Use Fetch tools to query the server, then allow only the actions required by the workflow.

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

{
  "conversationId": "{{queryExecutionId}}",
  "userEmail": "{{userData.email}}"
}

Outputs: tools, toolServerRouting, and metadata.

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.

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, prepare a new instruction when the LLM must rephrase the result.

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