Backend chat
A conversation in the TYPO3 backend, for the user who is signed in. No separate tool, no separate login.
TYPO3 extension · nr_mcp_agent
A controlled AI assistant for the TYPO3 backend.
Editors ask in the backend they already work in. The assistant reads what they may already see, and asks for an explicit approval before it changes anything.
Evaluate a backend agent under control Read the documentation
- Maturity
- Alpha
- Latest release
- v0.12.2
- Main branch
- 0.12.2
- Page last reviewed
- Requires
- TYPO3 13.4 / 14.0 · PHP 8.2+ · nr-llm
Latest release and main branch are different values, and the review date is a third. A difference between them is not a contradiction.
What you can tell in ten seconds
- Alpha or stable?
- Alpha. Evaluate it with someone watching.
- Read only, or write too?
- Read by default. Writing tools ship disabled.
- Where is a human required?
- Before every write. The run suspends until someone approves or rejects.
- What risks remain?
- Prompt injection, a wrong proposal approved without reading it, and too large a tool set.
- How is use limited?
- Per-group tool release, TYPO3 permissions, and nr-llm's budgets.
- How do I try it?
- Install it, point it at an nr-llm configuration, release a read-only tool group.
What works today
Stated as what it does, not as what it will do.
Retrieving information
The assistant can look things up through the tools an administrator released, and summarise what it found.
Released MCP tools only
Tools are configured per server and per permission. Nothing is available by default; the empty set is the starting point.
Conversation history
A run can be re-read afterwards. Without that there is nothing to review.
Known content operations
The content operations documented for the current release, each one either read-only or approval-gated. The documentation lists them; this page does not restate the list, because a list restated is a list that goes stale.
What is not promised
Five things the extension does not do. If you need one of them, this is the wrong tool today.
- Autonomous CMS operation. It has no schedule, no trigger and no unattended mode.
- Unrestricted write access. Writing tools are released per group and gated per call.
- Automatic approval. There is no timeout that approves on your behalf.
- A faultless substitute for an editor. It proposes; a person decides.
- Unreviewed actions. Everything that changes something leaves an audit record with the approver's decision.
Three controlled scenarios
In order of how much trust each one needs.
-
Find and summarise
Ask where a topic is covered across the pages the acting user may see, and get a summary with the records it came from.
Read-only tools. No approval needed, because nothing changes.
-
Prepare a change
Ask for a proposed rewrite, a translation or a set of alt texts. The result is a proposal in the conversation, not an edit.
Still read-only. The editor copies what they want, or asks for another version.
-
Execute an approved change
With a writing tool released, the assistant proposes the exact change and waits. On approval it executes; on rejection it stops.
Approval gate, audit record, TYPO3 permissions. The approver reads the proposal — that is the control, and skipping it removes it.
Who may do what
Six layers, each of which can stop a run on its own.
| Layer | What it decides |
|---|---|
| Backend user role | Whether the person may use the assistant at all. |
| Released tools | Which MCP tools exist for that group. The default is none. |
| Read or write | Whether a tool changes anything. Writing tools ship disabled. |
| Explicit approval | Whether a specific write actually happens, decided by a person, per call. |
| TYPO3 permissions | Whether the record is reachable for the acting user. Not bypassed. |
| Audit record | What happened afterwards: tool, user, arguments, decision. |
Cancellation and failure
A rejected approval stops the run and records the rejection. A failing tool call surfaces the error rather than retrying silently, and a run that exceeds its nr-llm budget stops with an explicit reason.
How it relates to nr-llm
This extension is the agent interface. nr-llm is the controlled AI base underneath it.
Provider and model
Chosen in nr-llm. This extension holds no key and talks to no provider directly.
Budgets
nr-llm's per-user request, token and cost limits apply to agent runs like any other AI use.
Cost analytics
Agent usage shows up in the same analytics as every other AI feature on the site.
Fallbacks
Provider fallback chains are configured once in nr-llm and apply here too.
Where the boundary is
nr-mcp-agent decides what the agent may attempt. nr-llm decides which model answers, at what cost, for whom.
Security
The risks an agent brings, named rather than implied.
Excessive agency
The most common failure of an agent is being allowed to do too much. Release the smallest useful tool set; the default of none exists for that reason.
Prompt injection
Content the agent reads can contain instructions. The tool release list and the approval gate bound the damage; they do not prevent the attempt.
Tool poisoning
A tool description is part of the model's input. Release tools from sources you control, and read what a tool declares before releasing it.
Data disclosure
The agent can only reach what the acting user may reach. That makes the acting user's permissions the disclosure boundary — review them before you widen access.
Permission escalation
Approval is per call and cannot be delegated to the agent. An approver who approves without reading is the escalation path that remains.
Cost and resource limits
nr-llm's budgets apply. A run that exceeds them stops with an explicit reason rather than continuing quietly.
Logging and traceability
Tool, user, arguments and decision are recorded for every call, which is what makes an after-the-fact review possible.
AI capability card
The same fields on every Netresearch AI product, so they can be compared rather than admired.
- Intended purpose
- A controlled assistant in the TYPO3 backend: finding and summarising content an editor may already see, preparing changes, and executing a released change after an explicit human approval.
- Excluded uses
- Unattended operation. Alpha means evaluate it with someone watching.
- Autonomous content changes. Every write goes through an approval.
- Replacing an editor's judgement. It drafts; a person decides.
- Bypassing TYPO3 permissions. It cannot reach what the acting user cannot reach.
- Anything with a legal, financial or personnel consequence.
- Maturity
- Alpha
- Models and providers
- Whatever nr-llm is configured with. This extension chooses no provider and holds no key.
- Data processed
- The editor's question, the conversation history of that run, and whatever a released tool returns.
- Tool calls and their arguments, for the audit trail.
- Processing location
- Your own server, An external provider
- Human oversight
- Reading needs no approval. Every writing tool suspends the run until a person approves or rejects it, and the decision is recorded.
- Permissions
- Administrators release MCP servers and tools per backend group. TYPO3's own access rules apply on top and are not bypassed.
- Logging
- Every tool call is recorded with tool, user, arguments and approval decision. Model usage is recorded by nr-llm.
- Retention
- Conversations and audit records live in the site's database and follow the site's own retention rules.
- Cost control
- Inherited from nr-llm: per-user budgets on requests, tokens or estimated cost.
- Security controls
- Read-only by default; writing tools ship disabled
- Approval gate with a recorded decision
- Per-group tool release
- TYPO3 backend permissions enforced, not bypassed
- Provider keys and budgets stay in nr-llm
- Known limitations
- Alpha. Interfaces, tool contracts and configuration can still change between releases.
- Prompt injection through content the agent reads is possible. The tool release list and the approval gate are the mitigation, not immunity.
- The model can misread an instruction and propose the wrong change. That is what the approval is for — an approver who does not read the proposal removes the control.
- Excessive agency is a design risk of any agent. Release the smallest useful tool set, not the largest available one.
- It is only as reliable as the model behind it, and that model is configured elsewhere.
- Last reviewed
- · Netresearch DTT GmbH — nr-mcp-agent maintainers
Trying it out
Four steps. Stop after the third if you only want to see what it reads.
- Installcomposer require netresearch/nr-mcp-agent
- Point it at nr-llmChoose an existing nr-llm configuration. Provider, model and budget come from there.
- Release a read-only tool groupStart with the smallest set that makes the assistant useful for one task.
- Only then consider a writing toolRelease it for one group, on one kind of record, and read what it proposes before approving.
Evidence
What backs the statements above.
Source code
Public, with its release history and changelog.
Technical documentation
Installation, configuration, MCP server setup, the tool contracts and the developer reference.
Releases
Every release with its notes, so a change in behaviour is traceable to a version.
What is not claimed
- No conformity claim for the EU AI Act, the NIST AI Risk Management Framework or ISO/IEC 42001. The extension supports controls; whether an organisation is conformant is a legal and organisational assessment.
- No productivity or savings figure. We do not know your editorial volumes.
- No guarantee about model behaviour. The controls bound what the agent may do, not what the model may say.
Evaluate a backend agent under control
We work through which tools to release, who approves what, and what an alpha evaluation has to produce before it can become anything more.