Build a RAG chatbot with MCP Retriever

RAG searches your sources before producing an answer. With MCP Retriever, the model selects the search tool, Studio runs it, and its result is added to conversation history for a grounded answer.

Configure a block that uses your sources

If the RAG block available in your organization offers a Data sources connection:

1. Add that block and connect it to the path from Start.
2. Fill in its editable fields, including instructions and the response model when offered.
3. Add a Data Sources block and choose the embedding model and compatible sources.
4. In the RAG block’s panel, open Contextual ports and use Connect block to connect your sources.
5. Connect the available outputs, save, and test a question covered by the sources and one with no result.

The Data Sources block stays outside the main path. Searching is performed by the block using the sources. The connection guide explains the steps and empty selections.

Build the MCP Retriever path one block at a time

The following example uses standard blocks to configure the search loop explicitly. No HTTP request block or documents configuration is required for this MCP path.

RAG document search

100 %

• After success
• After failure
• Condition
• Else
• Data or result

Dashed boxes represent data, services, or results.

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

Step-by-step configuration

1. Add MCP - List tools as the entry point.
2. Configure the MCP Retriever server for your environment and select at least retriever_retrieve_information.
3. In server metadata, provide the identifier of the LLM connector used by the sources. Organization and conversation identifiers are sent automatically by the platform.
4. Add an LLM instruction, enable {{listTools-1.tools}}, and explain when the retriever must be used.
5. Add an LLM request using {{generatePrompt-1.instruction}} and {{listTools-1.tools}}.
6. Add a condition: gt (length chatCompletion-1.genericToolCalls) 0.
7. On the positive route, run MCP - Call tools with the model’s calls and catalog routing.
8. After calling tools, return to the same LLM instruction, then the LLM request. The instruction is rebuilt with the results. When the condition is false, content is the final answer.
9. Connect failure branches to a clear, non-technical message.

MCP Retriever server

Example server configuration in MCP - List tools:

{
  "name": "Wikit Retriever",
  "url": "<MCP_RETRIEVER_URL>/mcp",
  "allowedTools": [
    "retriever_retrieve_information",
    "retriever_get_table_metadata",
    "retriever_run_sql_query"
  ],
  "meta": {
    "llmConnectorId": "<LLM_CONNECTOR_ID>"
  }
}

retriever_retrieve_information searches relevant document passages and tabular sources in parallel. The other two tools are useful when an answer requires inspecting a table schema and then running a read-only SQL query.

For a strictly document-based assistant, you can restrict allowedTools to the retrieval tool. The exact URL and metadata depend on your environment and enabled sources.

Variables to connect

Reference	Purpose
{{listTools-1.tools}}	Catalog passed to the LLM instruction and request
{{listTools-1.toolServerRouting}}	Routing to the MCP Retriever server
{{generatePrompt-1.instruction}}	Instruction prepared for the model
{{chatCompletion-1.genericToolCalls}}	Tool calls requested by the model
{{callTools-1.toolCallResults}}	Retriever results, useful for debugging and traceability

MCP - Call tools automatically appends results to conversationHistory. Returning to LLM instruction rebuilds the prompt with those results. The request keeps the {{generatePrompt-1.instruction}} reference, so there is no need to copy toolCallResults into document configuration.

Basic instruction

Answer from the internal sources available through the MCP tools.

For any question that may be covered by these sources, first call
retriever_retrieve_information with a precise search query.

If document passages are sufficient, answer from those passages and cite the document
name and page numbers when available.

If a table is relevant, call retriever_get_table_metadata before making any query with
retriever_run_sql_query.

If no relevant source is found, say so clearly without making up an answer.

Why this architecture works

1. The model turns the user question into a focused search query.
2. MCP Retriever returns document passages and, when needed, table metadata.
3. MCP - Call tools places the result in the current turn’s history.
4. The model can answer, refine its search, or request another tabular tool.
5. The condition ends the loop as soon as no additional tool call is requested.

This loop supports several targeted searches without exposing the HTTP URL, Elasticsearch index, embedding model, or raw retrieval request format to the workflow.

Checks

• the tool-list block contains retriever_retrieve_information;
• server metadata contains the correct llmConnectorId;
• both the LLM instruction and request receive {{listTools-1.tools}};
• the condition checks the length of genericToolCalls without braces around the full expression;
• MCP - Call tools receives calls and routing from the correct blocks;
• after calling tools, the path returns to the same instruction, which keeps the tools, then to the LLM request;
• empty results produce an honest answer;
• the loop has an exit and old tool results expire after a suitable number of turns.