Available Tools

The MCP server of the AI Suite currently provides 46 tools. Each tool belongs to exactly one OAuth scope, and a scope with a feature binding is only granted if the user's backend group has the matching AI Suite feature permission (mcp:read and mcp:write have none, see Permissions & Scopes). The tool list a model gets to see therefore differs from user to user. If a permission is missing, the affected tool does not appear at all. On an installation with only one language, the server also hides the translation tools.

The following overview is grouped by scope and briefly states the purpose of each tool. Every client provides the complete parameters itself, because they are part of the tool definition as a 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 the affected records as backend links. They arrive in two ways: as structuredContent.links for clients that render links themselves, and as a “🔗 Open in TYPO3” text block at the end of the result, which makes them clickable in the chat. The record's title serves as the label, if it has one.

The links are grouped by table, because a page and the content elements on it are different targets. pages comes first, followed by the remaining tables in the order in which they were touched. The cap of six links applies per group, so a written page is not pushed out by the content elements created on it. The omitted field states per group how many links the cap left out, so a truncated group cannot be mistaken for a complete one.

The addresses are absolute and deliberately contain no route token. A token belongs to the session that generated it, that is the MCP session and not the editor's browser. In a link that leaves the process, it would be worthless. TYPO3 answers a backend address without a token with a redirect through the login that carries the original target along. Anyone logged in to the backend therefore lands directly on the record.

Since version 0.9.0, the links point to an intermediate page under /aisuite-mcp/open on the backend host, which forwards to the backend from there. Without this detour, a link clicked in an external chat such as Claude.ai or ChatGPT reaches the backend without the editor's session cookie and ends up on the login. The setting mcpBackendLinkBounce (default: on) controls the intermediate page. If it is set to 0, the links point directly to the backend. Links already handed out keep working in both cases.

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

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

The exploring tools of this group belong to mcp:read, the writing ones to mcp:write. All write operations run through the DataHandler and thus through the usual TYPO3 checks, and they follow the configured 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.

With translations, two spellings from TYPO3 history collide. tt_content has kept the old l18n_parent, while pages and most custom child tables use l10n_parent. Since version 0.7.0, AI Suite MCP accepts both variants on read and on write and maps them to the name the table actually uses. The same applies to l10n_source and l18n_source. The result notes when such a rename has taken place. A field name the table really has is never rewritten.

These tools call the providers and models of the AI Suite and then consume credits. Which models are available results from the AI Suite configuration and the model permissions of the backend group. No additional setting is needed in AI Suite MCP for this.

Together with the batch tools and the three checking audit tools, they are the tools that require a valid AI Suite API key. 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 permissions of the backend group, which already remove a tool from the list.

Since version 0.7.0, this applies to translateRecord and translatePage only if you pass the optional parameter model. If you leave it out, the tool creates the translation record and returns its fields to you, together with the site glossary and the global instructions. The translation is then done by your client's model, nothing goes to the AI Suite server and it costs no credits. The answer also names the models available to you, in case you want to translate on the server after all. If fields come back unchanged, the result points this out, so that a missing translation does not go unnoticed.

This is to be distinguished from localizeRecord under mcp:write. That tool only creates the empty translation shell. translateRecord without model creates the shell and additionally hands you the field contents to be translated.

translateFileMetadata and the batch tools do not offer this path. Without model, they only return the list of available models, the actual translation always runs on the server there and costs credits.

The DeepL glossary of the site is not a separate tool but part of the translation tools, and it is applied automatically. Easy language is not available via MCP.

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

With onConflict you define what happens with an existing file name: rename (default) saves under a new name, replace overwrites the content of the existing file, so that all references immediately show the new file. This cannot be reverted through a workspace either. createFolder creates a missing target folder.

Not to be confused with copyMediaReference and replaceMediaReference. These two do not insert a new file but change existing file references, therefore belong to mcp:write and are listed in the records group. For the target folder, size limit, allowed file extensions and the safeguarding of 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. None of this is written automatically. A batch process generates suggestions. Translations are only written into the localization records by applyTaskResults, metadata suggestions you apply with writeRecords.

batchGenerateMetadata and, since version 0.9.0, also batchTranslatePage take their targets in exactly one of two ways: either via pageIds as an explicit UID list or via rootPageId as a page including everything below it. Both together is an error, and so is neither. recursive decides whether a rootPageId traverses the entire subtree or stops at the direct children. The root page is always included.

Since version 0.8.0, the server provides tools around audits, since version 0.9.0 there are four. Towards TYPO3 they only read, but they pass the page URL and thus the page content on to the AutoDudes audit infrastructure. That is why the three checking tools additionally depend on their own permission enable_audit (see Permissions & Scopes). readAuditResults only needs read permission on the page.

Since version 0.9.0, the three checking tools auditSeo, auditAccessibility and auditContent take the page in one of two ways. For a page of this installation, pageId is enough, its public URL is resolved from the site configuration. For a page outside the installation, url takes an absolute, publicly reachable http(s) address. A keyword is limited to 200 characters.

auditContent takes three further parameters:

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