Skip to main content
Glama

send-message

Send messages to Zulip channels or direct users using stream names or email addresses. Specify topic for channel messages and format content with Zulip Markdown.

Instructions

💬 SEND MESSAGE: Send a message to a Zulip stream (channel) or direct message to users. IMPORTANT: For streams use exact names from 'get-subscribed-streams'. For DMs use actual email addresses from 'search-users' tool (NOT display names). Always include 'topic' for stream messages.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
typeYes'stream' for channel messages, 'direct' for private messages
toYesFor streams: channel name (e.g., 'general'). For direct: comma-separated user emails (e.g., 'user@example.com' or 'user1@example.com,user2@example.com')
contentYesMessage content using Zulip Markdown syntax. Support mentions (@**Name**), code blocks, links, etc.
topicNoTopic name for stream messages (required for streams, max length varies by server)

Implementation Reference

  • MCP handler function for 'send-message' tool: validates inputs (requires topic for streams, validates emails for direct), constructs params, calls ZulipClient.sendMessage, returns success/error in MCP format.
    server.tool(
      "send-message",
      "💬 SEND MESSAGE: Send a message to a Zulip stream (channel) or direct message to users. IMPORTANT: For streams use exact names from 'get-subscribed-streams'. For DMs use actual email addresses from 'search-users' tool (NOT display names). Always include 'topic' for stream messages.",
      SendMessageSchema.shape,
      async ({ type, to, content, topic }) => {
        try {
          if (type === 'stream' && !topic) {
            return createErrorResponse('Topic is required for stream messages. Think of it as a subject line for your message.');
          }
    
          if (type === 'direct') {
            const validation = validateEmailList(to);
            if (!validation.isValid) {
              return createErrorResponse(`Invalid email format for direct message recipients: ${to}. Use 'search-users' tool to find correct email addresses. Don't use display names.`);
            }
          }
    
          const messageParams = { type, to, content, ...(topic && { topic }) };
          const result = await zulipClient.sendMessage(messageParams);
          return createSuccessResponse(`Message sent successfully! Message ID: ${result.id}`);
        } catch (error) {
          return createErrorResponse(`Error sending message: ${error instanceof Error ? error.message : 'Unknown error'}`);
        }
      }
    );
  • Zod schema defining the input parameters for the send-message tool: type (stream/direct), to (stream name or emails), content, optional topic.
    export const SendMessageSchema = z.object({
      type: z.enum(["stream", "direct"]).describe("'stream' for channel messages, 'direct' for private messages"),
      to: z.string().describe("For streams: channel name (e.g., 'general'). For direct: comma-separated user emails (e.g., 'user@example.com' or 'user1@example.com,user2@example.com')"),
      content: z.string().describe("Message content using Zulip Markdown syntax. Support mentions (@**Name**), code blocks, links, etc."),
      topic: z.string().optional().describe("Topic name for stream messages (required for streams, max length varies by server)")
    });
  • src/server.ts:404-428 (registration)
    Registers the 'send-message' tool with the MCP server using server.tool(), providing name, description, schema, and handler function.
    server.tool(
      "send-message",
      "💬 SEND MESSAGE: Send a message to a Zulip stream (channel) or direct message to users. IMPORTANT: For streams use exact names from 'get-subscribed-streams'. For DMs use actual email addresses from 'search-users' tool (NOT display names). Always include 'topic' for stream messages.",
      SendMessageSchema.shape,
      async ({ type, to, content, topic }) => {
        try {
          if (type === 'stream' && !topic) {
            return createErrorResponse('Topic is required for stream messages. Think of it as a subject line for your message.');
          }
    
          if (type === 'direct') {
            const validation = validateEmailList(to);
            if (!validation.isValid) {
              return createErrorResponse(`Invalid email format for direct message recipients: ${to}. Use 'search-users' tool to find correct email addresses. Don't use display names.`);
            }
          }
    
          const messageParams = { type, to, content, ...(topic && { topic }) };
          const result = await zulipClient.sendMessage(messageParams);
          return createSuccessResponse(`Message sent successfully! Message ID: ${result.id}`);
        } catch (error) {
          return createErrorResponse(`Error sending message: ${error instanceof Error ? error.message : 'Unknown error'}`);
        }
      }
    );
  • ZulipClient.sendMessage helper: constructs API payload for /messages endpoint, handles direct (array of emails) vs stream (name + topic), tries JSON then form-encoded request to Zulip API.
    async sendMessage(params: {
      type: 'stream' | 'direct';
      to: string;
      content: string;
      topic?: string;
    }): Promise<{ id: number }> {
      if (process.env.NODE_ENV === 'development') {
        debugLog('🔍 Debug - sendMessage called with:', JSON.stringify(params, null, 2));
      }
      
      // Use the type directly - newer API supports "direct" 
      const payload: any = {
        type: params.type,
        content: params.content
      };
    
      // Handle recipients based on message type
      if (params.type === 'direct') {
        // For direct messages, handle both single and multiple recipients
        const recipients = params.to.includes(',') 
          ? params.to.split(',').map(email => email.trim())
          : [params.to.trim()];
        
        // Try both formats to see which works
        payload.to = recipients;  // Array format first
        debugLog('🔍 Debug - Direct message recipients:', recipients);
      } else {
        // For stream messages, 'to' is the stream name
        payload.to = params.to;
        if (params.topic) {
          payload.topic = params.topic;
        }
      }
    
      debugLog('🔍 Debug - Final payload:', JSON.stringify(payload, null, 2));
    
      try {
        // Try JSON first (modern API)
        const response = await this.client.post('/messages', payload);
        debugLog('✅ Debug - Message sent successfully:', response.data);
        return response.data;
      } catch (jsonError) {
        debugLog('⚠️ Debug - JSON request failed, trying form-encoded...');
        if (jsonError instanceof Error) {
          debugLog('Error:', (jsonError as any).response?.data || jsonError.message);
        }
        
        // Fallback to form-encoded with different recipient format
        const formPayload = { ...payload };
        if (params.type === 'direct') {
          // Try JSON string format for recipients
          const recipients = params.to.includes(',') 
            ? params.to.split(',').map(email => email.trim())
            : [params.to.trim()];
          formPayload.to = JSON.stringify(recipients);
        }
        
        debugLog('🔍 Debug - Form payload:', JSON.stringify(formPayload, null, 2));
        
        const response = await this.client.post('/messages', formPayload, {
          headers: {
            'Content-Type': 'application/x-www-form-urlencoded'
          },
          transformRequest: [(data) => {
            const params = new URLSearchParams();
            for (const key in data) {
              if (data[key] !== undefined) {
                params.append(key, String(data[key]));
              }
            }
            const formString = params.toString();
            debugLog('🔍 Debug - Form-encoded string:', formString);
            return formString;
          }]
        });
        
        debugLog('✅ Debug - Form-encoded message sent successfully:', response.data);
        return response.data;
      }
    }
Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively communicates that this is a write operation (sending messages), specifies data source requirements (exact names from other tools), and includes important constraints (topic requirement for streams). However, it doesn't mention potential side effects like notifications or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is efficiently structured with three sentences that each serve a distinct purpose: stating the core function, providing critical usage rules, and specifying the topic requirement. The emoji and formatting enhance readability without adding unnecessary length.

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

Completeness4/5

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

For a write operation with no annotations and no output schema, the description does well by covering the essential behavioral context and usage guidelines. However, it could be more complete by mentioning what happens after sending (e.g., message ID returned, notification triggers) or any error conditions beyond the implied constraints.

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 description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema by reinforcing the 'topic' requirement for streams and emphasizing exact naming conventions, but doesn't provide significant additional semantic context beyond what's in the structured fields.

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 clearly states the specific action ('send a message') and target resources ('Zulip stream or direct message to users'), distinguishing it from sibling tools like 'create-draft' or 'edit-message' which handle different message lifecycle stages. The inclusion of the emoji and formatting makes the purpose immediately recognizable.

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?

The description provides explicit guidance on when to use this tool versus alternatives: it specifies to use 'get-subscribed-streams' for stream names and 'search-users' for email addresses, and clarifies that 'topic' is required for stream messages. This gives clear context for proper invocation without misleading information.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/avisekrath/zulip-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server