---
title: "Using the Tool Playground"
manual: "LLM Foundation"
version: "main"
permalink: "https://docs.typo3.org/permalink/netresearch/nr-llm:using-the-tool-playground@main"
source: "Administration/ToolPlayground.rst"
rendered: "2026-11-12T15:41:35+00:00"
---

# Using the Tool Playground {#using-the-tool-playground}

## Using the Tool Playground {#administration-tools-playground}

The playground lives in **AI > Operation > Playground** and is
admin-only. It is a sibling of the [Tools](https://docs.typo3.org/permalink/netresearch/nr-llm:administration-tools-manage@main) management module: the playground *runs* the
loop, while the Tools module governs *which* tools exist and are enabled.

![The Tool Playground module with the LLM configuration picker, an empty prompt box, the Run button, and the Available tools panel](../Images/ToolPlaygroundShell.png)

> [!TIP]
> **Small local models work best with a narrow tool set.** With every
> group enabled, the model is offered every enabled tool declaration at
> once (several dozen). Small models such as the seeded `qwen3:4b`
> often fail to pick the right tool from a set that large, or reason
> past the token budget without calling any. Untick the groups that are
> irrelevant to the question — restricted to one or two groups, the same
> model picks the right tool. Larger hosted models cope with the full
> set.

1.  Pick an **LLM configuration** from the dropdown. Its vault-stored API key,
    model, temperature and system prompt are what the loop actually runs on —
    the playground never falls back to a default model.
1.  Type a **prompt**. Optionally open the override panels to **force-inject
    skills** (added on top of the configuration's own), **force-add snippets**
    (inserted as leading system messages), override the **system prompt**, cap
    the **max rounds**, or tick **capture raw provider response**.
1.  Click **Run** — or **Dry run** to assemble the prompt and
    inspect exactly what *would* be sent without calling the model.
1.  Read the **inspector** — live from the moment you click Run. A summary
    strip reports rounds, tool calls, the prompt/completion token split,
    estimated cost, wall time and status. The step list is the nr_llm ↔ LLM
    dialog in order: each round opens with a **Context budget** step,
    then its outbound **request** (the messages sent and the tools offered)
    appears the instant it goes out, a waiting indicator shows while the model
    works, then the **response** and each tool execution stream in. Select a
    step to open its detail — requests carry **Messages sent** and
    **Tools offered**; responses carry **Structured**,
    **Raw JSON** and **Thinking**. The model's **final answer**
    closes the run.
1.  The **Context budget** step says where the window went for the round
    that follows it, so you can act on the component that is yours to change
    rather than only learn that history was dropped. It has two tabs:

    -   ****Where the window went****

        The window, the output reserve, the safety margin and the resulting
        budget, then four component lines — transcript, tool schema, system
        prompt (incl. snippets) and skills — that **sum to the estimated total**,
        plus what is left. On this surface the system-prompt line always reads
        *counted in the transcript* and the skills line always reads 0: the agent
        loop builds both into the transcript before the fit measures it, so their
        content is already on the transcript line. The table says so under the
        figures. A send whose reserve exceeds the whole window is handed to the
        provider unmeasured, and the step reports *no accounting* instead of a
        window of zero.

    -   ****Injected context****

        Every snippet and skill this run injects, by **name only**, with the data
        class it declared ([ADR-144](https://docs.typo3.org/permalink/netresearch/nr-llm:adr-144@main)) or *not classified*, and the
        strictest class across all of them. The list covers the snippets and
        skills you force-injected for this one run as well as the
        configuration's own, and the input-context gate reads the same list
        ([ADR-164](https://docs.typo3.org/permalink/netresearch/nr-llm:adr-164@main)): a source shown here is a source that is
        gated. Forcing a snippet the configuration's trust zone would refuse
        therefore refuses the run, naming that snippet.

![A completed tool run — the summary strip, the ordered step list and the selected step's detail tabs for a two-iteration agent loop](../Images/ToolPlaygroundRun.png)

The **Tools available to this run** list lets you narrow a single run
to a subset of the globally-enabled tools. Unticking every tool sends a plain
completion with no tools offered (the full list and the global
enable/disable controls live in the [Tools](https://docs.typo3.org/permalink/netresearch/nr-llm:administration-tools-manage@main) module). Raw-response capture is off unless you
tick it, so ordinary runs never retain the provider's raw payload. Every
displayed string — tool arguments, tool results (which may include
`sys_log` content), and the final answer — is rendered escaped; HTML is
only ever shown inside a sandboxed preview, never injected into the page.

The inspector distinguishes a completed run from a run waiting for approval
or input, a guardrail outcome, or cancellation. Waiting runs show their run
reference and direct you to **AI > Operation > Agent Runs** for the existing
approval or input workflow. The playground does not add a second decision
form. A stream that ends without a settled result keeps its received steps
and is marked *incomplete*, rather than completed.

Each run is bounded by the round cap (the playground's *Max rounds*, else
`agent.defaultMaxIterations`, never above `agent.maxIterations`) and, when the
configuration's backend user has a budget, by the per-iteration budget
pre-flight. If the cap is hit with tools still pending, a final tool-free
completion synthesises a closing answer and the run is marked *truncated*.
The aggregated **token** usage is reported; the monetary cost is recorded in
the usage table by the middleware pipeline.

## Ollama model-capability dependency {#administration-tools-ollama}

Tool calling depends on the **model**, not just the provider. For Ollama,
only function-calling-capable models — for example `llama3.1`,
`mistral`, `qwen2.5` — return tool calls. A model without function-calling
support simply **answers the prompt directly and never calls a tool**; the
loop ends gracefully on the first plain answer. If a configured Ollama model
never seems to use the available tools, verify it is one of the
function-calling models for your Ollama version.