Nextmail

Send with template

sendWithTemplate

Destructive

Send a message built from a stored template. THIS SENDS IMMEDIATELY. There is no confirmation step and no approval prompt on this server. Nothing asks the person before the mail leaves, exactly as sendEmail here does not. Call previewTemplate first and read what it renders; that is the only check there is. It is also not idempotent: calling it twice sends twice, because deduplication is keyed to an API key and an MCP session has none. Omit version to send whatever is published now, or pin one. Props must match exactly what getTemplate lists. An unknown key or a missing required one is refused rather than sent as a blank. Name from: there is no default sender, so a send without one is refused; listWorkspaceMembers names the addresses and whole domains you reach. Set cancellableForSeconds to hold the message briefly; cancelEmail can stop it until that time runs out.

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": {
      "id": "<id>",
      "to": "<to>"
    },
    "name": "sendWithTemplate"
  }
}

Input Schema

Name	Required	Description
`cc`	No
`id`	Yes
`to`	Yes
`bcc`	No
`from`	No
`tags`	No
`props`	No
`slots`	No
`replyTo`	No
`subject`	No
`version`	No
`trackOpens`	No	true adds an open pixel to this message and false leaves it out. Left out, the setting of the address it is sent from decides, and that is off unless the address turned it on. Set it only when the user asks to track or not to track.
`trackClicks`	No	true sends the links in this message through the tracking domain to count clicks and false leaves every link as written. Left out, the setting of the address it is sent from decides, and that is off unless the address turned it on. A link whose text is itself an address is never rewritten.
`cancellableForSeconds`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 25, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well past the annotations: discloses that there is no confirmation step or approval prompt, that the call is non-idempotent because deduplication is keyed to an API key an MCP session lacks, and that unknown or missing props are rejected rather than sent blank. These are exactly the facts that change an agent's decision to call, and none of them repeat destructiveHint/openWorldHint.

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 most consequential fact ("THIS SENDS IMMEDIATELY") is front-loaded in caps, and essentially every sentence adds a distinct operational constraint. It reads as dense run-on prose with one slightly tangled clause ("exactly as sendEmail here does not"), but there is no filler to cut.

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 destructive, open-world send with no output schema, the description covers irreversibility, idempotency, validation failure modes, sender requirements, and the cancellable window. An agent has what it needs to call it safely or decline.

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?

With only 14% schema coverage across 14 params, the description carries real weight: it explains version semantics, props validation against getTemplate, the required from sender, and cancellableForSeconds with its cancelEmail counterpart. Gaps remain — it distinguishes neither props from slots nor explains id, to/cc/bcc, subject, or tags — but it covers the parameters that carry the risk.

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?

Specific verb and resource ("Send a message built from a stored template") with an explicit sibling contrast against sendEmail and a named prerequisite (previewTemplate). An agent can distinguish it from sendEmail, sendBroadcastDraft, and sendToAudience from the text alone.

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

Usage Guidelines5/5

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

Explicit when-to-use and ordering guidance: call previewTemplate first and read the render, omit version to send published-now or pin one, props must match getTemplate, cancellableForSeconds plus cancelEmail for a hold window. It also names the hard prerequisite (no default from, so a send without one is refused) and points to listWorkspaceMembers to find valid senders.

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

All Nextmail tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.