Skip to main content
Glama

dialogbrain

by io.github.saloprj
OverviewDiscussionsAdmin

group_moderate

Run ONE moderation action on a group: a Telegram bot group or a Discord SERVER the connected account administers, or a WhatsApp group the connected number is a member of.

Discord actions (channel='discord'; chat_id = the server id, a channel id, a channel's thread ref or our thread id; params.account_id names the account when the workspace has several and chat_id does not; only an account connected in THIS workspace, never one shared in):

  • community: switch Community mode on (rules screening and announcement channels become possible). params: rules_channel (default #rules), updates_channel (where Discord posts its notices to the team; default a hidden #moderator-only, made when missing), announcement_channel (the one turned into an announcement channel, default #announcements; false for none); channels by id, ref or #name. Discord's conditions change server defaults (verification level at least low, media filter for everyone, notifications to mentions only): the answer lists them in settings_changed; tell the person

  • icon: params: file_id of a PNG/JPEG/GIF/WebP in this workspace

  • set_title: params: title. set_description: params: description (community servers only)

  • role: params: name, permissions (names such as view_channel, send_messages, manage_messages, kick_members, moderate_members, administrator, or Discord's bitfield as a number), color (#rrggbb), hoist, mentionable. Not idempotent: a retry makes a second role

  • slowmode: params: channel (id, ref or #name) and seconds (0 to 21600; 0 turns it off), both required

  • delete: the OWNER deletes the server. Irreversible: params.confirm_name must be the server's exact name (ask the person); with two-factor on, Discord wants params.mfa_code, the current authenticator code the person reads out (redacted from every log and trace) Every Discord action needs the caller to be a workspace owner or admin. Discord refusals are worded: no_permission (not an admin), mfa_required, not_community, bad_request (a value Discord rejected).

WhatsApp actions (channel='whatsapp'; chat_id = the group JID (...@g.us), its whatsapp: ref or our thread id; only the workspace's own numbers, not one shared in; the number that is in the group is used):

  • set_title: params: title (at most 100 characters). Any member may rename unless the group's admins locked its info; WhatsApp's refusal is passed through. Needs edit rights in the workspace. When two of the workspace's numbers are in the group, params.account_id is required. The inbox thread takes the new name.

Telegram actions:

  • invite_link: mint a fresh invite link; older links stay valid. Optional params: name, member_limit, expire_date, creates_join_request

  • revoke_invite_link: params: invite_link

  • admins: list administrators (user_id, username, name, status)

  • member_count: how many members the group has

  • member_status: one member's status. params: user_id

  • promote / demote: params: user_id, optional rights {can_*: bool}

  • ban / unban: params: user_id, optional revoke_messages

  • mute / unmute: params: user_id, optional until_date (unix ts)

  • pin / unpin: params: message_id (omit on unpin for the latest), optional silent

  • set_title: params: title

  • set_description: params: description

⚠️ A Telegram BOT cannot add a member or create a group — the Bot API has no method for either. To bring someone in, mint an invite_link and send it to them.

Telegram rules that surprise callers (all verified against a live group):

  • A bot may only promote/demote admins IT promoted. Check can_be_edited in member_status first: false means demote will answer 'not enough rights', and that is Telegram, not a failure on our side.

  • promote additionally needs the bot to hold can_promote_members in the group; plain admin rights are not enough.

  • After unmute the status stays 'restricted' while every can_send_* is true. That is Telegram labelling anyone who carries an explicit permission set — it does NOT mean still muted. Read the permissions, not the status.

  • unban lifts the ban but does not bring the person back: the status becomes 'left' and they must rejoin.

Returns: success plus the action's own keys (invite_link, admins, member_count, status) and result, Telegram's own payload.

Input Schema

NameRequiredDescriptionDefault
actionYesWhich action to run (see the tool description for the list)
paramsNoAction-specific arguments, e.g. {'user_id': 123} for promote/ban, {'message_id': '456'} for pin, {'title': '...'} for set_title
channelYesChannel the group lives on, e.g. 'telegram_bot', 'discord' or 'whatsapp'
chat_idYesGroup to act on: the platform chat id (e.g. -1004487018858), a channel_ref, or our numeric DB thread id
in_workspaceNoRun this one call in this workspace id instead of the session's. Nothing is stored; other sessions are not affected.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / channel / description
      Previous value: -"Channel the group lives on, e.g. 'telegram_bot' or 'discord'"New value: +"Channel the group lives on, e.g. 'telegram_bot', 'discord' or 'whatsapp'"
  2. Changed1 schema field changed
    • changedInput schema / properties / channel / description
      Previous value: -"Channel the group lives on, e.g. 'telegram_bot'"New value: +"Channel the group lives on, e.g. 'telegram_bot' or 'discord'"
  3. Changed1 schema field changed
    • addedInput schema / properties / in_workspace
      Added value: +{
+  "description": "Run this one call in this workspace id instead of the session's. Nothing is stored; other sessions are not affected.",
+  "type": "integer"
+}
  4. Added

TDQS

A4.1/5.0
Behavior2/5

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

The description is unusually candid about side effects — role creation is not idempotent, unban leaves the user at 'left', unmute leaves status 'restricted', and 'delete' irreversibly destroys the server behind confirm_name plus mfa_code. That last disclosure directly conflicts with the destructiveHint=false annotation, so an agent trusting the annotations alone would badly underestimate the risk; the undo/guard behavior is the only reason this isn't scored at the floor.

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?

It is long but front-loaded and organized by platform then action, so an agent can jump to the relevant bullet. A few passages are denser than needed, notably the community-mode defaults explanation and some repeated Discord parameter wording, but almost every line carries actionable constraint information.

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 five-param, multi-action tool with no output schema, it covers prerequisites (workspace admin/owner), per-platform refusal codes (no_permission, mfa_required, not_community, bad_request), and return shape ('success plus the action's own keys ... and result'). Nothing essential to calling it correctly is left out.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although the schema already documents all five parameters, the description supplies the per-action param contract the generic 'params' object cannot: key names, defaults (#rules, #announcements, hidden #moderator-only), value formats (#rrggbb, unix ts, Discord bitfield), and bounds (seconds 0-21600, title max 100 chars). It also explains chat_id's three accepted forms per platform and when account_id is required.

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?

The opening sentence states a specific verb and resource ('Run ONE moderation action on a group') and immediately bounds the resource by platform: Telegram bot group, Discord server the account administers, WhatsApp group the number belongs to. The per-platform action lists make it unambiguous what the tool can do without opening the schema.

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

Usage Guidelines4/5

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

It gives real conditional guidance: Discord actions require the caller to be a workspace owner or admin, only an account connected in THIS workspace can be used, WhatsApp set_title needs edit rights and account_id when two numbers are in the group, and it warns against the impossible 'add member' path (mint invite_link instead). What is missing is routing against overlapping siblings such as group_promote_admin, group_admins and group_get_invite_link, which this tool duplicates.

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

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