Skip to main content
Glama

Connect Discord, Slack, Telegram, and more

manage_webhook
Destructive

Create, update, delete, or test Minecraft server event webhooks that post joins, deaths, chat, and other activity to Discord, Slack, Telegram, Teams, Google Chat, or JSON endpoints.

Instructions

Connect the server to a chat: “send deaths to my Discord”, “post joins to Telegram in Russian”. action create makes one and sends a test message; update changes its events, language, own words, access, or pauses it (enabled false); delete removes it; test sends a test message; telegram_chats lists the chats a Telegram bot can write to. How the user gets what create needs:

  • discord: channel settings → Integrations → Webhooks → New Webhook → Copy Webhook URL.

  • slack: api.slack.com/apps → an app → Incoming Webhooks → Add New Webhook; Mattermost and Rocket.Chat take this format too.

  • teams: the channel → Workflows → “Post to a channel when a webhook request is received”, then its URL.

  • google_chat: the space → Apps & integrations → Webhooks.

  • telegram: make a bot with @BotFather and get its token; the user writes /start to the bot, or adds it to a group or channel; then telegram_chats with botToken lists chats, and one's id is chatId.

  • json: any HTTPS URL that takes the event as JSON; the answer holds a signing secret, shown once. These URLs and bot tokens are secrets: ask the user to paste them, never invent them, and don't repeat them back. topics are event ids, player.* for a prefix, or * for every notable event (joins, leaves, deaths, advancements, chat, raids, bosses, the server starting and stopping). By default a webhook sees no coordinates and no chat; permissions widens that, but only up to this token's own. Addresses must be https://, and ones on the server's machine or private network are refused, unless the owner allows them in config.yml. test works once per webhook every 10 seconds. Webhooks in config.yml change only there. Needs webhooks:manage.

Input Schema

NameRequiredDescriptionDefault
urlNoFor create, every format but telegram
nameNoThe webhook; for create, a new name such as discord-deaths
actionYesWhat to do
chatIdNoFor create with telegram
formatNoFor create
topicsNoSuch as ["player.death"], ["player.*"], or ["*"]
enabledNoFor update: false pauses it
botTokenNoFor create and telegram_chats, the Telegram bot's token
languageNoChat messages' language; English by default
messagesNoIts own words by message key, such as {"player.death": "RIP: {message}"}; list_webhooks with options shows the keys and placeholders
permissionsNoWhat it may see, such as ["events:read", "chat:read"]; default: no coordinates, no chat

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv4.2.1
    • addedInput schema / properties / action / description
      Added value: +"What to do"
  2. Addedv4.2.0

TDQS

A4.7/5.0
Behavior4/5

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

Adds substantial context beyond the annotations: the 10-second test rate limit, https-only URLs, refusal of addresses on the server's machine or private network unless the owner opts in in config.yml, the one-time signing secret for json, and the default coordinate/chat redaction with a permissions cap. Annotations cover destructive/write nature, but the description still carries the important operational caveats, so a 4 rather than 5.

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 semantics, then a compact per-format prerequisite list. Dense and information-rich, though the bulleted setup recipes make it longer than strictly necessary for an agent that already knows a given platform's webhook setup.

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 an 11-parameter, multi-action mutation tool with no output schema, the description covers selection, prerequisites, security handling of secrets, defaults and limits. Nothing an agent needs in order to call it correctly is missing.

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?

Even at 100% schema coverage the description adds real meaning: the topics grammar (event ids, `player.*` prefixes, `*` for notable events and its enumerated scope), the url/chatId split between telegram and other formats, and the pointer that list_webhooks with options reveals message keys and placeholders for `messages`.

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 the resource (chat webhooks) and enumerates every action with a specific verb: create sends a test message, update changes events/language/messages/access or pauses, delete removes, test sends a message, telegram_chats lists writable chats. An agent can tell exactly what this tool does and can distinguish it from the sibling list_webhooks, which it references by name.

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?

Explicit routing per action plus prerequisite collection instructions for every format (Discord channel settings, Slack app webhooks, Teams Workflows, Google Chat, BotFather token flow, generic JSON). It also states exclusions and boundaries: 'Webhooks in config.yml change only there' and 'Needs webhooks:manage.'

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