Available Tools

The TYPO3 AI Suite MCP server currently provides 45 tools. Each tool belongs to exactly one OAuth scope, and a scope is only granted if the user's backend group has the appropriate AI Suite feature rights (see Permissions & Scopes). The tool list that a model sees is therefore different for each user. If a right is missing, the affected tool does not appear at all.

The following overview is grouped by scopes and briefly states the purpose of each tool. The complete parameters are provided by each client itself, as they are part of the tool definition in JSON schema. Which tools a specific installation actually delivers is revealed by readServerInfo.

Since version 0.7.0, every call that touched records also returns those records as backend links. They arrive through two channels: as structuredContent.links for clients that render links themselves, and as a “⚙ Open in TYPO3” text block at the end of the result, which is what makes them clickable in a chat. The label is the record's own title where it has one.

Links are grouped by table, because a page and the content elements on it are different destinations. pages comes first, the remaining tables follow in the order they were touched. The cap of six links applies per group, so a written page is never pushed out by the content elements written onto it. The omitted field reports per group how many links the cap dropped, so a truncated group cannot be mistaken for a complete one.

The addresses are absolute and deliberately carry no route token. A token belongs to the session that generated it, which is the MCP session and not the editor's browser, so it would be worthless in a link that leaves the process. TYPO3 answers a tokenless backend address with a redirect through the login that carries the original target, so anyone with a live backend session lands directly on the record.

Where scheme and host come from is decided in this order: first the mcpBackendBaseUrl setting, then the current request, finally the site configuration. If none of them yields a complete address, for example with the stdio transport and no configured site, the AI Suite MCP drops the link rather than emitting a broken one, and notes it in aisuite_mcp_warnings.log.

These tools only read. They do not cost any credits and do not call an AI model.

The exploratory tools of this group belong to mcp:read, the writing ones to mcp:write. All write operations go through the DataHandler and thus through the usual TYPO3 checks, and they follow the set write mode.

Since version 0.7.0, an entry in writeRecords may carry a translations object next to fields, keyed by ISO language code. Record and translations are then created in a single call.

{
  "records": [{
    "table": "tt_content",
    "pid": 354,
    "fields": { "CType": "text", "header": "Einstellungen" },
    "translations": { "en": { "header": "Settings" } }
  }]
}

The translation shell is created with TYPO3's own localize command, the same path the backend takes. The language field, the translation parent, l10n_source, l10n_state, excluded fields and existing inline children are therefore handled by the TYPO3 core. The given fields are then written into that shell. It is created hidden, exactly as TYPO3 does it.

Sending the same call a second time updates the existing translation instead of creating a second one, so re-sending a batch after a partial failure is safe. translations also works on an entry carrying a uid, in which case that record is the origin. Nested inline children cannot be translated in the same call. Write them first, then translate them by their UID.

Two spellings collide here for historical TYPO3 reasons. tt_content kept the legacy l18n_parent, while pages and most hand-written child tables use l10n_parent. Since version 0.7.0 the AI Suite MCP accepts both spellings on read and on write and maps them onto whatever the table really calls the field. The same goes for l10n_source and l18n_source. The result notes when such a rename happened. A field name the table genuinely has is never rewritten.

These tools call the providers and models of the AI Suite and then consume credits. Which models are available is determined by the AI Suite configuration and the model rights of the backend group. No additional settings are required in the MCP for this.

They are therefore the only tools that require a valid API key from the AI Suite. If it is missing or the license package does not cover the function, the tools remain in the tool list and are also called by the model. The call then ends with a license error. This distinguishes them from the feature rights of the backend group, which can already remove a tool from the list.

Since version 0.7.0 this applies to translateRecord and translatePage only when you pass the optional model parameter. Leave it out and the tool creates the translation record and hands you its fields, together with the site glossary and the global instructions. Your client's model then does the translating, nothing goes to the AI Suite Server and no credits are spent. The answer also names the models available to you, in case you do want the server to translate after all. If fields come back unchanged, the result says so, to keep a missing translation from going unnoticed.

This is different from localizeRecord under mcp:write. That one only creates the empty translation shell. translateRecord without model creates the shell and additionally hands you the field values to translate.

translateFileMetadata and the batch tools have no such path. Without model they only return the list of available models; the translation itself always runs on the server there and costs credits.

Plain language and the DeepL glossary of the site are not a separate tool, but part of the translation tools. The glossary is applied automatically.

This tool brings existing files into the file management without involving an AI model. It does not cost any credits and works even without a valid API key from the AI Suite. It is tied to its own scope and its own feature right, both turned off by default, because it is the only tool besides generateImage that creates a physical file and therefore cannot be reverted through a workspace.

Not to be confused with copyMediaReference and replaceMediaReference. The two do not insert a new file but transform existing file references, thus belonging to mcp:write and being part of the record group. For target folder, size limit, allowed file extensions, and securing remote downloads, see Security & Operation.

Batch tools run asynchronously. They immediately return a task ID, the progress is queried with readTaskStatus, and the results are read with readTaskResults. Nothing is written automatically. A batch generates suggestions, and only applyTaskResults writes them into the records.

batchGenerateMetadata takes its targets in exactly one of two ways. Either pageIds as an explicit UID list or rootPageId as a page along with everything underneath. Both together is an error, and neither of them alone is. recursive decides whether a rootPageId traverses the entire subtree or stays with the direct children. The root page is always included.

Since version 0.8.0 the server provides seven tools for audits. Towards TYPO3 they only read, but they pass the page URL and thereby the page content on to the AutoDudes audit infrastructure. All seven therefore additionally depend on their own permission enable_audit, see Permissions & Scopes.

The six auditing tools expect an absolute, publicly reachable http(s) address in url. TYPO3-internal links such as t3://page?uid=1 cannot be audited, the public URL has to be resolved beforehand. A keyword is limited to 200 characters.

The four analysis tools auditQuestions, auditContentGap, auditTopicCluster and auditCompetitors take three further parameters in common:

readAuditResults works via pageId instead, optionally narrowed down with auditType and language. Stored results are kept separately per language.