Ranla

Send email

send_email

Destructive

Send an email. Provide subject + html/text, or a published template_id / template_alias with optional variables. Set scheduled_at to send later (cancel with cancel_email).

Input Schema

Name	Required	Description
`cc`	No	Cc recipients: one address, several separated by commas, or an array of addresses
`to`	Yes	Recipients: one address, several separated by commas, or an array of addresses
`bcc`	No	Bcc recipients: one address, several separated by commas, or an array of addresses
`from`	Yes	Sender address on a verified domain (or `Name <address>`). Before a domain is verified, use the sandbox sender noreply@mail.ranla.ai and send only to the account email.
`html`	No	HTML body. Send html, text or both, unless you use a template
`tags`	No	Tags as name → value, for filtering and webhooks
`text`	No	Plain-text body. Sent alongside html, or on its own
`headers`	No	Extra email headers as name → value
`subject`	No	Optional when using a published template
`category`	No	Default transactional. product and newsletter add an unsubscribe link and skip recipients who opted out of that category.
`reply_to`	No	Reply-To: one address, several separated by commas, or an array of addresses
`variables`	No	Template variables when using template_id or template_alias
`template_id`	No	Published template id
`unsubscribe`	No	Add a managed unsubscribe link to this send
`scheduled_at`	No	ISO 8601 time to send, e.g. 2026-10-01T09:00:00Z
`template_alias`	No	Published template alias
`idempotency_key`	No	Retry-safe key: the same key within 24 hours returns the first send instead of sending twice

Output Schema

Name	Required	Description	Default
`id`	Yes	Email id (msg_…)
`status`	Yes	Delivery status, e.g. queued, scheduled, sent, cancelled

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 14, 2026

addedInput schema / properties / html / description

Added value: +"HTML body. Send html, text or both, unless you use a template"

addedInput schema / properties / text / description

Added value: +"Plain-text body. Sent alongside html, or on its own"

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "id": {
+      "description": "Email id (msg_…)",
+      "type": "string"
+    },
+    "status": {
+      "description": "Delivery status, e.g. queued, scheduled, sent, cancelled",
+      "type": "string"
+    }
+  },
+  "required": [
+    "id",
+    "status"
+  ],
+  "type": "object"
+}

First observedOct 14, 2026

TDQS

A4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=false, destructiveHint=true, and openWorldHint=true, so the risky/irreversible nature of a live external send is covered structurally. The description adds scheduling behavior and the cancel_email counterpart, but says nothing about deliverability consequences, rate limits, or what an outbound send does to suppression/opt-out state. Adds some value over annotations, not a lot.

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, zero filler, and the core action is front-loaded ahead of the mode conditions and the scheduling escape hatch. Each clause carries distinct operational information.

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?

With an output schema present, return values need not be described, and the schema carries the 17 parameters, sandbox-sender rule, and idempotency behavior. The description covers action, content modes, and scheduling, which is sufficient for correct invocation, though it omits any note on failure behavior or prerequisites like verified domains.

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 per-parameter meaning is already documented in full and the baseline is 3. The description reinforces the cross-cutting rule that subject is optional when a template is used, but that relationship is already stated in the subject and html/text schema descriptions, so it adds little beyond the schema.

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 (send an email) and immediately qualifies the two content modes: subject + html/text, or a published template_id/template_alias with variables. That is enough to separate it from siblings like create_template, publish_template, and send_test_webhook_event 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 Guidelines4/5

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

Gives conditional usage for the two send modes and explicitly names the alternative for the deferral case ('Set scheduled_at to send later (cancel with cancel_email)'). It stops short of when-not-to-use guidance, such as preferring a template over inline bodies or preconditions on domain verification, which is left to the schema.

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

All Ranla tools Inspect

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

Need Help?