Skip to main content
Glama

messages_remove_reaction

Destructive

Remove a reaction from a message by providing channel, chat, message ID, and emoji. This updates data other people can see, so confirm before running.

Instructions

Remove a reaction from a message Reaches other people on the platform, deletes, or redirects data — say exactly what will happen and get the user’s confirmation first. (POST /api/kalagh/messages/remove-reaction · gRPC RemoveReaction · socket "messages/remove-reaction")

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
emojiYes
chatIdYes
channelIdYes
messageIdYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and openWorldHint=true, so the safety profile is covered structurally. The description adds a confirmation requirement ('get the user's confirmation first') and spells out the consequence that the change 'reaches other people on the platform', which is actionable behavioral context beyond the hints. It stops short of saying what happens if the reaction does not exist or whether the removal is reversible.

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?

Purpose is front-loaded, followed by the safety caveat and then endpoint metadata. The parenthetical transport details (POST path, gRPC method, socket event) are useful for debugging and do not bury the core instruction, though the middle sentence is generic template text rather than tool-specific.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a four-parameter destructive mutation with no output schema, the description omits key details: the relationship between channelId/chatId/messageId, what the response contains on success, and behavior when the reaction is absent. Annotations cover the safety profile, so the gap is not fatal, but the definition is only minimally complete.

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

Parameters2/5

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

Schema description coverage is 0% and the description mentions none of the four required parameters (channelId, chatId, messageId, emoji). The schema only supplies example values, so the agent gets no explanation of the ID hierarchy or the emoji format from either source; the description fails to compensate for the coverage gap.

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 first line gives a precise verb+resource ('Remove a reaction from a message'), which is immediately distinguishable from the sibling messages_react and from messages_delete. No ambiguity about what operation is performed.

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

Usage Guidelines3/5

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

It instructs the agent to state exactly what will happen and obtain user confirmation first, which is real operational guidance for a mutation. However, it never contrasts this tool with messages_react (the inverse operation) or explains when removal is appropriate versus editing/deleting the message, so usage is only implied.

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