Nitrosend

nitro_send_message

DestructiveIdempotent

Send one transactional email/SMS. For bulk use campaigns/flows. Retry unchanged payload/key.

Input Schema

Name	Required	Description
`cc`	No
`to`	Yes	Email or E.164 phone
`bcc`	No
`body`	No	Plain text; required for SMS
`data`	No	Merge variables, e.g. {{ data.order_id }}
`from`	No	Email sender: Name <address>
`tags`	No	Email tags
`channel`	Yes
`dry_run`	No	Preview without sending
`headers`	No	Email headers; reserved names rejected
`subject`	No
`reply_to`	No	Reply address
`from_name`	No	Sender name
`from_email`	No	Verified brand sender address
`template_id`	No	Email template ID
`idempotency_key`	Yes	Reuse only for an exact retry

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 3, 2026

addedInput schema / properties / bcc

Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "maxItems": 10,
+  "type": "array"
+}

addedInput schema / properties / cc

Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "maxItems": 10,
+  "type": "array"
+}

Changed14 schema fields changedOct 28, 2026

changedInput schema / properties / body / description

Previous value: -"Message body. Required for SMS. Optional plain text for email."New value: +"Plain text; required for SMS"

removedInput schema / properties / channel / description
```
Removed value: -"Delivery channel"
```

changedInput schema / properties / data / description

Previous value: -"Transactional merge variables. Use in email templates as {{ data.order_id }} or nested paths like {{ data.customer.name }}."New value: +"Merge variables, e.g. {{ data.order_id }}"

changedInput schema / properties / dry_run / description

Previous value: -"Validate and preview without sending"New value: +"Preview without sending"

addedInput schema / properties / from

Added value: +{
+  "description": "Email sender: Name <address>",
+  "type": "string"
+}

addedInput schema / properties / from_email

Added value: +{
+  "description": "Verified brand sender address",
+  "type": "string"
+}

addedInput schema / properties / from_name

Added value: +{
+  "description": "Sender name",
+  "type": "string"
+}

addedInput schema / properties / headers

Added value: +{
+  "additionalProperties": {
+    "type": "string"
+  },
+  "description": "Email headers; reserved names rejected",
+  "maxProperties": 20,
+  "type": "object"
+}

changedInput schema / properties / idempotency_key / description

Previous value: -"Required for live sends. Reuse the same stable key on retry to prevent duplicate delivery."New value: +"Reuse only for an exact retry"

addedInput schema / properties / reply_to

Added value: +{
+  "description": "Reply address",
+  "type": "string"
+}

removedInput schema / properties / subject / description

Removed value: -"Email subject line (required for email)"

addedInput schema / properties / tags

Added value: +{
+  "additionalProperties": {
+    "type": [
+      "string",
+      "number",
+      "boolean"
+    ]
+  },
+  "description": "Email tags",
+  "maxProperties": 20,
+  "type": "object"
+}

changedInput schema / properties / template_id / description

Previous value: -"Load email design from an existing template (email only)"New value: +"Email template ID"

changedInput schema / properties / to / description

Previous value: -"Recipient email address or E.164 phone number"New value: +"Email or E.164 phone"

First observedOct 19, 2026

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, idempotentHint=true, openWorldHint=true and readOnlyHint=false, so the safety profile is known without the prose. The description adds genuine value by converting idempotentHint into an actionable retry rule (same payload AND same key), but it omits rate limits, verified-sender requirements, and what happens to a duplicate submission with a changed payload.

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 clauses, zero filler, with the core action front-loaded before the bulk alternative and the retry rule. Every sentence earns its place and nothing needs trimming.

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 16-parameter, nested-object, destructive send tool with no output schema, the definition covers the essentials: what it does, when not to use it, and how to retry safely. The remaining gap is channel-conditional requirements (SMS needs body, email needs a verified sender) and the test-message sibling, which the schema only partially compensates for.

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 75% across 16 parameters, so the schema already documents most fields including to, body, from, data, dry_run, and headers. The description's only parameter-level contribution is constraining idempotency_key usage to exact retries, which the schema's 'Reuse only for an exact retry' already largely conveys.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource (send one transactional email/SMS) and scopes it to single-message use, which separates it from the bulk composing siblings. It says 'campaigns/flows' rather than naming nitro_compose_campaign and nitro_compose_flow directly, so the routing cue is inferable rather than explicit, and it never mentions nitro_send_test_message as the test-path alternative.

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?

It gives a clear when-not ('For bulk use campaigns/flows') and an explicit retry rule ('Retry unchanged payload/key'), which tells the agent exactly when this tool is the right call versus a campaign/flow tool. It stops short of covering prerequisites such as sender verification or the test-vs-live distinction.

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

All Nitrosend 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?