AccountHub

send_chat_message

Destructive

Send a message in AccountHub chat (one-to-one chats and group chats; a group chat is a shared project) — use this whenever the user says 'send X to <person/group> in AccountHub chat' / 「AccountHub のチャットで〇〇さんに送って」. NOT Slack, Gmail or Chatwork. Before calling, show the user the recipient and the exact text and get their explicit OK — they have not seen text you composed. Address it by to (a person's name or email among your chat contacts and existing chats, or a group chat's name) or by chat_id. If the name matches several chats or none, NOTHING is sent: the result has status 'needs_choice' / 'not_found' with candidates — ask the user which one and call again with that chat_id. It posts exactly like typing in the AccountHub chat, and the recipients get the same notifications. To send files, stage them with upload_attachment and pass attachment_ids (and/or attachment_urls); the message arrives once every file is stored. Not idempotent: a successful call posts once; an identical text sent to the same chat within 10 minutes is refused as 'duplicate_suspected' unless allow_duplicate is true. Trial users only.

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": {
      "text": "<text>"
    },
    "name": "send_chat_message"
  }
}

Input Schema

Name	Required	Description
`to`	No	Who to send to: a person's name (e.g. '佐藤さん' / 'Sato'), their email, or a group chat's name. Use this OR chat_id.
`text`	Yes	The exact message text the user confirmed. Sent as-is (first line + the rest), like typing it in the AccountHub chat.
`chat_id`	No	An exact chat id from list_unread_chats / read_chat / a previous candidates list. Use this OR to.
`chat_type`	No	Narrow `to` to one-to-one chats ('direct') or group chats ('group') when a person and a group share a name.
`attachment_ids`	No	upload_id values from upload_attachment to send as photos / videos / files in this message (max 10; each staged upload is at most 5 MB). With attachments, text may be empty.
`allow_duplicate`	No	Only when the user explicitly wants to send the same text again within 10 minutes. Default false: an identical recent message is not re-sent.
`attachment_urls`	No	Public http(s) URLs fetched at send time and sent as attachments (each at most 25 MB; unsafe addresses are refused). Executables cannot be sent.
`reply_to_item_id`	No	Optional: item_id of a message in the same chat to reply to (from read_chat).

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 24, 2026

addedInput schema / properties / attachment_ids

Added value: +{
+  "description": "upload_id values from upload_attachment to send as photos / videos / files in this message (max 10; each staged upload is at most 5 MB). With attachments, text may be empty.",
+  "items": {
+    "type": "string"
+  },
+  "maxItems": 10,
+  "type": "array"
+}

addedInput schema / properties / attachment_urls

Added value: +{
+  "description": "Public http(s) URLs fetched at send time and sent as attachments (each at most 25 MB; unsafe addresses are refused). Executables cannot be sent.",
+  "items": {
+    "type": "string"
+  },
+  "maxItems": 10,
+  "type": "array"
+}

AddedOct 23, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already flag destructiveHint=true and idempotentHint=false, and the description reinforces rather than contradicts them by spelling out exactly what happens: it posts as if typed by the user, recipients get normal notifications, attachments land only after all files are stored, and an identical message within 10 minutes is refused as 'duplicate_suspected' unless allow_duplicate is true. The 'trial users only' constraint is valuable extra context. It stops short of stating permission/auth requirements or what a successful result body contains.

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 the trigger and exclusions, then prerequisite, addressing, failure modes, duplicates, and attachments in a sensible order. It is a single dense paragraph with no filler, but the packing of duplicate/attachment/trial-user caveats makes it heavier to scan than an ideally structured definition.

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?

With 8 parameters, no output schema, and only sparse annotations, the description carries the behavioral load and does so fully: addressing, ambiguity outcomes and status strings, duplicate policy, attachment mechanics and size limits, and the pre-send confirmation requirement. An agent has everything needed to invoke it correctly and interpret failure statuses.

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 3 is the baseline; the description earns above it by explaining the to-vs-chat_id addressing model, the needs_choice/not_found candidates flow, the attachment staging path via upload_attachment, and the duplicate window tied to allow_duplicate. It adds meaning rather than repeating schema text, though the per-field detail itself still lives 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?

Names a specific verb and resource ('Send a message in AccountHub chat') and immediately bounds the scope to one-to-one and group chats. It explicitly excludes Slack, Gmail and Chatwork, which is exactly the differentiation an agent needs among the many send_* siblings such as send_chatwork_message and send_message.

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 an explicit trigger phrase ('whenever the user says send X to <person/group>'), an explicit negative list, and a hard prerequisite: show the recipient and exact text and get explicit OK before calling. It also routes ambiguity to a concrete procedure (ask the user, re-call with chat_id) and file sending to upload_attachment.

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

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