Workspace369

Send an inbox message

inbox_send_message

Destructive

Send one email or SMS from the workspace inbox to a client or contact. Not for texting many clients (inbox_send_bulk) or replying to a new inbound request (requests_respond); invoices and proposals use invoices_send and proposals_send. Recipients (to, cc, bcc) must already be in the workspace: a client's or contact's saved address or number (pass client_id), a team member, the workspace's own address, or the contact of an existing conversation (conversation_id); others are refused, as are opted-out or blacklisted clients. Email: to, subject and body (markdown), or a template (see email_send_options). SMS: to is one phone number and body the text; it needs client_id or conversation_id, and numbers that texted STOP or are blocked are refused. from_inbox defaults to the AI & MCP inbox, else the only inbox the user can send from; with several and no default nothing is sent and the result lists them. cc/bcc replace the default copies. Sends a real, billed message. Recipient cap: 10 per email from a starter inbox, 50 from the user's own domain or mailbox; over the cap nothing is sent. Held until the user approves it in the Workspace369 app.

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": {
      "channel": "<channel>",
      "to": "<to>"
    },
    "name": "inbox_send_message"
  }
}

Input Schema

Name	Required	Description
`cc`	No	Cc addresses. Email only. The final list: passing it replaces that field's defaults entirely (the Bcc to the workspace's own email, default Cc/Bcc, archive Bcc, a template's copies), so to add someone pass the defaults plus the new address, and to remove someone leave them out; `[]` means none. Omitted, the defaults apply. The sending inbox's compliance archive Bcc is always added. Each address counts toward the per-email cap.
`to`	Yes	Recipients. Email: one or more addresses, each getting its own copy and conversation. SMS: exactly one E.164 phone number.
`bcc`	No	Bcc addresses. Email only. The final list: passing it replaces that field's defaults entirely (the Bcc to the workspace's own email, default Cc/Bcc, archive Bcc, a template's copies), so to add someone pass the defaults plus the new address, and to remove someone leave them out; `[]` means none. Omitted, the defaults apply. The sending inbox's compliance archive Bcc is always added. Each address counts toward the per-email cap.
`body`	No	SMS text (required for sms). Email body, or use `template`. Markdown: `# ` / `## ` / `### ` start a large / medium / small heading; `- ` or `1. ` starts a bullet or numbered item; inline `bold`, `italic`, `<u>underline</u>`, `~~strikethrough~~`, `[text](https://…)` links and `![alt](https://…)` images. Text without these markers goes out as plain paragraphs. Merge fields like `{{client.first_name}}`, `{{workspace.name}}` and `{{sender.name}}` are filled in.
`channel`	Yes	Delivery channel.
`subject`	No	Email subject; else the template's, else "(no subject)".
`template`	No	Email only. A general library template, by id or name.
`client_id`	No	The client written to. Email: fills `{{client.*}}` merge fields and makes the client's saved addresses valid recipients. SMS: the client whose saved number is texted. Use the `id` that clients_search returns.
`from_inbox`	No	Email only. The inbox to send from, by label (like 'Billing') or address. Omitted, the email goes from the workspace's inbox for AI & MCP emails, else the only inbox the user can send from; when there are several and no such default, nothing is sent and the result lists them.
`conversation_id`	No	An existing conversation of this workspace to thread into; its contact's address or number may be used as a recipient. Use the `conversation_id` that search_workspace_messages returns.
`idempotency_key`	No	Optional. Repeat a call with the same key to avoid doing it twice.

Output Schema

Name	Required	Description	Default
`cc`	No
`to`	No
`bcc`	No
`sent`	No
`channel`	No
`subject`	No
`client_id`	No
`from_inbox`	No
`message_id`	No
`approval_id`	No
`template_id`	No
`approval_url`	No
`from_inbox_id`	No
`conversation_id`	No
`conversation_ids`	No
`held_for_approval`	No
`approval_expires_at`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 1, 2026

changedInput schema / properties / client_id / description

Previous value: -"The client written to. Email: fills `{{client.*}}` merge fields and makes the client's saved addresses valid recipients. SMS: the client whose saved number is texted."New value: +"The client written to. Email: fills `{{client.*}}` merge fields and makes the client's saved addresses valid recipients. SMS: the client whose saved number is texted. Use the `id` that clients_search returns."

changedInput schema / properties / conversation_id / description

Previous value: -"An existing conversation of this workspace to thread into; its contact's address or number may be used as a recipient."New value: +"An existing conversation of this workspace to thread into; its contact's address or number may be used as a recipient. Use the `conversation_id` that search_workspace_messages returns."

First observedOct 21, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Well beyond the annotations: states the message is real and billed, that it is held until user approval in the app, recipient caps per inbox tier (10 starter / 50 own domain) with 'nothing is sent' over the cap, and refusal behavior for unknown, opted-out and stopped numbers. Slightly short of 5 because the interaction between caps and the tool's own cc/bcc counting is only implied.

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?

Front-loaded with purpose, then alternatives, then recipient constraints, then channel rules and side effects — a sensible ordering. Dense and long, with some overlap against the very detailed schema descriptions of cc/bcc/from_inbox, but no sentence is filler.

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 a destructive, billed, open-world send tool with 11 parameters, the description covers eligibility, per-channel requirements, default resolution, caps, approval hold and failure modes. Output schema exists, so not explaining the response is fine, and it still flags that the result lists available inboxes when no default resolves.

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 baseline is 3, but the description adds real semantics: recipients must be saved addresses, team members, the workspace's own address or an existing conversation's contact; SMS needs client_id or conversation_id; from_inbox defaulting and the 'nothing is sent, result lists them' fallback. It mostly restates cc/bcc replacement behavior already documented at length in the schema.

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?

Specific verb and resource ('Send one email or SMS from the workspace inbox') with an explicit scope limit ('to a client or contact'). Immediately names the siblings it is not: inbox_send_bulk, requests_respond, invoices_send, proposals_send.

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?

Gives explicit when-not-to-use routing to four alternative tools plus prerequisites for the recipient (must already exist in the workspace, opt-outs refused). The channel-specific requirements (email to/subject/body vs SMS single number) define invocation conditions rather than just describing fields.

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

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