Libraries and templates
A library is a brand's governed kit of modules, settings and rules. A template is an approved starting layout inside it. Every email built through the MCP starts from one.
Libraries
A library holds everything one brand, region or team is allowed to build with: its modules, the settings each email may use, styling variations, languages, tags, tracking rules and connected integrations. People only see libraries their permissions include.
When your assistant calls stensul-get-libraries with a library key, it learns:
| It learns | Why it matters |
|---|---|
| The modules, by role, and which variations each supports | What it can place in an email |
subject_line_enabled, preheader_enabled, title_enabled and their length caps |
Which settings it may send. Sending a disabled one gets the whole call declined |
The variations mode (all or individual) |
Whether styling applies to the whole email or per module |
dca_segment_sets.supported |
Whether audience versions work in this library |
| Languages and tags | Valid values for new emails |
Name libraries descriptively. Assistants match your brief to library names. “EMEA Retail – German” beats “Lib 7”.
Templates
A template is an approved email layout: a fixed sequence of modules with starter content. Admins make templates in Stensul; the MCP can’t create one from scratch. An email saved as a template can be copied to start new emails, but never becomes a sendable email itself.
Two ways to start an email
Template ──(template_id)──▶ new draft with the template's module order
Existing email ──(copy_of)──▶ new draft with its content and imagesstensul-build-email takes exactly one of template_id or copy_of, then writes content by position against a read of that source: module 1 is the first module, element 2 is the second element in it. That’s why a good assistant reads the source with stensul-read-email first.
If a library has no template and no email to copy, there’s nothing to start from, and the assistant should say so rather than improvise.