Images, Videos, and Files for the TYPO3 MCP Server — Community Budget Project Delivered

The TYPO3 MCP Server is an extension that connects AI assistants to TYPO3 through the Model Context Protocol. Every content change an assistant makes lands in a TYPO3 workspace first, so editors review before anything is published. Until now, there was one big gap: media. The assistant could read and write records, but it could not see the fileadmin, upload a file, or attach an image to a content element. For everyday editorial work — “put this image on the homepage” — that gap was the difference between a demo and a tool.

Closing it was the goal of the community budget idea Image Support for TYPO3 MCP Server, funded in the Community Budget Ideas 2026. The result is now merged and released. Here is what it does.

The heart of the release is a single new UploadFile tool that supports four ingestion paths. The assistant picks the right one on its own, based on what the editor asks for:

“Put this image on our homepage: example.org/press/team.jpg” — the TYPO3 server downloads the file itself. The image never passes through the AI’s context, which keeps large photos both cheap and private.

“Put this video on the home page: www.youtube.com/watch?v=…” — video links become proper TYPO3 online media assets. The video itself stays where it is.

Text-based formats like SVG or CSV can be uploaded as raw content. In our tests, models even generate an SVG chart from data in the conversation and upload it in one step.

“Upload the team photo from my Desktop” — this is the interesting one. Binary data has no good path through an LLM: pasting a photo into tool arguments as base64 is slow, expensive, and lossy. Instead, the tool hands out a pre-signed, single-use upload URL. The file goes directly from your machine to TYPO3 — out-of-band, never through the model’s context. The token behind that URL is stored only as a SHA-256 hash, is valid for 15 minutes, is bound to your backend user and target folder, and is consumed atomically on first use — a leaked token is a single attempt, not a standing permission.

A typical end-to-end flow looks like this:

// 1. Upload the file (targetFolder defaults to the user's upload folder)
{"tool": "UploadFile", "params": {"url": "https://example.org/press/team.jpg"}}
// -> {"uid": 42, "fileName": "team.jpg", "publicUrl": "...", ...}
 
// 2. Create the content element referencing the file
{"tool": "WriteTable", "params": {
  "table": "tt_content", "action": "create", "pid": 1,
  "data": {
    "CType": "image",
    "header": "Our team",
    "image": [{"uid_local": 42, "alternative": "The team in front of the office"}]
  }
}}

Every upload response includes a nextStep hint with the concrete follow-up call — because an upload nobody references is invisible on the website.

Files needed different rules than records, and the design leans into that:

• Create-only — Unlike records, files are not workspace-versioned in TYPO3 — overwriting or deleting one would be immediately live and irreversible. So the MCP server simply never does either. Name conflicts are resolved by renaming (image.jpg becomes image_01.jpg), and uploading content that already exists returns the existing file instead of a duplicate.
• The reference is still staged — An uploaded file lands in your storage right away, but it only becomes visible on the website once a record references it — and that reference is workspace-staged. The usual review before publishing fully applies.
• Executable files are refused — both server-side (PHP, CGI, shell scripts) and browser-side formats that would enable stored Cross-Site Scripting (HTML, JavaScript), independently of TYPO3’s configurable fileDenyPattern. Server configuration files like .htaccess are blocked as well.
• Downloads are hardened against SSRF — Only public http(s) addresses are allowed; private and cloud-metadata IP ranges are rejected, every redirect hop is re-validated, and resolved IPs are pinned against DNS rebinding.
• Your permissions apply throughout — File mounts and storage permissions of the connected backend user are enforced on every path — including CLI connections, where TYPO3 core would not normally apply them.

Uploading is only half the story. The read side was extended so assistants can work with what is already there: sys_file is browsable read-only within the user’s file mounts, and every file record carries a computed public_url — which is how vision-capable models can actually look at an image before writing an alt text. File metadata (sys_file_metadata) is editable, so titles and alternative texts can be maintained or generated at scale. File references, including image cropping, are written through the regular WriteTable tool as inline records.

Like the rest of the project, the file features are verified against real LLMs, not just unit tests. A dedicated benchmark has current models from Anthropic, OpenAI, Mistral, and Google choose the correct upload path from the tool descriptions alone — and then connect the uploaded file to a content element. On top of that sit over 30 functional tests for the upload path alone, covering everything from redirect attacks to deduplication after TYPO3’s SVG sanitizer rewrites a file.

The original budget idea also sketched visual and semantic image search. That part did not make it into this release: finding existing images currently relies on file names and metadata, not on image content. AI-generated image descriptions can help bridge that gap today — a model can read a file’s public URL, look at the image, and write metadata — but a dedicated semantic search remains future work.

composer require hn/typo3-mcp-server

The extension requires TYPO3 v13.4+, and the defaults work out of the box; limits like the maximum file size are configurable in the extension settings. See the Technical Overview for the full tool reference and worked examples.