Skip to main content
Glama
Sign In

DialogBrain

by com.dialogbrain.api
OverviewDiscussionsAdmin

group_moderate

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

Telegram account actions (channel='telegram'; the person's own account, not a bot; chat_id = the chat id (-100...), its telegram: ref or our thread id; params.account_id names the account when the workspace has several and the chat has no conversation in the inbox; only an account connected in THIS workspace, never one shared in; the caller must be a workspace owner or admin):

  • delete: the OWNER (creator) deletes the group, supergroup or broadcast channel for everyone. Irreversible: params.confirm_name must be the chat's exact current title as Telegram has it (ask the person; a mismatch is refused and names the title Telegram has). The inbox conversation is archived, its messages kept. error_type outcome_unknown means it may have been deleted: check before retrying

  • history_visible: params: visible (true/false). Whether NEW members see the messages sent before they joined. Supergroups only (a basic group has no such switch; a broadcast channel always shows its history); the account must be an admin allowed to change the info

  • set_title: params: title. set_description: params: description ("" clears it). Both need those admin rights too; safe to repeat

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 BOT actions (channel='telegram_bot'):

  • 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', 'telegram' (an account), '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', 'discord' or 'whatsapp'"New value: +"Channel the group lives on, e.g. 'telegram_bot', 'telegram' (an account), 'discord' or 'whatsapp'"
  2. 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'"
  3. 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'"
  4. 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"
+}
  5. Added

TDQS

A3.9/5.0
Behavior1/5

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

The description discloses rich behavior, including irreversible delete actions, confirm_name requirements, MFA requirements, and platform-specific refusal modes. However, the annotations declare destructiveHint: false while the description explicitly says Telegram group/channel delete and Discord server delete are irreversible and remove the group/server for everyone. That is a direct contradiction of the annotation's destructive safety signal.

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?

The description is long, but the tool is genuinely multi-action and multi-platform, and the content is organized with clear headings and bullets. It is front-loaded with the core purpose and the length is largely justified, though some platform-specific detail could be tightened.

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 complex tool with no output schema, the description is highly complete: it explains action availability by channel, prerequisites, refusal outcomes, return keys, and important Telegram-specific pitfalls. An agent has enough context to select actions and anticipate errors.

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 has 100% description coverage, its parameter descriptions are generic and the nested params object is largely undocumented. The tool description compensates by listing action-specific parameters and semantics: confirm_name, mfa_code, visible, title, description, file_id, permissions, color, hoist, mentionable, channel, seconds, account_id, invite_link, user_id, rights, revoke_messages, until_date, message_id, and silent.

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 description opens with a specific verb and resource: 'Run ONE moderation action on a group,' then enumerates the supported group types and action categories across Telegram account, Discord, WhatsApp, and Telegram bot. This is far more specific than a tautological title and lets an agent distinguish moderation actions from sibling group-management tools.

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?

The description gives extensive per-channel and per-action guidance, including prerequisites, required admin rights, irreversible operations requiring confirm_name or MFA, and what to do when a bot cannot add members. It does not explicitly compare against sibling tools such as group_promote_admin or group_add_member, so it falls short of full alternative routing guidance.

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