Skip to main content
Glama
Infomaniak

kChat MCP Server

by Infomaniak

kchat_add_reaction

Adds an emoji reaction to a kChat message using the message ID and emoji name.

Instructions

Add a reaction emoji to a kChat message

Input Schema

NameRequiredDescriptionDefault
post_idYesThe ID of the the message to react to
emoji_nameYesThe name of the emoji reaction

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.1

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations, the description carries the full burden and discloses very little. It doesn't say whether adding the same reaction twice errors or is idempotent, whether the caller needs channel membership or permissions, or whether the reaction is visible to others — all meaningful for a mutation tool.

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?

A single efficient sentence with the verb and target front-loaded and no filler. It is not padded, though the terseness is what leaves the behavioral and format gaps open.

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?

The operation is simple and atomic with only two fully-described parameters and no output schema to explain, so the essentials are present. However, for a mutation tool with zero annotations, the missing emoji-format convention and duplicate/permission behavior are real gaps an agent would hit in practice.

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

Parameters3/5

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

Schema coverage is 100%, so both parameters are already documented in the schema, making 3 the baseline. The description adds no syntax detail — critically, whether emoji_name expects a shortcode like 'thumbsup' or a literal emoji character like '👍' is left unresolved in both schema and description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Add') and resource ('reaction emoji') against a clearly identified target ('kChat message'), which is unambiguous. It is naturally distinct from the sibling tools (posting, reading history, user lookups), though the description itself does no explicit differentiating work.

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

Usage Guidelines2/5

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

There is no guidance on when to use this versus alternatives, no prerequisites (e.g. must the caller already be able to see the message?), and no mention that the message must already exist. The agent must infer all usage conditions from the tool name alone.

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