This server has a remotely hosted endpoint. Open its connector listing for connection details, authentication requirements, and setup instructions:
Source for docs.osamahassouna.com — an engineering reference hub I keep open while building. Currently one guide is live, with more landing as I write them.
A working reference for hand-building HTML email templates that render reliably across Outlook (Windows desktop, 2007 through 365), Gmail web + mobile, Apple Mail, Yahoo Mail, and the long tail of clients that haven't moved past 2007.
Covers:
Structure — doctype, head boilerplate, body container, header / body / footer organization
Components — bulletproof CTA buttons (with Outlook VML fallback), spacing patterns, images, inline icons, background images, text
Compatibility — Outlook MSO conditional comments, RTL languages, hybrid responsive layouts
Production — Gmail 102KB clipping, dark mode, preheader text
AI Generation — rules and patterns for AI tools that generate playbook-compliant email HTML
Read it: docs.osamahassouna.com/email-playbook/
There's also a Playground at /email-playbook/playground/ with a live editor, instant preview, and a "From Image" tab that converts a design screenshot into playbook-compliant HTML.
Related MCP server: Temway MCP Server
The playbook is published as an MCP server + terminal CLI so AI clients (Claude Desktop, Cursor, Cline, etc.) can pull rules and component patterns directly into their reasoning. The model calls structured tools to fetch the exact patterns from the playbook instead of guessing from training data.
npm install -g email-playbook-mcpSetup, tool reference, and Claude Desktop / Cursor config snippets:
docs.osamahassouna.com/email-playbook/mcp/
There's also a hosted JSON-RPC endpoint at docs.osamahassouna.com/api/mcp if you'd rather not install anything.
MIT. Playbook content © Osama Hassouna · osamahassouna.com
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.
Inputs: name (required).
Return rule pages. format "checklist": each page as its slug, title, description and a short list of the rules to follow, without the body or code; leave out category to get every page in one call (about 16 KB). format "full" (default, needs a category): each page with title, description, checklist, markdown body and all HTML/CSS code examples. Start with the checklists, then fetch the pages you need with get_rule. Components are not included: use list_components / get_component.
Inputs: format, category.
Return one rule page: slug, category, title, description, checklist, and the markdown body, which includes the page's HTML/CSS code. Accepts the full slug (e.g. "compatibility/responsive"), just the page name ("responsive"), or a page link from a body ("/email-playbook/compatibility/responsive/"). Get the slugs from list_categories. Much smaller than fetching the whole category with get_playbook_rules.
Inputs: slug (required), include_examples.
List all rule categories in the Email Playbook with a one-line description, page count, and the slug and title of each page in it. 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). Pass a page slug to get_rule to fetch just that page. For reusable components, use list_components instead — they live in a separate dimension and are not returned by get_playbook_rules.
Inputs: no named parameters.
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.
Inputs: no named parameters.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
Scored across 5 tools
get_playbook_rules and get_rule both return rule pages, which could cause confusion, but the descriptions clearly differentiate (bulk/checklist vs single full page). list_categories and get_playbook_rules also overlap in returning rule metadata, but the separation of rules vs components is well-articulated.
Consistent list_/get_ verb prefixes throughout (list_categories, list_components, get_rule, get_component, get_playbook_rules). Minor noun inconsistency between 'rule' and 'playbook_rules' is the only deviation, still readable and predictable.
Five tools is well-scoped for a read-only reference/playbook server, with a clean 2x2 structure of listing and fetching rules and components, plus category listing. Each tool earns its place.
The surface covers discovery and retrieval for both rule pages and components, which is the core lifecycle for a documentation server. A search tool or a way to fetch multiple specific rules by slug could improve it, but core workflows are fully served.
Design on-brand emails with your AI, preview them in chat, and send through server-side guardrails.
Audit and build email signatures that survive Gmail, Outlook desktop and Apple Mail.
Analyze, audit, fix and diff HTML, MJML, Maizzle and React Email across 21 email clients.
Build responsive HTML email campaigns from any brand website: design, QA, export.
