MCP configuration tools
The tools behind the configuration door /mcpconfig: the ones an environment is set up with. Products and prices, the front end and the theme, e-mail templates and the booking workflow. A key with scope config opens this door; how to connect is described in Connecting an AI agent to the MCP server. The daily work sits behind a different door — see MCP operations tools.
Plan and apply are two tools
Every writing act here consists of two tools: ..._plan shows what would change and writes nothing, ..._apply carries it out. That is not a formality but the heart of how this door is used safely: you show a plan to somebody who says yes to it, and only then is anything written. They each have their own right, so you can let somebody look without letting them change.
An _apply that finds nothing to change is a success, not an error: if the value already was what was asked for, the answer says nothing changed. A client that lost its answer can therefore simply try again.
Two locks, plus the production lock
Before anything is written here, two locks must be open: one set by the supplier for the whole environment, and one set by the license holder. If either is closed, even the plan is refused — otherwise the door you cannot open would still describe in full detail what is behind it.
On top of that, the heaviest tools face a third condition: on a production environment they do not run at all. Those are the tools with level 2 in the table below — the statuses and the automatic status transitions. Changing those decides which e-mail goes out at which status change, and at the next job run that is real post to real customers. Changing theme CSS is allowed on production: that is visible and reversible.
The tools
| Tools | Read/write | Level | Description |
|---|---|---|---|
| env_describe / config_diff_vs_baseline / recent_changes | read | - | What this environment is, what differs from a fresh installation, and what changed recently |
| object_explain / pricing_explain / availability_why_not_bookable | read | - | An explanation of one product: its settings, how the price is built up, and why it is not bookable on a date |
| object_create / object_update / object_set_periods / object_set_extras / object_set_participants | write | 1 | Create and change products, with their periods, extra options and participant types |
| product_set_active | write | 1 | Switch a product on or off |
| combi_create / combi_update | write | 1 | Compose packages |
| theme_describe / theme_set_variables / theme_set_css / theme_set_logo / theme_rebuild | read/write | 1 | The front-end theme: colours and variables, own CSS, logo, and recompiling |
| brand_set_logo | write | 1 | The corporate logo |
| content_block_describe / content_block_create / content_block_update | read/write | 1 | The blocks a front-end page is built from |
| content_block_delete | write | 1 | Delete a block. Refused while it is still used somewhere: on a page, in a theme, in another block or in a form |
| menu_describe_items / menu_set_items | read/write | 1 | The items of a menu as a list: order, dropdowns, the page an item leads to and the label per language |
| page_describe / page_create / page_update | read/write | 1 | Content pages in the front end |
| page_list / page_check_links | read | - | All content pages, and which internal links in menus, content blocks and the homepage lead nowhere |
| page_delete | write | 1 | Delete a page. Refused when another language version points to it, unless you have that link cleaned up at the same time |
| theme_set_menu | write | 1 | Which menu the header of a theme shows, per language |
| homepage_set | write | 1 | Which page the front end opens when a visitor arrives at the base address |
| template_describe / template_create / template_update / template_section_set | read/write | 1 | E-mail and pdf templates and their header, footer and css parts |
| workflow_describe | read | - | The whole booking workflow in one answer: statuses, manual and automatic transitions, and which template belongs to which transition — including checks on templates nothing points at any more |
| status_set | write | 2 | Change a booking status: whether it occupies a place, and where somebody may move a booking to by hand |
| auto_set / auto_delete | write | 2 | Automatic status transitions: from which status to which, at what moment, and which e-mail or sms goes with it |
| language_list | read | - | The languages of the environment (active, default) and which parts are translatable |
| language_activate | write | 1 | Switch a front-end language on or off; the plan counts what is still empty in that language |
| language_missing_report | read | - | Per part, the texts that are filled in the source language but not yet in the new one, with the source text included |
| translation_get / translation_set | read/write | 1 | Read and store translations, up to 50 at a time, across all translatable parts |
Furnishing the front end
A front end consists of content blocks, pages that show those blocks, a menu, a theme and a homepage. With the tools this goes in the following order: create and fill blocks (content_block_create, content_block_update), turn them into pages (page_create), fill the menu (menu_set_items), link the menu to the theme (theme_set_menu) and choose the homepage (homepage_set). Finally, page_check_links shows whether any links still lead nowhere.
Along the way a number of things are guarded, so that a mistake does not only show up for the visitor:
- The content of a content block is checked before it is saved, the same way as in the editor. Text that would break the page, such as a stray curly brace or an
{if}without{/if}, is refused. Put JavaScript and CSS with curly braces between{literal}and{/literal}. - The menu in the header is chosen per language, and a language without a menu does not fall back to another language. The plan of
theme_set_menunames every active language that has no menu afterwards. - A menu set up for one language only needs labels in that language. A menu for all languages needs a label in every active language.
- The homepage is one setting for all languages. When a visitor switches language, the front end follows the linked language version of that page. The plan of
homepage_setwarns about every active language in which the page has no version. - The link check only looks at links a visitor clicks. JavaScript does not count, even when it contains something like
location.href.
Adding a language
Switching a front-end language on copies nothing. Everything that has no text in that language yet stays empty in the front end: product names, options, statuses, field labels, content blocks, the menu and the pages. Almost nothing falls back to the default language. The language tools turn that manual work into one structured job:
language_activate_planshows how many texts are still empty per part. Only after approval doeslanguage_activate_applyswitch the language on.language_missing_reportgives the work queue: per part, which texts are missing, with the source text included.- The agent translates and
translation_set_planshows per text what would change.translation_set_applystores it.
Three things are always guarded. A text that is already filled is not overwritten unless that is explicitly asked for. Codes such as {NAME} or ##OWNER_ID## and the HTML markup of a text must come back exactly the same after translating. And a text may not be longer than its field allows. A content page in a new language needs its own url; it is not taken over from the original page.
E-mail and pdf templates are not covered here: those are separate documents per language, made with the template tools.
All these tools need the right menu_config_language, plus the right of the screen where the text is normally edited. Someone who may not change the products cannot translate them through AI either.
You ask for the exact, always current list with all input fields using the standard MCP method tools/list on the door itself. What you get back depends on your rights, so a shorter list than this usually means a right is missing.
BETA. This door is new and still being developed. Tool names, input fields and levels may change between releases without a transition period. Use the plan variant before applying anything, and do not yet build a production integration on it that is not allowed to break.
