Skip to main content
Glama

zulip_react

Add an emoji reaction to a Zulip message by message ID and emoji name to acknowledge or respond to updates in team streams.

Instructions

Add an emoji reaction, by name such as "thumbs_up", to a message id.

Input Schema

NameRequiredDescriptionDefault
emojiYes
message_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=true, so the safety profile is covered. The description adds nothing about the non-idempotent behavior that matters here (what happens when the same emoji is added twice, whether it errors or duplicates) nor about required permissions.

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 front-loaded sentence with no filler. Minor deduction because the nested quoting around "thumbs_up" is slightly awkward and the emoji-name hint would read more cleanly as a separate clause.

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 two-parameter, non-destructive tool with no output schema, the description is serviceable but thin: it omits duplicate-reaction behavior, permission requirements, and the message_id format. An agent can probably invoke it correctly, but edge cases are undocumented.

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 0%, so the description must carry parameter meaning and only partially does. The 'by name such as "thumbs_up"' clause genuinely helps, telling the agent to pass a Zulip emoji name rather than a unicode character, but message_id is left entirely unexplained and the exact naming convention (aliases, punctuation) remains ambiguous.

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?

States a specific verb ('Add') and resource ('emoji reaction') against a named target ('a message id'). This is clearly distinct from every sibling (zulip_send, zulip_read, zulip_search), so an agent can select it 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 Guidelines3/5

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

Usage is implied by the action itself: react to an existing message rather than post a new one. However, there is no explicit statement of when to prefer this over zulip_send (e.g., acknowledging a message without a reply) and no exclusions or prerequisites.

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