SenderKit

Send Raw Message

senderkit_send_raw

Destructive

Send a transactional email, SMS, push, or web-push notification with inline content, without a registered template. This connection is bound to one mode: in test mode messages are recorded but not delivered; in live mode they are really sent. The result's mode field reports which one was used, and senderkit_context reports it before sending.

Input Schema

Name	Required	Description
`cc`	No	Email-only. Cc recipients as a JSON array of addresses (max 50).
`to`	Yes	Recipient address for the chosen channel: an email address (email), an E.164 phone number such as +15551234567 (sms), a device token (push), or the JSON-encoded browser PushSubscription — endpoint + keys — (web-push).
`bcc`	No	Email-only. Bcc recipients as a JSON array of addresses (max 50).
`body`	No	Message body (sms, push, web-push).
`from`	No	Email-only. Optional From address override (bare address — put the display name in fromName). Defaults to the connection's From address.
`html`	No	Email HTML body. Required when channel is "email" — a text-only email send is rejected; wrap plain text in minimal HTML instead.
`icon`	No	Icon URL shown in the notification (web-push).
`text`	No	Email plain-text body (email).
`vars`	No	Template variables as a JSON object.
`badge`	No	Badge count (push, web-push).
`sound`	No	Notification sound (push).
`title`	No	Notification title (push, web-push).
`channel`	Yes	Channel: email, sms, push, or web-push.
`context`	Yes	Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): "Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization."
`replyTo`	No	Email-only. Reply-To address.
`subject`	No	Email subject. Required when channel is "email".
`clickUrl`	No	URL opened when the notification is clicked (web-push).
`fromName`	No	Email-only. Optional From display name, rendered as `Name <address>`. Max 128 chars; no control characters or angle brackets.
`metadata`	No	Free-form metadata as a JSON object of scalar values.
`pushData`	No	Data payload as a JSON object of strings (push, web-push).
`preheader`	No	Email preheader (email).
`attachments`	No	Email-only. JSON array; up to 10 MB total across all attachments.
`interpolate`	No	Run server-side variable substitution over content.
`scheduledAt`	No	ISO 8601 timestamp for scheduled delivery (e.g. 2026-06-01T09:00:00Z). Must be in the FUTURE and at most 30 days ahead — check the current date before computing it. Omit to send immediately.
`idempotencyKey`	No	Idempotency key. Repeat values return the original send instead of duplicating.

Output Schema

Name	Required	Description
`id`	Yes	Public message id (e.g. "msg_…"). Pass it to senderkit_messages_get to track delivery, or to senderkit_cancel_message while it is still pending.
`mode`	Yes	The connection's send mode: live messages are really delivered; test messages are recorded but not delivered.
`status`	Yes	"scheduled" when scheduledAt was in the future; otherwise "queued".
`livemode`	Yes	Whether the message was created in live mode.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 15, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false, openWorldHint=true, so the safety profile is covered. The description adds genuinely new behavior: test mode records without delivering, live mode really sends, and the 'mode' field in the result reports which was used. It does not cover failure modes or rate limits.

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, front-loaded with the primary action and followed by the mode semantics. Every sentence carries information the agent needs; nothing is restated from the schema.

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 25-parameter, multi-channel send tool with an output schema (so return values need not be explained) and full annotation coverage, the description supplies the crucial test/live mode caveat. It stops short of noting channel-required-field constraints at a glance, but that lives in the schema.

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% across all 25 parameters, so the schema already documents channel-specific fields (html required for email, E.164 for sms, etc.). The description adds no parameter-level syntax or format detail beyond what the schema provides, so baseline 3 applies.

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 (Send) plus the four supported channels and the scope qualifier 'inline content, without a registered template', which cleanly separates it from the template-based sibling senderkit_send. An agent can pick it without opening the 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?

'without a registered template' implicitly routes template-based sends to senderkit_send, and the test-vs-live mode sentence tells the agent when delivery actually occurs. No explicit when-not statement or named alternative, so it stops short of a 5.

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

All SenderKit 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.