Document how to get Open WebUI to run tool calls server-side over the API

People wiring scripts, bots and agents into Open WebUI keep hitting the same wall: they send a prompt with tool_ids, get a raw tool_calls object back, and have no way to execute a builtin tool like web search or the code interpreter from their own process. Nothing in the docs said which request fields decide whether Open WebUI runs the tools for you.

The new Reference page spells that out. `/api/chat/completions` behaves in three different ways and the request body picks which one: the native multi-round loop needs `chat_id`, `id` and `stream: true` and returns its answer through the chat record rather than the HTTP body; `session_id` is what makes the builtin tools available at all; legacy function calling runs one round inline and returns everything in the response. It also flags that a model's configured terminal is applied by the frontend, so an API caller has to send `terminal_id` itself.

It is written as two end-to-end paths, full agentic loop and single request, each with the calls in order, both streaming and non-streaming, both with and without the chat being saved, and a reusable Python script at the end. Reference lives in Reference rather than Tutorials because this is core API behaviour, not a community integration.

Author: Classic298

docs/reference/api-endpoints.md

@@ -112,6 +112,10 @@ Open WebUI checks the caller's access to each selected tool server before resolv
 
 If your external client sends its own OpenAI-style `tools` array, Open WebUI forwards those caller-provided tool definitions to the model instead of resolving `tool_ids` server-side.
 
+:::tip Want the model to actually run those tools, in a loop, with the built-in tools too?
+Which fields you send decides whether Open WebUI executes tool calls for you or hands them back for your client to run, and whether the answer arrives in the HTTP body or in the chat record. [Server-Side Tool Calling (API)](/reference/server-side-tool-calling) walks through every call for both approaches, streaming and non-streaming, with and without saving the chat, and ends in a reusable script.
+:::
+
 - **Curl Example**:
 
   ```bash

docs/reference/api-flow.md

@@ -30,6 +30,10 @@ Before following this tutorial, ensure you have:
 
 This tutorial describes a comprehensive 6-step process that enables server-side orchestration of Open WebUI conversations while ensuring that assistant replies appear properly in the frontend UI.
 
+:::tip Looking for tool calling specifically?
+If your goal is to have the model use tools (built-in tools, workspace tools, MCP servers or a terminal) and have Open WebUI execute them server-side, see [Server-Side Tool Calling (API)](/reference/server-side-tool-calling). It builds on the chat structures documented here and adds the fields that switch tool execution on.
+:::
+
 ### Process Flow
 
 The essential steps are:

docs/reference/index.md

@@ -59,6 +59,22 @@ Open WebUI exposes a full REST API authenticated via Bearer tokens or JWTs. Use
 
 ---
 
+## 🤖 Server-Side Tool Calling
+
+**Send a prompt, have Open WebUI run the tools, get the finished answer back.**
+
+Every request you need to make the model call built-in tools, workspace tools, MCP servers and Open Terminal on the server, with your user's own permissions. Streaming and non-streaming, with and without saving the chat, ending in a reusable script.
+
+| | |
+| :--- | :--- |
+| 🔁 **Full agentic loop** | Multi-round native tool calling, result read back from the chat |
+| ⚡ **Single-request mode** | One HTTP call in, one completion out, tool results already applied |
+| 🧭 **Field-by-field** | `chat_id`, `id`, `session_id`, `tool_ids`, `terminal_id`, `features` |
+
+[**Run tools server-side →**](/reference/server-side-tool-calling)
+
+---
+
 ## 🔒 HTTPS Configuration
 
 **Terminate TLS in front of Open WebUI with Nginx, Caddy, or HAProxy.**