AccountHub

forward_chat_message

Destructive

AccountHub chat: forward ONE delivered message (with its attachments) to ONE other AccountHub chat you are in (one-to-one or group; a group chat is a shared project), after the user confirmed the destination and its member count from preview_chat_forward. NOT Slack, Gmail or Chatwork. The copy arrives as a new message marked as forwarded, from you; the original sender's name and the original conversation are not shown. If the destination's members changed since the preview (someone joined or left), NOTHING is sent: the result is recipients_changed with the new member_count and expected_members — tell the user the new count and ask again. If the original was unsent, the result is source_gone. Copies already forwarded stay even if the original is later unsent. Retrying with the same request_id never delivers twice.

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": {
      "item_id": "<item_id>",
      "target_chat_id": "<target_chat_id>",
      "expected_members": "<expected_members>"
    },
    "name": "forward_chat_message"
  }
}

Input Schema

Name	Required	Description
`item_id`	Yes	item_id of the message to forward (the same one you previewed).
`request_id`	No	Optional idempotency key for this one forward. Reuse the same value only when retrying the same forward after an error; omit it (or use a new value) for a new forward.
`target_chat_id`	Yes	chat_id of ONE destination from preview_chat_forward targets (a conversation you are in).
`expected_members`	Yes	That target's expected_members, unchanged from preview_chat_forward. If the members changed since, nothing is sent and the result is recipients_changed.

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 25, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the annotations: the copy is a new message marked as forwarded, authored by the caller, with original sender and conversation hidden; a members-changed destination sends NOTHING and returns recipients_changed with new member_count and expected_members; unsent source returns source_gone; already-delivered copies survive later unsending. The request_id note (same key never delivers twice) refines idempotentHint=false rather than contradicting it, since a fresh request_id does deliver again.

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 action and scope, and every clause carries information (exclusions, copy semantics, three failure results, idempotency). It is a single dense paragraph with semicolon-chained conditions, which costs some scannability, but there is no filler to cut.

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, non-idempotent mutation with four parameters and no output schema, the description supplies everything an agent needs: preconditions, side effects, named result states, and post-condition behavior of previously forwarded copies. No return-value explanation is owed since results are named inline.

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, but the description adds cross-tool provenance the schema cannot: item_id must be the message already previewed, target_chat_id must be one target from preview_chat_forward, and expected_members must be carried unchanged from that preview or nothing is sent. That said, it does not clarify request_id beyond what its schema description already says.

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?

A specific verb and resource (forward ONE delivered message with attachments to ONE AccountHub chat) plus explicit scope limits: one-to-one or group, one message, one destination. It also rules out Slack, Gmail and Chatwork, so an agent can distinguish it from the sibling forward_message without opening a schema.

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?

States the precondition directly: only after the user confirmed the destination and member count from preview_chat_forward. It also encodes the correct recovery path when recipients_changed fires (tell the user the new count and ask again), which is a genuine when-to-use/when-not rule rather than implied usage.

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?