[mcp] no path to author email content: message templates unreachable, and the only writable format is the legacy Content designer

clio 8.1.0.112 · Creatio cloud demo (8.x, .NET Framework host, cliogate NOT installed) ## Summary Task: clone an existing marketing email (`BulkEmail`, authored in the current Beefree-based **Email designer**) into a **Message template** (`EmailTemplate`) on the same environment. clio has no read or write path for email content of any kind: - no tool for `EmailTemplate` (message templates) — `get-page` / `update-page` only cover Freedom UI pages, and message templates are a classic module (`EmailTemplateSectionV2` / `EmailTemplatePageV2`); - no tool for the content itself — neither the legacy Content designer config (`EmailTemplate.TemplateConfig`) nor the current designer storage (`BfEmailTemplate.PageJson` / `PageHtml`); - no guidance article: `get-guidance name=routing` routes pages / entities / data / applications, and `availableGuides` has nothing on email templates, message templates or email content. So the only way to do the task is raw OData writes with a hand-authored `TemplateConfig` JSON — and that JSON is the **legacy** designer's format. Everything clio can produce therefore lands in the old designer; there is no supported way to generate content that opens in the designer the platform actually ships for marketing emails. ## Reproduction 1. `find-entity-schema search-pattern 'EmailTemplate'` → the entity is discoverable, but no tool operates on its content. 2. `get-tool-contract` (index) → no `*email*` / `*template*` content tool. 3. `get-guidance name=routing` → no email/message-template route; an unknown name returns `availableGuides`, which lists none. 4. Everything below had to be reverse-engineered from OOB records via `odata-read`, because nothing documents it: - `EmailTemplate.ConfigType` = 0 (raw HTML body, `IsHtmlBody: true`) vs 1 (designed in Content designer, `IsHtmlBody: false`); - the Content designer vocabulary `sheet > mjblock > section > column > {text | mjimage | mjbutton | mjdivider | spacer | navbar}`, plus `ImageConfig {source, url, imageSrc, name}`; - English content lives on `EmailTemplate`, other languages in `EmailTemplateLang`; - the new designer keeps content in `BfEmailTemplate` keyed by a plain-Guid `EmailId` (`BulkEmail.TemplateBody` / `TemplateConfig` are empty for such emails — a first-time caller reasonably concludes the email has no content). ## Expected Symmetry with the page tooling — something like: - `get-email-template` writing the body/config to files (as `get-page` does), `update-email-template` pushing them back with a checksum guard; - support for the current designer's storage, so generated content opens in that designer rather than the legacy one; - a copy path between hosts (marketing email ↔ message template), which the platform itself has server-side (`BfEmailTemplateExtendedCopyService`, `BFTemplateTransformerService`); - a guidance article covering the above field semantics, so they don't have to be inferred from sample data. ## Observed Task completed only by: `call-service` GET of `BfEmailTemplate` → local transform → `call-service` POST of a full `EmailTemplate` with a hand-built legacy `TemplateConfig` (9 `mjblock`s, 24 `text`, 4 `mjimage`, 2 `mjbutton`). ~3 h of schema archaeology for what is conceptually a copy. ## Impact Any demo/delivery task that involves email content (message templates for processes, transactional emails, cloning a marketing email) is outside clio's reach today, and whatever is built through the OData fallback is stuck in the legacy designer's format.