Skip to main content
Glama
Sign In

GoodSender

by io.github.good-sender
OverviewDiscussionsAdmin

Send Template Draft Test Email

send_template_draft_test_email
Destructive

Enqueue one test email from a draft template (by token) as custom content — not linked to a saved template name.

Rendered subject and body come from the draft; only the given recipient receives the message (template To:/groups ignored for delivery). Consent rules match other enqueue tools: sends immediately if consent is already granted; otherwise it queues and is sent on the next tool call that refreshes consent state after consent is granted.

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": {
      "TemplateToken": "<TemplateToken>",
      "TemplateData": "<TemplateData>",
      "Recipient": "<Recipient>"
    },
    "name": "send_template_draft_test_email"
  }
}

Input Schema

NameRequiredDescriptionDefault
RecipientYesSingle test recipient address. Overrides any To: line in the template.
TemplateDataYesData to populate template variables.
TemplateTokenYesTemplate token from 'create_template_draft' or 'get_template'.

Output Schema

NameRequiredDescriptionDefault
ResultYesResult of the operation.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / Recipient / properties / Address / description
      Added value: +"Email address, e.g. ada@example.com."
    • addedInput schema / properties / Recipient / properties / Name / description
      Added value: +"Optional display name shown with the address, e.g. Ada Lovelace."
  2. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Goes well beyond the annotations by disclosing the consent model: immediate send if consent already exists, otherwise queued until a later tool call refreshes consent state. It also discloses that rendered subject/body come from the draft and that template-level recipients are bypassed for delivery. It does not clarify why destructiveHint is true or what happens on repeated calls, which keeps it from a 5.

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

Conciseness5/5

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

Three short sentences, each carrying distinct information: what it does, what overrides apply, and how consent affects timing. The identifying clause is front-loaded and nothing is redundant.

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

Completeness4/5

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

For a non-idempotent, open-world sending tool, the description covers origin of content, recipient scoping, and send timing, and an output schema exists to cover return values. Only the mutation/duplication semantics behind destructiveHint and idempotentHint=false are left unexplained.

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 description coverage is 100%, so the schema already documents TemplateToken, TemplateData, and the nested Recipient fields. The description only reinforces that the token identifies a draft and that Recipient overrides the template To: line, adding little beyond the structured text. Baseline 3 is appropriate.

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?

States a specific verb and resource ('Enqueue one test email from a draft template (by token)') and immediately scopes it with 'as custom content — not linked to a saved template name', which separates it from enqueue_template_email and save_template. An agent can pick this over its siblings without opening a 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?

Makes the usage context explicit – testing a draft template by token, delivered only to the given recipient, with template To:/groups ignored. It does not name the concrete alternatives (render_template_preview for previewing, enqueue_template_email for named templates), so the routing is implied rather than spelled out.

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