Groundbase

Send an email

email_send

Send a real email from the user's connected mailbox (default: the oldest one). Give bodyHtml and/or bodyText. Pass contactId so merge tags resolve and the email threads to that contact. At most 50 recipients (to+cc+bcc); a list is a campaign. One-to-one mail ignores the campaign suppression list. Confirm with the user first.

Input Schema

Name	Required	Description
`cc`	No
`to`	Yes	Address or comma-separated list.
`bcc`	No
`subject`	Yes
`bodyHtml`	No
`bodyText`	No
`fromName`	No
`accountId`	No	Sending mailbox, from email_accounts_list.
`contactId`	No
`fromEmail`	No	Send-as alias registered on that mailbox; others are refused (INVALID_FROM).
`trackOpens`	No	Adds an open-tracking pixel (approximate).
`scheduledSendAt`	No	Future ISO 8601 time to send at.

Schema Changelog

Changes observed during successful MCP inspections.

Changed12 schema fields changedOct 1, 2026

changedInput schema / properties / accountId / description

Previous value: -"Optional mailbox UUID from email_accounts_list. Defaults to the oldest connected mailbox."New value: +"Sending mailbox, from email_accounts_list."

removedInput schema / properties / bcc / description
```
Removed value: -"BCC list (comma-separated)."
```

removedInput schema / properties / bodyHtml / description

Removed value: -"HTML body (preferred). Supports merge tags."

removedInput schema / properties / bodyText / description

Removed value: -"Plain-text body. Sent alongside HTML if both given."

removedInput schema / properties / cc / description
```
Removed value: -"CC list (comma-separated)."
```

removedInput schema / properties / contactId / description

Removed value: -"Optional contact UUID. When set, merge tags resolve and the thread attaches to the contact. It does not pick the mailbox."

changedInput schema / properties / fromEmail / description

Previous value: -"Optional Send-as alias to send from, e.g. \"adam@example.com\". Must be the mailbox's own address or an alias registered on it under Settings → Email; anything else is refused with INVALID_FROM. Does not pick the mailbox — pair with accountId when there is more than one."New value: +"Send-as alias registered on that mailbox; others are refused (INVALID_FROM)."

removedInput schema / properties / fromName / description

Removed value: -"Optional display name for the From header. Defaults to the alias's or mailbox's saved name."

changedInput schema / properties / scheduledSendAt / description

Previous value: -"Optional future ISO 8601 timestamp. When set the message is queued and dispatched by the per-minute cron at that time."New value: +"Future ISO 8601 time to send at."

removedInput schema / properties / subject / description

Removed value: -"Subject line. Supports merge tags when contactId is provided."

changedInput schema / properties / to / description

Previous value: -"Recipient email or comma-separated list."New value: +"Address or comma-separated list."

changedInput schema / properties / trackOpens / description

Previous value: -"When true, inject a 1x1 open-tracking pixel. Signal is approximate (Gmail proxies + Apple Mail Privacy interfere)."New value: +"Adds an open-tracking pixel (approximate)."

Changed2 schema fields changedSep 23, 2026

addedInput schema / properties / fromEmail

Added value: +{
+  "description": "Optional Send-as alias to send from, e.g. \"adam@example.com\". Must be the mailbox's own address or an alias registered on it under Settings → Email; anything else is refused with INVALID_FROM. Does not pick the mailbox — pair with accountId when there is more than one.",
+  "type": "string"
+}

addedInput schema / properties / fromName

Added value: +{
+  "description": "Optional display name for the From header. Defaults to the alias's or mailbox's saved name.",
+  "type": "string"
+}

First observedSep 23, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the annotations: this sends a real external message, defaults to the oldest connected mailbox, has a hard 50-recipient ceiling, and one-to-one mail bypasses the campaign suppression list — a behavior an agent would otherwise get wrong. The instruction to confirm with the user before sending is exactly the safety context the annotations (destructiveHint=false) do not supply.

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?

Five short sentences, each carrying a distinct constraint (mailbox default, body pairing, contactId effect, recipient cap, suppression bypass, confirmation). The most consequential facts — real send and user confirmation — are not buried.

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 12-parameter outbound-send tool with no output schema, the description covers the decisions that matter: which mailbox, how to supply the body, recipient limits, and confirmation. It does not say what is returned (message id) or how scheduling interacts with the confirmation requirement, a minor gap given the tool's complexity.

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?

With schema coverage at 42%, the description compensates by explaining that bodyHtml and bodyText are alternatives, that contactId drives merge-tag resolution and threading, and that to/cc/bcc share a 50-address budget. It leaves fromName and the cc/bcc/subject fields undocumented beyond their names, so the compensation is strong but not complete.

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 real email') plus the sending context ('from the user's connected mailbox, default: the oldest one'), which an agent could not infer from the name. The line 'a list is a campaign' draws the boundary against campaign-style sending in the sibling set.

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 concrete preconditions: supply bodyHtml and/or bodyText, pass contactId for merge tags and threading, stay within 50 recipients, and confirm with the user first. It signals that a recipient list becomes a campaign rather than naming campaigns_manage as the alternative, so routing is implied rather than explicit.

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

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