HTML Email Playbook
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_categoriesA | List all rule categories in the Email Playbook with a one-line description and page count. Categories are: structure (head/body container/header/body/footer), compatibility (Outlook MSO, RTL, responsive), production (Gmail clipping, dark mode, preheader, bulletproof buttons), ai-generation (constraints for AI emitters). For reusable components, use list_components instead — they live in a separate dimension and are not returned by get_playbook_rules. |
| get_playbook_rulesA | Return the full rule pages for a given category. Each rule includes the title, description, markdown body explaining the rule, and any HTML/CSS code examples from the playbook. Use this to teach a model the exact patterns for a specific concern (e.g., responsive layout). |
| list_componentsA | List all reusable email components in the playbook with their metadata: name, subcategory (layout/media/interactive/text), description, whether they require Outlook VML, and whether they are responsive. Use this first to discover what components exist before calling get_component. |
| get_componentA | Return the full record for a single component: title, description, narrative body, the primary HTML pattern, list of slots (placeholders the model should fill), VML/responsive flags, and all code examples. Use after list_components to fetch the actual HTML pattern to paste into an email. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
Each tool serves a distinct, well-defined purpose: listing categories, listing components, fetching component details, and fetching rule pages. No two tools overlap in functionality.
All tools follow a consistent verb_noun pattern using snake_case: 'list' for enumeration and 'get' for retrieval. The naming is predictable and easily distinguishable.
With only 4 tools, the server is tightly scoped to browsing and retrieving email playbook content. This count is ideal for the domain—neither too few nor excessive.
The tools cover listing and retrieval of both components and rule categories. A minor gap is the lack of a tool to list all individual rules without specifying a category, but the existing tools enable complete navigation of the playbook.