Skip to main content
Glama

Groundbase

by com.groundbasecrm.mcp
OverviewDiscussionsAdmin

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. Confirm with the user first.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ccNo
toYesAddress or comma-separated list.
bccNo
subjectYes
bodyHtmlNo
bodyTextNo
fromNameNo
accountIdNoSending mailbox, from email_accounts_list.
contactIdNo
fromEmailNoSend-as alias registered on that mailbox; others are refused (INVALID_FROM).
trackOpensNoAdds an open-tracking pixel (approximate).
scheduledSendAtNoFuture ISO 8601 time to send at.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed12 schema fields changed
    • 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)."
  2. Changed2 schema fields changed
    • 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"
+}
  3. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations cover the safety profile (readOnly=false, idempotent=false, openWorld=true, destructive=false), and the description adds value beyond them: the default mailbox is the oldest account, the 50-recipient ceiling across to+cc+bcc, merge-tag/threading behavior, and the confirm-first expectation. It does not spell out auth/permission requirements or what a failure returns, so not a 5.

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?

Four tight sentences, front-loaded with the core action and scoped by mailbox, followed by body, contactId, recipient-limit, and confirmation guidance. Dense and purposeful, with no filler.

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 no output schema and 12 params at 42% coverage, the description carries a lot but covers the key behavioral facts: default mailbox, threading/merge tags, recipient ceiling, and confirmation. Minor gaps remain (fromName intent, scheduling semantics), but the agent has enough to call it correctly.

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 coverage is low (42%) and 12 params exist, so the description must compensate. It clarifies that bodyHtml and bodyText are alternatives and explains the contactId effect, but leaves fromName, cc/bcc/subject, and several others unaddressed, so it only partially fills the gap.

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 from the user's connected mailbox') and the 'real' qualifier plus the mailbox scope clearly separates it from sibling senders like sms_send, invoices_send, and quotes_send. An agent can identify the action 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?

Gives concrete usage conditions: supply bodyHtml and/or bodyText, pass contactId for merge tags and threading, and 'Confirm with the user first'. It sets context but does not name alternative tools or state when not to use it, so it falls short of full alternative routing.

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

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