Skip to main content
Glama
Sign In

AccountHub

by ai.accounthub
OverviewDiscussionsAdmin

send_message

Destructive

Send an email (Gmail) or a Slack message from one of the user's connected accounts. Gmail: to reply into a thread pass reply_to_external_id (external_id from a search result) — the reply is REPLY ALL by default (original sender + everyone on the original To and Cc, minus only the sending account — the user's other connected accounts are kept like any participant) and is sent FROM THE ACCOUNT THAT RECEIVED THE THREAD, so omit account for replies; subject and threading are derived too. A to you pass replaces the To line but the original recipients stay on Cc, and a cc you pass is added, never a replacement — recipients are only reduced with reply_mode='sender_only', which you should use only when the user explicitly asks to reply to the sender alone. Naming an account that did not receive the thread is refused unless allow_different_sender=true (only on the user's explicit request). The result reports the actual from / to / cc — tell the user who it went to. For a new mail pass to (address) and subject. Slack: set connector='slack', account=workspace label, to=channel ('#name' or channel id) or 'me' (DM to self); no subject. To reply to a Slack search hit, pass its external_id ('channel_id:ts') as reply_to_external_id — the channel is derived and the reply threads under that message; posts as the connecting person when the workspace has a user token with chat:write; otherwise it falls back to the app (bot). The result's sent_as is 'user' or 'app'. Reading/searching does not prove which sending identity is available. For user-identity sends, access is the connecting person's access; a bot invite is not inherently required. For app-identity sends, a PUBLIC channel can work without the bot being a member when its token has chat:write.public, while a PRIVATE channel needs the bot invited. Do not silently substitute app identity when the user requires their own identity. File attachments (Gmail and Slack): pass attachment_ids (upload_id values staged via upload_attachment) and/or attachment_urls (public http(s) URLs fetched at send time). On Slack the body and the files become ONE post (uploaded as the connecting person when the workspace has the user-token files:write, otherwise as the app); a workspace connected before 2026-08-26 lacks files:write and returns a reconnect hint for attachments only — text-only sends there keep working. The user may have several Gmail accounts or Slack workspaces connected — pass account to pick one (call list_accounts first when unsure). This actually sends — confirm the recipient and body with the user before calling. Gmail needs the send scope (reconnect on a permission error); Slack channel-by-name needs channels:read (use a channel id or reconnect otherwise).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "connector": "<connector>",
      "body": "<body>"
    },
    "name": "send_message"
  }
}

Input Schema

NameRequiredDescriptionDefault
ccNoGmail Cc recipient(s). On a reply these are ADDED to the original Cc — never a replacement.
toNoGmail: recipient address (omit to reply). Slack: '#channel' / channel id / 'me' (DM to self).
bodyYesPlain-text message body.
accountNoAccount/workspace label to send from (see list_accounts). Omit when the user has exactly one for the connector.
subjectNoGmail subject (omit to reply, 元件名に Re: を付ける). Ignored for Slack.
connectorYesConnector to send from ('gmail' or 'slack').
reply_modeNoGmail replies only. 'all' (default) = Reply All: original sender + original To and Cc, minus the sending account. 'sender_only' = add nobody automatically: To = your `to` (else the original sender), Cc = only your `cc`. Use 'sender_only' ONLY when the user explicitly asks to reply to the sender alone.
attachment_idsNoGmail and Slack: upload_id values from upload_attachment to attach (staged uploads expire after 24h). Slack posts the body and the files as ONE message; a workspace connected before 2026-08-26 must be reconnected first (files:write).
attachment_urlsNoGmail and Slack: public http(s) URLs to fetch and attach at send time (15s timeout, 20MB total; private/localhost addresses are refused).
reply_to_external_idNoGmail: thread external_id to reply into (from a search result). Slack: a search hit's external_id ('channel_id:ts') to reply in-thread (channel derived), or a bare ts (then `to` is required).
allow_different_senderNoGmail replies only. A reply is sent from the account that RECEIVED the thread; if `account` names a different one the send is refused (reply_account_mismatch). Set true only when the user explicitly wants to answer from that other account.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Annotations only carry destructiveHint=true; the description adds the critical behavior that this actually sends and relies on user confirmation. It discloses reply-all defaults, that replies must come from the receiving account (or be refused), the from/to/cc reported in the result, Slack sent_as fallback to bot identity, and required scopes (send, channels:read, files:write) with reconnect guidance.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded, but the body is a dense wall of text that interleaves Gmail reply mechanics, Slack identity rules, and attachment caveats with heavy parenthetical nesting. Several attachment/permission details duplicate the schema descriptions verbatim, and the safety-critical 'confirm before sending' instruction is buried near the end.

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?

For an 11-parameter mutation tool with no output schema and minimal annotations, the description covers identity, permissions, reply semantics, attachment constraints (24h staging, 20MB, private-address refusal), and even describes the result fields (from/to/cc, sent_as). An agent has enough to call it correctly across both connectors.

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 coverage is 100%, so the baseline is 3; the description goes further by explaining cross-parameter interactions the schema can't express — that `to` replaces the To line while original recipients remain on Cc, that `account` should be omitted for replies, and that naming a non-receiving account triggers reply_account_mismatch unless allow_different_sender=true.

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 first sentence gives a specific verb and dual resource: send an email (Gmail) or a Slack message from a connected account. It separates itself from the chat/draft siblings implicitly via the gmail/slack connector scope, though it never names an alternative tool (e.g. send_draft, send_chat_message) explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit routing for new mail vs. reply, when to use reply_mode='sender_only' (only on explicit user request), when allow_different_sender is permitted, when to call list_accounts first, and a clear instruction to confirm recipient/body before sending. Slack identity selection (user vs app token, public vs private channel) is spelled out with conditions.

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

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