Skip to main content
Glama

send16-mcp

by io.github.spruikco
OverviewDiscussionsAdmin

Send email

send_email
Destructive

Send a transactional email through Send16. Provide html, text, or both (text-only is fine for OTPs/receipts/alerts). from_email must belong to a domain that is verified in the workspace; call whoami for the account and list_domains to see which senders are allowed; a send from an unverified domain returns a clear error, not a silent failure. For a zero-setup first send, use from_email onboarding@send16.com; the sandbox sender delivers with no DNS, but only to your own account email. Before calling, confirm with the user: show them the recipients (or the recipient count), the sender and the subject, and wait for a clear yes. Send16 can refuse a send. 429 SEND_RAMP_LIMIT: new and free workspaces have hourly and daily sending limits while they build reputation; the error details give the window, the limit and how many remain. Tell the user how many can go now and that the rest can go once the window resets (or after upgrading), and do not split the send or retry in a loop to get around it. 403 SENDING_PAUSED: sending from the workspace is paused while the Send16 team reviews it. Nothing was sent. Tell the user to check the workspace owner's email or contact support, and do not retry. 422 MESSAGE_NEEDS_REVIEW: the content looked like it might be impersonating a government agency, bank, toll operator or delivery company, so it was held and not sent. Tell the user it is held for review and they can contact support if it is legitimate. Do not reword it and try again; repeated flags pause the workspace.

Input Schema

NameRequiredDescriptionDefault
toYesRecipient email address or array of addresses (max 50)
htmlNoHTML body content
textNoPlain text body content
apiKeyNoSend16 API key (overrides SEND16_API_KEY env var)
subjectYesEmail subject line
reply_toNoReply-to email address
templateNoTransactional template slug to use instead of inline content
from_nameNoSender display name (e.g. "Acme Co")
variablesNoTemplate variables for merge tags
from_emailNoSender email address (must be from a verified domain)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / from_email / pattern
      Previous value: -"^(?!\\.)(?!.*\\.\\.)([A-Za-z0-9_'+\\-\\.]*)[A-Za-z0-9_+-]@([A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"New value: +"^(?:[A-Za-z0-9_'+\\-]+\\.)*[A-Za-z0-9_'+\\-]*[A-Za-z0-9_+-]@(?:[A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"
    • changedInput schema / properties / reply_to / pattern
      Previous value: -"^(?!\\.)(?!.*\\.\\.)([A-Za-z0-9_'+\\-\\.]*)[A-Za-z0-9_+-]@([A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"New value: +"^(?:[A-Za-z0-9_'+\\-]+\\.)*[A-Za-z0-9_'+\\-]*[A-Za-z0-9_+-]@(?:[A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"
    • changedInput schema / properties / to / anyOf
      Previous value: -[
-  {
-    "format": "email",
-    "pattern": "^(?!\\.)(?!.*\\.\\.)([A-Za-z0-9_'+\\-\\.]*)[A-Za-z0-9_+-]@([A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$",
-    "type": "string"
-  },
-  {
-    "items": {
-      "format": "email",
-      "pattern": "^(?!\\.)(?!.*\\.\\.)([A-Za-z0-9_'+\\-\\.]*)[A-Za-z0-9_+-]@([A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$",
-      "type": "string"
-    },
-    "maxItems": 50,
-    "minItems": 1,
-    "type": "array"
-  }
-]New value: +[
+  {
+    "format": "email",
+    "pattern": "^(?:[A-Za-z0-9_'+\\-]+\\.)*[A-Za-z0-9_'+\\-]*[A-Za-z0-9_+-]@(?:[A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$",
+    "type": "string"
+  },
+  {
+    "items": {
+      "format": "email",
+      "pattern": "^(?:[A-Za-z0-9_'+\\-]+\\.)*[A-Za-z0-9_'+\\-]*[A-Za-z0-9_+-]@(?:[A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$",
+      "type": "string"
+    },
+    "maxItems": 50,
+    "minItems": 1,
+    "type": "array"
+  }
+]
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Far exceeds the annotations (destructive/idempotent/openWorld hints). It discloses the verification requirement, the sandbox sender's restricted reach, the mandatory user-confirmation flow, and the concrete failure modes (429 SEND_RAMP_LIMIT, 403 SENDING_PAUSED, 422 MESSAGE_NEEDS_REVIEW) with what happened and what NOT to do (no retry loops, no rewording). This is exactly the behavioral context an agent needs before invoking.

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?

Long but front-loaded: the core action and content options come first, followed by prerequisite constraints, the confirmation requirement, and error handling. Every block carries actionable information, though the error-code enumeration is dense and slightly repetitive in its 'do not retry' refrain.

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?

No output schema exists, and the description fully compensates by enumerating the meaningful failure responses and their required handling. For a 10-parameter mutation tool with nested variables, nothing an agent needs to call and recover from this tool is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3; the description adds meaning by explaining that html and text are alternatives (text-only is fine for OTPs/receipts/alerts), that from_email must be a verified-domain sender, and that a specific sandbox sender exists. It clarifies selection semantics beyond the raw field list.

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 a transactional email through Send16'), and the 'transactional' qualifier implicitly separates it from broadcast/campaign sends. An agent can distinguish it from send_broadcast, send_reply, and send_event without opening a 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?

Provides clear preconditions and context: from_email must be on a verified domain, call whoami/list_domains to check senders, and use the sandbox sender for a first send. It even names the alternative senders to inspect. However, it never explicitly routes the agent to a sibling like send_broadcast for marketing sends, so the when-not side is implied rather than stated.

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

All send16-mcp toolsInspect
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