Skip to main content
Glama
Sign In

GoodSender

by io.github.good-sender
OverviewDiscussionsAdmin

Enqueue Template Email

enqueue_template_email
Destructive

Enqueue a template-based email to be sent.

Emails to recipients who have already granted consent are sent right away. For every other recipient the email is queued, and a consent request is sent now if the recipient has none yet. New recipients are auto-registered and sent the consent request during this call. A queued email is sent once its recipient has granted consent and consent state is next refreshed: by 'send_pending_emails', or by a later call to another tool that sends email. Nothing is sent while the server is idle.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "TemplateName": "<TemplateName>",
      "TemplateData": "<TemplateData>"
    },
    "name": "enqueue_template_email"
  }
}

Input Schema

NameRequiredDescriptionDefault
TemplateDataYesData to populate template variables.
TemplateNameYesName of the template to use. Must exist already.

Output Schema

NameRequiredDescriptionDefault
ResultYesHow many emails were queued, and of those how many were released for sending now, wait for recipient consent, or are not sent because the recipient denied consent.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / properties / Result / description
      Previous value: -"Result of the operation."New value: +"How many emails were queued, and of those how many were released for sending now, wait for recipient consent, or are not sent because the recipient denied consent."
  2. First observed

TDQS

A4/5.0
Behavior5/5

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

Even against annotations that already mark this non-read-only, open-world, non-idempotent and destructive, the description adds substantial context: immediate send for consented recipients, queuing otherwise, consent-request dispatch, and auto-registration of new recipients as a side effect. It also discloses the timing model – queued mail only flushes on send_pending_emails or a later sending call, never while the server is idle. This is exactly the behavioral detail annotations cannot express.

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 one-line purpose is front-loaded, followed by short paragraphs on the immediate-send path, the queue/consent path, and the flush timing. Every sentence carries distinct information; only the final sentence about the idle server is arguably redundant with the preceding one, keeping it just short of a 5.

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?

With an output schema present and full parameter documentation, the description only needs to cover behavior and side effects, which it does thoroughly: consent check, queuing, auto-registration, and dispatch triggers. An agent has everything needed to call this correctly and predict what happens next.

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

Parameters3/5

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

Schema coverage is 100% and both parameters are documented there, including that the template "must exist already" and that TemplateData populates template variables. The description adds no naming, format, or validation guidance beyond what the schema already provides, so the baseline of 3 applies.

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

Purpose4/5

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

The description states a specific verb and resource ("Enqueue a template-based email") and the template-based constraint implicitly separates it from enqueue_email and send_consentless_email. It never names a sibling explicitly, so there is no direct differentiation statement, but an agent can identify the operation 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 Guidelines3/5

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

It explains the consent-gated flow, so an agent can infer that this tool handles consent properly while send_consentless_email bypasses it. However, it never explicitly says when to use this versus enqueue_email or send_consentless_email, and no prerequisites or exclusions are stated. The usage guidance is implied rather than declared.

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

All GoodSender toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources