[Feature Request] System Inspection Tools for TYPO3 Upgrade Support

[dkd-schmal]

Summary

Add a set of read-only system inspection tools to the MCP server to support AI-assisted TYPO3 upgrade analysis and pre-flight checks.

Motivation / Use Case

The MCP server currently focuses on content management (pages, records, translations) — which works great. However, when using an AI assistant to support a TYPO3 upgrade (e.g., v11 → v12, v12 → v13), critical system information is not accessible via MCP.

Today, the AI can inspect content but cannot answer questions like:

• Which TYPO3 version is this instance running?
• Which PHP version is in use?
• Which extensions are installed, in which versions, and from which source (Composer / TER / local)?
• Are there deprecation warnings in the logs?
• Are there orphaned tables or deprecated TCA fields?

Without this data, the AI cannot provide meaningful upgrade guidance (compatibility checks, migration paths, risk assessment).

Proposed Tools (read-only)

Tool	Purpose
GetTypo3Version	Return core version, branch, LTS status
GetPhpVersion	Return PHP version + relevant extensions (intl, gd, etc.)
ListInstalledExtensions	List active/inactive extensions incl. version, composer name, source
GetComposerStatus	Expose relevant parts of composer.json / composer.lock
ReadDeprecationLog	Read TYPO3 deprecation log (tail / filter)
AnalyzeSchema	Detect orphaned tables, missing fields, schema drift
GetSiteConfiguration	Read site configuration YAML (read-only)

All tools should be strictly read-only and — where possible — respect existing permission checks (admin vs. editor).

Benefits

• Enables AI-assisted upgrade analysis (e.g. "Extension X only supports TYPO3 v12, here's the migration path")
• Complements the existing content-focused toolset without breaking its scope
• Useful for health checks and documentation generation beyond upgrades

Scope Considerations

• Should probably be opt-in (separate permission / backend user setting), since system info is more sensitive than content
• Could be a separate tool group (system.*) to keep the content tools clean
• No write operations — purely inspection

Related

• Current tools cover content only (see README "Project Status" table)
• This feature would extend the use case from "AI content editor" to "AI upgrade assistant"

Happy to discuss scope / contribute if there's interest.

[Nemo64]

I don't really see a use case for this.

If you are upgrading a TYPO3 instance, then you are likely using a coding agent that already has access to the project. And that means, it can already run shell commands like these:

> vendor/bin/typo3 --version
TYPO3 CMS 13.4.25 (Application Context: Production)

Runtime: PHP 8.4.18 - TYPO3 Console 8.3.1

> vendor/bin/typo3 extension:list

All installed (= active) extensions
===================================

+--------------------------------+----------------------+----------+--------+
| Extension Key                  | Version              | Type     | Status |
+--------------------------------+----------------------+----------+--------+
| core                           | v13.4.25             | System   | active |
| scheduler                      | v13.4.25             | System   | active |
| extbase                        | v13.4.25             | System   | active |
| fluid                          | v13.4.25             | System   | active |
| install                        | v13.4.25             | System   | active |

So, if your goal is to use a coding tool to upgrade TYPO3, then it can already use Composer, the TYPO3 CLI, or the MySQL CLI.

Adding more tools to your coding agent usually degrades performance more than it helps.

If you want to improve the upgrade process, I would suggest creating a skill, that details how a TYPO3 upgrade works.

This MCP is focused on the use case of content management in production environments, and the communication and OAuth are optimised for it.

[dkd-schmal]

Thanks for the detailed response — that actually helps clarify the scope, and I agree the upgrade-via-coding-agent angle is weak (a coding agent on the project has CLI access anyway).

However, I'd like to reframe the use case, because I think it actually aligns well with your "content management in production" focus:

Real Use Case: Pre-Sales & Account Management via AI Chat

We integrate this MCP into our internal AI chat, used by project managers, account managers, and sales — people who:

• do not have shell/SSH/Composer access to customer instances
• do not use coding agents
• do need to answer questions about customer TYPO3 installations quickly

Typical real-world prompts from our team:

• "List all installed extensions on customer X's instance and attach them to ticket #4711"
• "Which TYPO3 version is running at customer Y? We need it for the upgrade quote."
• "Does customer Z have news and powermail installed, or do we need to scope them in?"
• "Give me a quick overview of this instance for the kickoff meeting"

This is exactly the non-developer, production-environment, OAuth-authenticated scenario your MCP was designed for. The content tools (ReadTable, Search, GetPage) already cover 80% of our needs — the missing 20% is basic instance metadata (TYPO3 version, installed extensions).

Minimal Scope Suggestion

If the full list from my original post feels like scope creep, even just two read-only tools would be a huge win:

• GetTypo3Version → core version + PHP version
• ListInstalledExtensions → extension keys + versions + active status

No deprecation logs, no schema analysis, no site config — just the basics a non-technical user would ask about.

Would that be acceptable? Happy to contribute a PR if there's conceptual agreement.

[Nemo64]

I don't see any harm in exposing the list of installed extensions... although a normal user would usually not see that. I'm not sure yet, let me think about that. I usually prefer to have as few tools as possible.

However, I have a counter suggestion: I don't have it documented, but this MCP here is extendable.

If your use case requires a specific tool, you can easily add it to your site package or your own standalone extension.

You just need to implement this interface here and then let the Symfony service container autowire it:
https://github.com/hauptsacheNet/typo3-mcp-server/blob/main/Classes/MCP/Tool/ToolInterface.php

Every service tagged with the mcp.tool tag is automatically added to the ToolRegistry https://github.com/hauptsacheNet/typo3-mcp-server/blob/main/Classes/MCP/ToolRegistry.php#L22
(I just noticed that I should have namespaced the tag)

I'm not fully against something like a GetSystemReport tool, that exposes version, reporting, extensions, current issues.... kind of like the system reports extensions, which is also extendable without a hard requirement to this mcp extension, which i like. Would that help your use-case already?