Skip to main content
Glama
Sign In
Arsel MCP Server

Arsel MCP Server

Official
by Arsel-SA
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Send Email

send-email
Destructive

Send a transactional email such as a receipt, order update, or password reset—not marketing—by providing HTML/text or a template, then confirm recipients before dispatch.

Instructions

Send a transactional email: a one-off message such as a receipt, an order update or a password reset, not a marketing campaign. Give the content as html and/or text with a subject, or as a template_id from list-templates. Up to 50 recipients across to, cc and bcc; one malformed address rejects the whole request. This reaches real people, and a message that has gone out cannot be recalled. Before calling it, show the user what will go out and to whom, and wait for their go-ahead. See what was sent with list-emails.

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": {
      "from": "<from>",
      "from_name": "<from_name>",
      "to": "<to>"
    },
    "name": "send-email"
  }
}

Input Schema

NameRequiredDescriptionDefault
ccNo
toYes
bccNo
fromYesSender address at one of the organization's `verified` domains, from list-email-domains.
htmlNoCannot be combined with `template_id`.
textNoPlain-text body; alone or alongside `html`.
subjectNoRequired with `html` or `text`; with `template_id` it defaults to the template subject.
categoryNoLabel for grouping in analytics, e.g. `order_update` or `otp`.
reply_toNo
from_nameYesSender display name.
variablesNoValues for `{{key}}` placeholders in the content.
attachmentsNoUp to 10 files, 30 MB in total once decoded.
template_idNoTemplate to send, from list-templates. Cannot be combined with `html` or `text`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.2.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare destructive=true, idempotent=false and openWorld=true, but the description adds non-obvious operational facts the schema cannot convey: one malformed address rejects the entire request (all-or-nothing validation), the 50-recipient cap spans to/cc/bcc combined, and a sent message cannot be recalled. The 'reaches real people' framing plus the pre-send confirmation requirement is genuine behavioral guidance beyond the safety hints.

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?

Five sentences, each carrying distinct load: what it is, how to supply content, hard limits, irreversibility, required human confirmation, and verification path. The disambiguation is front-loaded, and no sentence restates the name, title or annotations.

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 13-parameter, nested-object mutation tool with no output schema, the description covers the decision-critical surface: content composition, recipient limits, atomicity, irreversibility and confirmation workflow. It does not touch attachments (30 MB / 10 files), variables, or category, though those are documented in the schema — hence short of perfect but complete enough to call correctly.

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 69% and the description closes the important gaps: it states the content model (html and/or text with subject, XOR template_id), that template_id must come from list-templates, and the aggregate recipient limit across three array parameters that the schema's maxItems only partly conveys (maxItems=50 sits on `to` alone). Remaining undocumented fields (category, variables, attachments) are adequately described in the schema itself.

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 ('Send a transactional email') and immediately scopes it with concrete examples (receipt, order update, password reset) while explicitly excluding the sibling use case ('not a marketing campaign'), which maps to send-email-campaign. An agent can distinguish this from the campaign, push, SMS and WhatsApp senders without opening any schema.

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?

Gives explicit when-to-use criteria (transactional, one-off), an explicit when-not (marketing campaign), the prerequisite chain (template_id from list-templates, from address from verified domains), a required human-in-the-loop workflow (show the user what goes out and to whom, wait for go-ahead), and a follow-up route ('See what was sent with list-emails'). Nothing about tool selection is left to inference.

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

Deploy Server

Other Tools