TYPO3 MCP Server

Model Context Protocol server for TYPO3 v14: structured, workspace-safe tools for pages, records, TCA/FlexForm schemas, file handling, and editorial workflow — over MCP for LLM clients (Cursor, Claude Desktop, …) and over the TYPO3 CLI for shell scripts and CI.

Built on the editor-first design of hauptsacheNet/typo3-mcp-server by Marco Pfeiffer. This fork tracks upstream and adds: capability-manifest enforcement, DDEV-aware local mode, preview/render tools for the editor verification loop, a complete CLI mirror of the MCP surface, and additional fork-only tools such as the file sandbox, content audit, preview/render loop, local-mode ergonomics, and site configuration helpers.

Continuously Tested With Real LLMs

Every push to main runs a benchmark that has models from Anthropic, OpenAI, Mistral, and Google actually use this MCP to perform real TYPO3 tasks. That's how we stay vendor-independent and prove the tool descriptions convey what they claim across very different prompting styles — your AI assistant of choice should just work, not only ours. Click any badge for the full run-by-run history.

In 60 seconds

An MCP client (Cursor, Claude Desktop, n8n, Manus, MCP Inspector) connects over OAuth to https://your-site/mcp and can:

Browse the page tree and read records with TCA context.
Safely edit content — writes land in a TYPO3 workspace by default.
Attach images, translate records, copy content, publish, or roll back.
Render a workspace preview URL or fetch the rendered HTML to verify a change without leaving the chat.
Import text/Markdown/HTML and propose or create content elements.
Audit content for missing metadata or alt text.

Every tool is available from the TYPO3 CLI: either through its dedicated vendor/bin/typo3 mcp:<tool-name> shortcut or through the universal vendor/bin/typo3 mcp:tool <ToolName> runner. CLI commands support --json, --plain, and --no-ansi output modes for shell scripting.

TYPO3 stays in control of permissions, TCA, DataHandler, workspaces, and language overlays. The MCP client sees a clean, machine-readable surface.

Status: experimental surface — tool names, parameters, and defaults may change between releases. Pin Composer versions. Validate in staging before relying on this in production.

Quick start

While there are a lot of automated tests, TYPO3 instances are widely different and language models are also widely different. Feel free to create issues here on GitHub or share experiences in the typo3-core-ai channel.

1. Install

composer require hn/typo3-mcp-server
vendor/bin/typo3 extension:activate mcp_server

Requirements

TYPO3 ^14.0 (no v12/v13 fallback paths in this fork)
PHP 8.2 – 8.5 as declared in ext_emconf.php
typo3/cms-workspaces

2. Open the backend module

In the TYPO3 backend, go to User → MCP Server. The module shows:

Your MCP endpoint URL (https://your-site/mcp).
One-click setup for Cursor and ready-to-paste config for Claude Desktop, n8n, Manus.
A live health check for OAuth discovery endpoints.
Token management (create/revoke personal-access tokens).

3. Connect a client

Client	Transport	Setup
Cursor	Local stdio	One-click install button starts `vendor/bin/typo3 mcp:server` without OAuth; DDEV projects use `ddev exec -p <project>`
Claude Desktop	Via `mcp-remote` proxy	Paste JSON config from the module
n8n	Remote HTTP + OAuth	Paste endpoint URL into the MCP Client node
Manus	Remote HTTP + OAuth	Paste endpoint URL
MCP Inspector	Remote HTTP	`npx @modelcontextprotocol/inspector …`
Local / trusted host	stdio	`vendor/bin/typo3 mcp:server`
Shell / CI / scripts	TYPO3 CLI	`vendor/bin/typo3 mcp:<tool-name> [--json]` or `vendor/bin/typo3 mcp:tool <ToolName> --json`

The first remote request triggers the OAuth flow: TYPO3 logs you in with your existing backend credentials and authorizes the client.

What changed in this fork

This repository is the TYPO3 v14-focused maintained line of the original hauptsacheNet MCP server. Compared with upstream/main, the current branch adds and hardens these areas:

TYPO3 v14 foundation — Composer constraints, services, TCA schema usage, workspaces, DataHandler calls, and tests are aligned with TYPO3 v14 only. There are no v12/v13 compatibility paths documented for this fork.
Workspace-safe editorial tool surface — record writes use TYPO3 workspaces, keep live-facing UIDs stable, auto-select or create a writable workspace, and hide internal version rows from MCP clients.
Remote and local transports — /mcp supports OAuth 2.1 + PKCE, protected resource metadata, dynamic client registration, streamable HTTP sessions, and a local stdio server for trusted development clients.
Backend module — User -> MCP Server now provides endpoint discovery, client setup snippets, token management, health checks, and workspace/context warnings using XLIFF 2 labels in English and German.
Capability manifest — Configuration/Capabilities.yaml declares every tool's required subsystem and outbound HTTP policy. AbstractTool enforces it at call time; UploadFileFromUrl and RenderRecord also enforce the network allowlist outside local mode.
DDEV/local mode — LocalModeService detects DDEV or TYPO3 Development context and can relax workspace-only writes, non-workspace-table writes, FAL sandbox limits, and outbound-network gates for local work. Production stays strict by default.
CLI mirror — every bundled MCP tool has a Symfony console command, plus mcp:tool <Name> and mcp:tool:list for generic automation. CLI output can be pretty, plain text, or JSON.
Expanded tools — the fork adds file sandbox tools, FAL search/browse tools, workspace review/publish/rollback, import/audit helpers, preview and render verification, site configuration helpers, safe CLI execution, optional x402 tools, and dev-site tools for Site Sets, ViewHelpers, TCA resources, and XLF authoring.
Security hardening — tokens are hashed, query-string bearer tokens stay disabled by default, the auth-header diagnostic is off by default, sensitive HTTP logs are redacted, PKCE requires S256, browser-defense headers are set, unsafe system columns are rejected, SVG text writes are not allowed by default, and outbound HTTP has SSRF checks outside local mode.
Quality gates — PHPUnit unit/functional suites, PHPStan, PHP CS Fixer, Rector, Fractor, Playwright E2E tests, architecture tests, and real LLM workflow tests are wired into the development and CI flow.

The detailed manual page is Documentation/Introduction/ForkChanges.rst. It intentionally describes the current live implementation only, not obsolete experiments or generated build output.

Example session

What an "add a news article on page 42" conversation looks like at the tool-call level. The MCP client drives these calls; you only write a natural-language prompt.

USER: Add a news article "Spring Sale" on the News page with a short teaser.

// 1. Discover context
GetCapabilities {}                                 // know what's allowed
GetPageTree     { "startPage": 1, "depth": 3 }
ListTables      {}
GetTableSchema  { "table": "tx_news_domain_model_news" }

// 2. Write into a workspace (auto-selected/created)
WriteTable {
  "table": "tx_news_domain_model_news",
  "action": "create",
  "pid": 42,
  "data": {
    "title":    "Spring Sale",
    "teaser":   "30% off selected items for two weeks.",
    "datetime": "2026-04-20"
  }
}
// → { "action": "create", "table": "tx_news_domain_model_news", "uid": 1234, "pid": 42 }

// 3. Verify before publishing
GetPreviewUrl { "table": "tx_news_domain_model_news", "uid": 1234 }
RenderRecord  { "pageId": 42, "mode": "text", "maxLength": 5000 }

// 4. Review and publish
WorkspaceReview  {}
PublishWorkspace { "dryRun": false }

The live UID 1234 is stable across workspace and live — MCP clients never see the internal workspace version ID.

Capabilities at a glance

The extension ships 44 bundled MCP tools across these groups. For the authoritative list with parameters, see Documentation/Tools/Index.rst. The same tool-to-subsystem map is also exposed by the GetCapabilities tool, gated by Configuration/Capabilities.yaml.

Discovery & schema — GetCapabilities, ListTables, GetTableSchema, GetFlexFormSchema
Navigation & search — GetPageTree, GetPage (uid, pageId, or url), Search (accepts query or terms)
Read & write records — ReadTable (structured filters with sys_language_uid ISO codes and boolean hidden), WriteTable, BulkWrite, CopyContent, AttachImage
Verification — GetPreviewUrl (signed workspace preview link), RenderRecord (fetches the FE HTML so the LLM can see the result)
Content import — ImportContent, ImportFromUrl
Workspace workflow — ListWorkspaces, WorkspaceReview, PublishWorkspace (supports tables list and onlyTranslations), RollbackWorkspace
Files (sandboxed) — BrowseFolder, BrowseFiles, WriteFile, UploadFile, UploadFileFromUrl, ReadFileMetadata, SearchFile, SearchMedia, ListStorages
Diagnostics — ContentAudit, GetSystemLog, ManageRedirects
Admin / operations — CreateSite, SiteSet, InstallExtension, SafeCli
Dev-site only (DDEV / localUnsafeMode) — SiteSettings, ListViewHelpers, GetViewHelperDocumentation, CreateLocallang, MCP TCA resources (typo3-mcp://tca, typo3-mcp://tca/{table})
Optional: x402 monetization — ListPaidContent, GetPaidContent, GetPaymentStats (when typo3-x402-paywall is installed)

Frontend design-system tooling

ApplyShadcnPreset is an admin-only helper for applying a copied shadcn/create preset to an existing frontend project directory. The MCP server does not own TYPO3 Fluid template sets or Desiderio's frontend component recipes; those stay in the consuming sitepackage where Visual Editor content areas, site settings, CSS tokens, and template overrides can evolve together.

Dev-site tools (DDEV / local development)

Dev-site tools use the same localMode gate as live workspace writes and unrestricted file access (see DDEV / local-development mode below). When localUnsafeMode resolves to on — via DDEV, TYPO3 Development context, or explicit localUnsafeMode=on — the MCP server also exposes tools that stay hidden on production endpoints. Record tools default to the live workspace when workspace_id is omitted (major local-dev change; production unchanged). See Documentation/Configuration/LiveEditsOnDevelopment.rst for a plain-language guide and per-user opt-out. Production override (DDEV-like live chatbot edits on a non-DDEV server) is documented in the same guide — use with extreme care. mcpServer.strictSandbox turns all relaxations off, including dev-site tools, even inside DDEV.

Tool	Purpose
`SiteSettings`	List Site Set setting definitions; read/update `settings.yaml`
`ListViewHelpers` / `GetViewHelperDocumentation`	Fluid ViewHelper reference
`CreateLocallang`	Create or extend XLF files in extensions
MCP resources	`typo3-mcp://tca` overview + `typo3-mcp://tca/{table}` with access checks

GetCapabilities reports devSiteTools.available alongside localMode. Install editor workflow skills for Claude Code / OpenCode:

vendor/bin/typo3 mcp:install-editor-skills
# DDEV: ddev typo3 mcp:install-editor-skills

This copies typo3-content-edit and typo3-translate-page skills into .claude/skills/.

CLI shortcuts (dev-site / DDEV):

ddev typo3 mcp:site-settings --action=listDefinitions --identifier=main --json
ddev typo3 mcp:list-viewhelpers --json
ddev typo3 mcp:get-viewhelper-documentation --tagName=f:for --json
ddev typo3 mcp:create-locallang --extensionKey=my_ext --fileName=locallang.xlf \
  --params '{"transUnits":[{"id":"label","source":"Label"}]}' --json
ddev typo3 mcp:tca-resource --json                    # MCP resource typo3-mcp://tca
ddev typo3 mcp:tca-resource --table=pages --json      # typo3-mcp://tca/pages
ddev typo3 mcp:install-extension --action=list --json
ddev typo3 mcp:install-editor-skills

Adding a site configuration

CreateSite accepts a live root page UID and an optional rendering definition so the frontend renders with the intended theme out of the box. Site configuration is YAML-backed and not workspace-versioned, so prepare or publish the root page before pointing a site config at it.

CreateSite {
  "action": "create",
  "identifier": "launch-2026",
  "rootPageId": 474,
  "base": "https://example.com/",
  "dependencies": ["webconsulting/desiderio-preset-corporate"],
  "settings": { "theme": { "accent": "violet" } }
}

Need to add the theme later? action: "update" merges top-level keys into an existing site config without touching unrelated entries.

If no Site Set/theme/site package is available and there is no root sys_template, CreateSite creates a minimal site-level setup.typoscript fallback in TYPO3's active site configuration path, so a newly added website can still render content immediately.

Translating a page in one call

Translations are visible by default (hidden=0). Pass hidden: true to keep them in review. Inline children are auto-localized by TYPO3 unless you opt out with translateChildren: false.

WriteTable {
  "action": "translate",
  "table": "pages",
  "uid": 474,
  "data": { "sys_language_uid": "hu", "title": "Esemény", "slug": "/esemeny" }
}
// → { "translationUid": 1234, "targetLanguage": "hu",
//     "siteIdentifier": "launch-2026", "slug": "/esemeny", "hidden": false }

Core guarantees

Workspace transparency — record-backed writes stage in a TYPO3 workspace by default. MCP clients see stable live UIDs; the workspace context is selected or created automatically. Live writes require explicit workspace_id: 0 and local mode.
TCA-first — tool schemas come from TCA, not from handwritten adapters. Field labels, permissions, palettes, FlexForms, and third-party extensions like georgringer/news work out of the box.
Language-aware — translation parameters only appear when the site has more than one language. ISO codes (de, fr) are accepted.
File sandbox — file tools are restricted to fileadmin/mcp/ by default. Physical files are not workspace-versioned; only file references are.
Dry-run by default — PublishWorkspace and RollbackWorkspace show what would happen unless dryRun: false.
Capability-manifest enforcement — every tool declares its required subsystems (database:write, file:write, render:frontend, …). Removing a subsystem from Configuration/Capabilities.yaml disables every tool that needs it. Outbound HTTP defaults to self only.

CLI: every tool, every shell

Every MCP tool is available from the TYPO3 CLI, so the same surface is available to shell scripts, CI pipelines, and ddev exec. Three output modes:

# Pretty (humans):
ddev exec ./vendor/bin/typo3 mcp:read-table --table tt_content --pid 1

# Plain text only (logs, redirects):
ddev exec ./vendor/bin/typo3 mcp:read-table --table tt_content --pid 1 --plain
ddev exec ./vendor/bin/typo3 mcp:read-table --table tt_content --pid 1 --no-ansi

# JSON envelope `{ok, result}` (jq, agents, CI):
ddev exec ./vendor/bin/typo3 mcp:read-table --table tt_content --pid 1 --json | jq '.result'

Every tool also accepts --param key=value (repeatable) and --params <json> for arbitrary input. Use --param data=@payload.json to read JSON from a file (constrained to the project root for safety).

ddev exec ./vendor/bin/typo3 mcp:tool:list             # discover tools
ddev exec ./vendor/bin/typo3 mcp:tool:list --schema=ReadTable
ddev exec ./vendor/bin/typo3 mcp:tool ReadTable --param table=pages --json
ddev exec ./vendor/bin/typo3 mcp:get-capabilities --json

The shipped mcp:<tool-name> shortcuts cover the complete bundled tool surface, including generic shortcuts backed by GenericMcpToolCommand. mcp:tool <Name> remains the universal runner for any registered tool, including tools contributed by third-party extensions. Adding a new shortcut usually means adding a GenericMcpToolCommand service entry; use a custom AbstractMcpToolCommand subclass only when the command needs bespoke options or formatting.

Capability manifest (security model)

The MCP server ships Configuration/Capabilities.yaml that declares which subsystems each tool needs. Inspired by Capability Manifests for TYPO3 extensions.

capabilities:
  subsystems:
    - database:read
    - database:write
    - file:write          # delete this line → file-write tools all stop working
    # …
  network:
    outbound:
      - self              # only this site by default
      # - '*'             # uncomment to allow public web (still blocks private IPs)
  tools:
    WriteTable:        [database:write]
    UploadFileFromUrl: [file:write]
    RenderRecord:      [database:read, render:frontend]
    # …

Enforcement points:

AbstractTool::execute() — refuses to run a tool whose required subsystems (or any of their requires: prerequisites) are not declared. Removing database:write cascades into disabling every file:write/workspace:write/site:write tool too.
UploadFileFromUrlTool and RenderRecordTool — refuse outbound requests to hosts not in network.outbound (the IP-range SSRF check still applies on top).

To loosen the policy: edit the YAML or unset enforceCapabilityManifest in extension settings. To check what's active right now:

ddev exec ./vendor/bin/typo3 mcp:get-capabilities --json

DDEV / local-development mode

By default, MCP enforces two safety nets that are inconvenient on a developer's laptop:

All record writes are staged in a workspace (no live edits).
File operations are jailed to fileadmin/mcp/.

When the server detects a DDEV environment (via IS_DDEV_PROJECT, DDEV_PROJECT, DDEV_HOSTNAME, or DDEV_TLD) or when TYPO3 runs in the Development/... application context, the safety nets relax:

Record tools default to the live workspace when workspace_id is omitted (edit published content directly). Pass an explicit draft workspace_id to stage changes locally.
WriteTable also accepts workspace_id: 0 explicitly.
BrowseFiles, WriteFile, UploadFile accept any storage / path.
File-sandbox boundary checks are bypassed (path-traversal protection still applies).
The capability manifest's network.outbound: [self] gate is bypassed — UploadFileFromUrl and RenderRecord accept any remote host. The SSRF private-IP filter is also lifted so DDEV's *.ddev.site (which resolves to 127.0.0.1) and local NAS / staging hosts work out of the box.

Override via extension setting localUnsafeMode:

Value	Behavior
`auto`	(default) on if DDEV or Development context detected, off otherwise
`on`	always relaxed — only set in trusted local environments
`off`	always strict — production-safe

The same mode can be set per backend user or group via User TSconfig, which allows TYPO3 conditions (recommended for opt-out on DDEV):

[applicationContext == "Development/DDEV" && backend.user.groupList contains "integrators"]
options.mcpServer.localUnsafeMode = on
[else]
options.mcpServer.localUnsafeMode = off
[end]

When localUnsafeMode resolves to off, MCP uses draft workspaces even on DDEV.

MCP live vs draft — decision tree

Entry points (HTTP OAuth, Cursor stdio, CLI), hosting context (DDEV, Development, production, staging), and where chatbot edits land:

flowchart TB
    subgraph EP["① MCP entry points"]
        HTTP["Remote HTTP /mcp<br/>OAuth token → real backend user"]
        STDIO["Local stdio<br/>Cursor Install → ddev exec mcp:server"]
        CLI["TYPO3 CLI<br/>vendor/bin/typo3 mcp:…"]
    end

    subgraph ENV["② Hosting context examples"]
        DDEV["DDEV<br/>IS_DDEV_PROJECT, …"]
        DEVCTX["Development context<br/>TYPO3_CONTEXT=Development/…"]
        PROD["Production<br/>Production context, no DDEV vars"]
        STAGE["Staging / demo<br/>same rules as PROD unless overridden"]
    end

    EP --> CTX["Backend user + workspace context"]
    HTTP --> REAL["Token owner: permissions + User TSconfig apply"]
    STDIO --> SYNTH["Synthetic admin uid 1<br/>extension / auto policy mainly"]

    CTX --> POLICY

    subgraph POLICY["③ LocalModeService — local mode on?"]
        SB{"strictSandbox = 1?<br/>feature flag or User TSconfig"}
        SB -- strict --> OFF["local mode OFF<br/>allows_live_writes: false"]
        SB -- not strict --> CFG{"localUnsafeMode<br/>User TSconfig overrides extension"}
        CFG -- on --> ON["local mode ON<br/>allows_live_writes: true"]
        CFG -- off --> OFF
        CFG -- auto --> AUTO{"DDEV env vars<br/>OR Development context?"}
        AUTO -- detected --> ON
        AUTO -- not detected --> OFF
    end

    POLICY --> WS

    subgraph WS["④ Default workspace when chatbot omits workspace_id"]
        CUR{"User already in<br/>draft workspace?"}
        CUR -- yes --> DRAFT["Draft workspace<br/>staged changes"]
        CUR -- no --> ALLOW{"allows_live_writes?"}
        ALLOW -- yes --> LIVE["Live workspace 0<br/>published content"]
        ALLOW -- no --> PICK["Pick or create<br/>MCP draft workspace"]
    end

    EX["Explicit workspace_id in tool call"] --> EX0{"workspace_id = 0?"}
    EX0 -- "0 + allowed" --> LIVE
    EX0 -- "0 + denied" --> DENY["AccessDenied:<br/>live workspace"]
    EX0 -- "draft id > 0" --> DRAFT

    DDEV -.-> AUTO
    DEVCTX -.-> AUTO
    PROD -.-> AUTO
    STAGE -.-> CFG

Full plain-language guide: Documentation/Configuration/LiveEditsOnDevelopment.rst.

To force the production safety nets even in DDEV, set either the TYPO3 feature flag $GLOBALS['TYPO3_CONF_VARS']['SYS']['features']['mcpServer.strictSandbox'] or User TSconfig:

options.mcpServer.strictSandbox = 1

Strict sandbox mode means file tools stay inside the configured MCP file sandbox and record writes stay in TYPO3 workspaces. Local mode additionally removes the workspace-capable table requirement so local-only tools can write non-workspace tables with the current backend user's normal permissions.

OAuth, backend-user permission checks, and per-tool subsystem checks from Configuration/Capabilities.yaml remain enforced. Local mode relaxes the workspace-staging, non-workspace-table, file-sandbox, and outbound-network safety nets; it does not turn the MCP endpoint into an unauthenticated or ungated shell.

Authentication and clients

Two connection models:

Remote HTTP at /mcp, protected by OAuth 2.1 + PKCE. Recommended for clients that cannot start a local process: Claude Desktop, n8n, Manus, MCP Inspector.
Local stdio via vendor/bin/typo3 mcp:server. Recommended for Cursor during local development. It runs as your OS user; TYPO3 gates CMS operations but does not contain the host. Use stdio with trusted local clients only.

The User → MCP Server backend module handles token creation, per-client instructions, and endpoint health checks.

Remote MCP requests stay stateless from the editor's point of view. The extension creates an anonymous in-memory backend user session for the lifetime of the request so TYPO3 internals that expect session state during DataHandler writes keep working, without creating a persistent backend login.

Configuration

All settings live in Extension Configuration → mcp_server.

Key	Default	Purpose
`additionalReadOnlyTables`	`sys_file`	Comma-separated non-workspace tables exposed for reads only
`additionalStandaloneTables`	`sys_file_metadata`	Hidden TCA tables exposed as standalone read targets instead of embedded child-only tables
`fileSandboxRoot`	`1:/mcp/`	FAL folder root where file tools operate
`workspaceUploadSubfolders`	`1`	Route uploads into workspace-specific folders
`allowMcpTokenInQueryString`	`0`	Allow `?token=…` on `/mcp` (legacy clients only, logging risk)
`enableMcpAuthHeaderDiagnostic`	`0`	Enable minimal `?test=auth` diagnostic on `/mcp` (off-by-default since 2026-05)
`localUnsafeMode`	`auto`	DDEV/Development -> live writes, unrestricted file/outbound access, and dev-site tools. `on`/`off`/`auto`; can be overridden by User TSconfig.
`enforceCapabilityManifest`	`1`	Reject tools whose required subsystems aren't declared in `Capabilities.yaml`

See Documentation/Configuration/Index.rst for details and security recommendations.

Development

ddev exec composer test            # unit + functional suites
ddev exec composer test:llm        # LLM-assisted ergonomics tests (needs OPENROUTER_API_KEY)
ddev exec composer phpstan         # PHPStan level max + saschaegerer/phpstan-typo3
                                   # + phpstan-strict-rules + phpstan-deprecation-rules
ddev exec composer php-cs-fixer:fix
ddev exec composer rector          # PHP migrations dry-run
ddev exec composer fractor         # non-PHP (FlexForm/TypoScript/Fluid) dry-run
ddev exec composer docs:check      # RST render check (uses Docker)

CI matrix runs PHP 8.2 / 8.3 / 8.4 / 8.5 × TYPO3 ^14.0 on every push.

E2E (Playwright) — spins up MySQL, TYPO3, Playwright in Docker:

Build/runTests.sh -s e2e
Build/runTests.sh -s e2e --no-docker      # host PHP + SQLite + local Playwright
TYPO3_BASE_URL=https://my.ddev.site Build/runTests.sh -s e2e
Build/runTests.sh -h                      # all options

Syncing with upstream

This fork tracks hauptsacheNet/typo3-mcp-server. To pull in new upstream changes:

git fetch upstream
git merge upstream/main
ddev exec composer php-cs-fixer:fix && ddev exec composer phpstan && ddev exec composer test

Resolve conflicts by keeping TYPO3 v14 patterns (final class, constructor DI, getToolSchema()).

Repository layout

Classes/
  MCP/         MCP server, tool registry, tool implementations
  Service/     workspace, TCA, language, file sandbox, OAuth, capability manifest, local mode
  Http/        /mcp endpoint + OAuth/discovery endpoints
  Controller/  backend module controller
  Command/     CLI commands (mcp:server, mcp:tool, per-tool shortcuts)
Configuration/
  Capabilities.yaml   declared subsystems + per-tool requirements + outbound policy
  Services.yaml       DI + console.command + event listener registration
  Commands.php        legacy/explicit command map for selected shortcuts
Documentation/        reStructuredText manual (published source)
Resources/            templates, CSS/JS, XLIFF labels (en + de)
Tests/                unit, functional, LLM, architecture, E2E

Documentation

Canonical manual under Documentation/ in reStructuredText. Suggested reading order:

Topic	Entry point
Overview & safety model	`Introduction/Index.rst`
Detailed fork changes	`Introduction/ForkChanges.rst`
What the tools promise	`Introduction/IntendedBehavior.rst`
Install & activate	`Installation/Index.rst`
Module, OAuth, sandbox, manifest, local mode	`Configuration/Index.rst`
Full MCP tool reference	`Tools/Index.rst`
Architecture deep-dives	`Architecture/Index.rst`
Security audit	`Architecture/SecurityAudit.rst`
Testing with Cursor	`Testing/CursorTesting.md`
Full-feature chatbot script	`Testing/FullFeatureChatbotScript.md`
E2E test suite	`Testing/E2eSuite.rst`
Troubleshooting	`Troubleshooting/Index.rst`

Long-form design rationale and real-world scenarios: TECHNICAL_OVERVIEW.md.

New dedicated CLI shortcuts can be added through GenericMcpToolCommand service entries in Configuration/Services.yaml; use a custom command class only when a shortcut needs specialized behavior.

Acknowledgements

Thank you to hauptsacheNet and Marco Pfeiffer for open-sourcing the original TYPO3 MCP Server: a strong, editor-first, workspace-safe foundation that this project builds on. The capability-manifest concept is adapted from Kurt Dirnbauer's TYPO3-extension-security article.

License

GPL-2.0-or-later

Name		Name	Last commit message	Last commit date
Latest commit History 173 Commits
.claude/skills		.claude/skills
.cursor/rules		.cursor/rules
.ddev		.ddev
.github/workflows		.github/workflows
Build		Build
Classes		Classes
Configuration		Configuration
Documentation		Documentation
Resources		Resources
Tests		Tests
.gitignore		.gitignore
.php-cs-fixer.dist.php		.php-cs-fixer.dist.php
AGENTS.md		AGENTS.md
CHANGELOG.md		CHANGELOG.md
CLAUDE.md		CLAUDE.md
LICENSE		LICENSE
README.md		README.md
TECHNICAL_OVERVIEW.md		TECHNICAL_OVERVIEW.md
composer.json		composer.json
composer.lock		composer.lock
ext_conf_template.txt		ext_conf_template.txt
ext_emconf.php		ext_emconf.php
ext_localconf.php		ext_localconf.php
ext_tables.sql		ext_tables.sql
fractor.php		fractor.php
mcp_setup.png		mcp_setup.png
phpstan-baseline.neon		phpstan-baseline.neon
phpstan.neon		phpstan.neon
phpunit.xml.dist		phpunit.xml.dist
rector.php		rector.php

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Repository files navigation

TYPO3 MCP Server

Continuously Tested With Real LLMs

In 60 seconds

Table of contents

Quick start

1. Install

2. Open the backend module

3. Connect a client

What changed in this fork

Example session

Capabilities at a glance

Frontend design-system tooling

Dev-site tools (DDEV / local development)

Adding a site configuration

Translating a page in one call

Core guarantees

CLI: every tool, every shell

Capability manifest (security model)

DDEV / local-development mode

MCP live vs draft — decision tree

Authentication and clients

Configuration

Development

Syncing with upstream

Repository layout

Documentation

Acknowledgements

License

About

Uh oh!

Releases

Packages

Uh oh!

Contributors

Uh oh!

Languages

Folders and files

Latest commit

History

Repository files navigation

TYPO3 MCP Server

Continuously Tested With Real LLMs

In 60 seconds

Table of contents

Quick start

1. Install

2. Open the backend module

3. Connect a client

What changed in this fork

Example session

Capabilities at a glance

Frontend design-system tooling

Dev-site tools (DDEV / local development)

Adding a site configuration

Translating a page in one call

Core guarantees

CLI: every tool, every shell

Capability manifest (security model)

DDEV / local-development mode

MCP live vs draft — decision tree

Authentication and clients

Configuration

Development

Syncing with upstream

Repository layout

Documentation

Acknowledgements

License

About

Resources

License

Uh oh!

Stars

Watchers

Forks

Releases

Packages 0

Uh oh!

Contributors

Uh oh!

Languages

Packages