AccountHub

create_chat_group

Create a group chat (an AccountHub shared project and its conversation) with a name. People in member_user_ids (from list_chat_contacts: your active, consenting shared project collaborators) join at once without accepting; emails are invited and join after accepting (accept_url is returned — nothing is emailed from here). Posts a first line saying who joined and who was invited, which notifies the joined people at their chat notification destinations. Optional handoff posts a user-reviewed summary of a one-to-one as the first post, only when that chat's other person is in member_user_ids. To post in a group that already exists use send_chat_message. 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": {
      "name": "<name>"
    },
    "name": "create_chat_group"
  }
}

Input Schema

Name	Required	Description
`name`	Yes	Group name (1-120 characters).
`emails`	No	Email addresses to invite. They join after accepting the invitation link (returned as accept_url; no email is sent from MCP).
`handoff`	No	Carry over a reviewed summary of a one-to-one. Accepted only when the other person of that chat is in member_user_ids.
`member_user_ids`	No	AccountHub people to add directly (user_id from list_chat_contacts). They join at once without accepting.

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 22, 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 lone destructiveHint=false annotation: discloses that joining members are notified, that no email is sent from here and accept_url is returned instead, and the trial-user limitation. These are non-obvious side effects an agent needs before invoking a mutating call.

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?

Information-dense and front-loaded with the core action, though some sentences are long and pack multiple clauses (join semantics + notifications + handoff rule). No filler, but slightly dense to parse in one pass.

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 no output schema, the description steps up by noting accept_url is returned and describing the first-post/notification behavior. Nested handoff object semantics are also addressed, leaving no critical gap for correct invocation.

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 still adds value by tying member_user_ids to list_chat_contacts and explaining the accept vs. invite distinction and the handoff eligibility rule. It reinforces rather than simply repeats 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?

States a specific verb+resource ('Create a group chat') and clarifies it is an AccountHub shared project plus its conversation, which distinguishes it from message-sending siblings like send_chat_message. The name/purpose is unambiguous.

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?

Explicitly routes the agent to send_chat_message for posting in an existing group, and states the handoff precondition ('only when that chat's other person is in member_user_ids') plus the 'Trial users only' constraint. When-to-use and when-not are both covered.

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?