Skip to main content
Glama
mojawave

MojaWave MCP

Official
by mojawave

send_email

Send transactional emails from a registered sender. Confirm recipient, subject, and content with user before sending to use credits.

Instructions

Send a transactional email from a registered sender address.

Costs 1 credit per recipient (to + each cc + each bcc). At least one of body (plain text) or html is required.

Call list_email_senders first to confirm from_email is registered. ALWAYS confirm to, subject, from_email, and body/html with the user before sending — this spends real credits and delivers a real email.

Args: to: Recipient email address (e.g. customer@example.com). from_email: Registered sender address on a verified domain (e.g. noreply@yourdomain.com). Use list_email_senders to find valid values. subject: Email subject line (max 500 chars). body: Plain-text body. At least one of body or html is required. html: Optional HTML body (e.g. "Hello"). Provide alongside body as a fallback for clients that don't render HTML. from_name: Optional display name shown in the recipient's inbox (e.g. "Duka Masta Billing"). cc: Optional list of CC addresses. Each costs 1 credit. bcc: Optional list of BCC addresses. Each costs 1 credit. reply_to: Optional reply-to address if different from from_email. schedule_at: Optional future delivery time in ISO-8601 (e.g. 2026-06-15T09:00:00Z). Naive datetimes (no Z/offset) are treated as EAT (Africa/Dar_es_Salaam, UTC+3). Leave empty to send immediately. tags: Optional string labels for filtering in message history (max 10).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ccNo
toYes
bccNo
bodyNo
htmlNo
tagsNo
subjectYes
reply_toNo
from_nameNo
from_emailYes
schedule_atNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

With no annotations, the description fully discloses credit costing per recipient, requirements for body/html, timezone handling for schedule_at (EAT), tag limits, and that this is a real email send. No contradictions.

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 description is well-structured with a purpose statement, key notes, and an organized parameter list. It is concise for 11 parameters but some entries (e.g., html fallback explanation) could be slightly more terse.

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?

Given the complexity (11 params, no annotations, no schema descriptions), the description covers all essentials: purpose, prerequisites, costs, parameter details, behavioral nuances (timezone), and references to related tools. It is fully actionable.

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?

Despite 0% schema coverage, the description's Args section provides detailed semantics for all 11 parameters, including constraints (max 500 chars for subject, max 10 tags), formatting (ISO-8601 for schedule_at), and dependencies (body or html required).

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 description starts with a specific verb ('Send') and resource ('transactional email from a registered sender address'), clearly stating the tool's function. It implicitly distinguishes from SMS siblings by focusing on email.

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?

The description gives important prerequisites: 'Call list_email_senders first to confirm from_email is registered' and warns about real credit usage and user confirmation. It lacks explicit comparison to alternatives but the context is sufficient.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mojawave/mojawave-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server