Skip to main content
Glama

Generate email

generate_email

Render one branded email in a brand kit and save it to the user's files: any email the user describes, from a cold intro or a follow-up to a newsletter, an invitation, a launch note or a receipt. Nothing is sent. Drafts are limited to 20 per day. Templates: 'letter' takes preheader, signoff, footer_note; 'announcement' takes headline (required), preheader, cta_label, cta_url, signoff, footer_note; 'newsletter' takes issue_label, headline (required), preheader, cta_label, cta_url, signoff, footer_note; 'invitation' takes invite_label, event_name (required), when, where, preheader, cta_label, cta_url, signoff, footer_note; 'notification' takes status_label, headline (required), cta_label, cta_url, footer_note; 'onboarding' takes headline (required), preheader, cta_label, cta_url, signoff, footer_note; 'receipt' takes headline (required), order_label, order_date, cta_label, cta_url, footer_note. Pick the template whose shape fits the job and write the subject, props and body yourself in the user's voice; the template is a layout, not a limit on what the email can say. Write the body as markdown (paragraphs, lists, links, tables) or as blocks, never both. header 'band' paints the header in the brand color, 'plain' keeps it white; align is left or center; both default to the template's layout. Leave brand_kit_id out to use the space's default brand. It costs 1 credit, or nothing on a Solo or Pro plan. Returns the artifact id; call draft_email_in_gmail with it. Do not call this again to retry.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
alignNo
propsNoText fields for the template, all strings.
blocksNoThe body as blocks.
headerNo
subjectNoThe subject line.
markdownNoThe body as markdown.
template_idYes
brand_kit_idNoA brand_kit_id from list_brand_kits.
saved_template_idNoA saved_template_id from list_templates; its inputs seed the ones you pass.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added
  2. Removed
  3. Changed1 schema field changed
    • addedInput schema / properties / saved_template_id
      Added value: +{
      +  "description": "A saved_template_id from list_templates; its inputs seed the ones you pass.",
      +  "type": "string"
      +}
  4. Changed1 schema field changed
    • changedInput schema / required
      Previous value: -[
      -  "template_id",
      -  "subject"
      -]New value: +[
      +  "template_id"
      +]
  5. Added

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds substantial behavior beyond the single readOnlyHint=false annotation: nothing is sent, drafts are capped at 20/day, it costs 1 credit (free on Solo/Pro), it returns the artifact id, and retries are discouraged. These are exactly the operational traits an agent needs before invoking a credentialed write.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads purpose, then behavior, then template detail, with zero filler. It is a dense single paragraph, though, and the template enumeration is a long run-on that would scan better as a list; some sentences pack multiple distinct facts.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter mutation tool with nested blocks and no output schema, the description covers the return value (artifact id), cost, rate limit, template selection, body format exclusivity, and the next step. Nothing an agent needs to invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 67%, and the description compensates well: it enumerates which props each template takes (and which are required), states markdown and blocks are mutually exclusive ('never both'), documents header band/plain and align defaults, and explains that omitting brand_kit_id uses the space default. This is meaning well beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb+resource+scope: 'Render one branded email in a brand kit and save it to the user's files.' It distinguishes itself from siblings by stating 'Nothing is sent' and by pointing to draft_email_in_gmail as the send path, so an agent can tell it apart from send_email/create_gmail_draft without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear context for when to use it ('any email the user describes, from a cold intro to a follow-up to a newsletter...') and names the follow-on tool (draft_email_in_gmail) plus a retry exclusion ('Do not call this again to retry'). It does not explicitly contrast against generate_markdown/generate_pdf or state when not to use this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.