Skip to main content
Glama

Generate email

generate_email
Destructive

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

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.6/5.0
Behavior5/5

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

The annotations already declare a non-read-only, destructive operation, and the description adds substantial context beyond them: no email is sent, drafts are capped at 20/day, the call costs 1 credit except on Solo/Pro, and the result is an artifact id. It also warns not to call again to retry, which is valuable operational guidance.

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?

The purpose is front-loaded and most sentences carry necessary template or behavioral detail. The long template enumeration makes it dense and somewhat run-on, but little is pure filler for a tool with seven templates and nine parameters.

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 complex, nested-parameter tool with no output schema, the description covers the important behavioral facts an agent needs: template shapes, body format, defaults, cost/rate limit, return value, and next step. The only minor gap is saved_template_id, which the schema already explains.

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

Parameters4/5

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

Schema coverage is 67%, so the description usefully goes beyond the schema by listing exactly which props each template accepts, the markdown-versus-blocks exclusivity, header/align defaults, and brand_kit_id fallback behavior. It omits saved_template_id semantics, though the schema itself documents that parameter.

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?

The first sentence states a specific verb and resource ('Render one branded email') plus the outcome ('save it to the user's files'), and immediately clarifies it does not send. It distinguishes itself from email-sending siblings by saying 'Nothing is sent' and directing the artifact to draft_email_in_gmail.

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?

It clearly tells the agent to pick a template whose shape fits the job and gives the follow-on action ('call draft_email_in_gmail with it'), plus an explicit retry exclusion. It does not explicitly compare itself to create_gmail_draft or send_email, but the no-send scope and next-step routing cover most selection needs.

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.