Enables interaction with Zulip workspaces, providing tools to list channels, post messages, send direct messages, add emoji reactions, retrieve channel history, get topics, subscribe to channels, and get user information.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Zulip MCP Server post a message to the general channel about the upcoming team meeting"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP Server for the Zulip API, enabling AI assistants like Claude to interact with Zulip workspaces.
zulip_list_channels
List available channels (streams) in the Zulip organization
Optional inputs:
include_private (boolean, default: false): Whether to include private streams
include_web_public (boolean, default: true): Whether to include web-public streams
include_subscribed (boolean, default: true): Whether to include streams the bot is subscribed to
Returns: List of streams with their IDs and information
zulip_post_message
Post a new message to a Zulip channel (stream)
Required inputs:
channel_name (string): The name of the stream to post to
topic (string): The topic within the stream
content (string): The message content to post
Returns: Message posting confirmation and ID
zulip_send_direct_message
Send a direct message to one or more users
Required inputs:
recipients (string[]): Email addresses or user IDs of recipients
content (string): The message content to send
Returns: Message sending confirmation and ID
zulip_add_reaction
Add an emoji reaction to a message
Required inputs:
message_id (number): The ID of the message to react to
emoji_name (string): Emoji name without colons
Returns: Reaction confirmation
zulip_get_channel_history
Get recent messages from a channel (stream) and topic
Required inputs:
channel_name (string): The name of the stream
topic (string): The topic name
Optional inputs:
limit (number, default: 20): Number of messages to retrieve
anchor (string, default: "newest"): Message ID to start from
Returns: List of messages with their content and metadata
zulip_get_topics
Get topics in a channel (stream)
Required inputs:
channel_id (number): The ID of the stream
Returns: List of topics in the stream
zulip_subscribe_to_channel
Subscribe the bot to a channel (stream)
Required inputs:
channel_name (string): The name of the stream to subscribe to
Returns: Subscription confirmation
zulip_get_users
Get list of users in the Zulip organization
Returns: List of users with their basic information
Related MCP server: Slack MCP Server
Create a Zulip Bot:
Log in to your Zulip instance
Navigate to Settings > Personal > Bots
Click "Add a new bot"
Select "Generic bot" type
Fill in the required information
Click "Create bot"
Permissions:
By default, Zulip bots have limited permissions
Make sure to subscribe the bot to any streams it needs to access
If you need the bot to have more permissions, consider using a full user account instead
Get the API credentials:
Bot's email address
Bot's API key (displayed when you create the bot)
Zulip instance URL (e.g., https://example.zulipchat.com)
Add the following to your claude_desktop_config.json:
{
"mcpServers": {
"zulip": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-zulip"
],
"env": {
"ZULIP_EMAIL": "your-bot@example.zulipchat.com",
"ZULIP_API_KEY": "your-bot-api-key",
"ZULIP_URL": "https://example.zulipchat.com"
}
}
}
}{
"mcpServers": {
"zulip": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"-e",
"ZULIP_EMAIL",
"-e",
"ZULIP_API_KEY",
"-e",
"ZULIP_URL",
"mcp/zulip"
],
"env": {
"ZULIP_EMAIL": "your-bot@example.zulipchat.com",
"ZULIP_API_KEY": "your-bot-api-key",
"ZULIP_URL": "https://example.zulipchat.com"
}
}
}
}If you encounter permission errors, verify that:
The bot API key is correct
The bot has been subscribed to the channels it needs to access
The Zulip URL is correct and accessible
Docker build:
docker build -t mcp/zulip .Copyright 2025 Monadical
Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
This product includes third-party software components. See the LICENSE and NOTICE files for details.
Add an emoji reaction to a message
| Name | Required | Description | Default |
|---|---|---|---|
| message_id | Yes | The ID of the message to react to | |
| emoji_name | Yes | Emoji name without colons |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It states the action but doesn't disclose whether this requires specific permissions, if it's idempotent, what happens on duplicate reactions, or any rate limits. For a mutation tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any wasted words. It's appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the tool returns, error conditions, or behavioral nuances. Given the complexity of adding reactions in a messaging system, more context about permissions, idempotency, or response format would be needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters. The description doesn't add any additional meaning about the parameters beyond what's in the schema, such as emoji format examples or message ID constraints. Baseline 3 is appropriate when the schema does all the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add') and target ('emoji reaction to a message'), making the purpose immediately understandable. However, it doesn't distinguish this tool from potential sibling tools like 'zulip_post_message' or 'zulip_send_direct_message' in terms of interaction type, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The description doesn't mention prerequisites (like needing message access), appropriate contexts, or when other tools might be more suitable for different types of interactions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recent messages from a channel (stream) and topic
| Name | Required | Description | Default |
|---|---|---|---|
| channel_name | Yes | The name of the stream | |
| topic | Yes | The topic name | |
| limit | No | Number of messages to retrieve (default 20) | |
| anchor | No | Message ID to start from (default 'newest') | newest |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves messages but doesn't cover critical aspects like whether it's read-only (implied but not explicit), pagination behavior, rate limits, authentication needs, or error handling. For a tool with no annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and appropriately sized, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a tool with 4 parameters and behavioral complexity. It lacks details on return values, error conditions, or operational constraints, which are crucial for an agent to use the tool effectively in context with sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 with clear descriptions. The description adds no additional meaning beyond what the schema provides, such as explaining relationships between parameters or usage nuances. Baseline 3 is appropriate when the schema handles parameter documentation effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get recent messages') and resource ('from a channel (stream) and topic'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'zulip_get_topics' or 'zulip_list_channels', which also retrieve information but about different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, exclusions, or compare it to sibling tools like 'zulip_get_topics' for topic lists or 'zulip_post_message' for sending messages, leaving the agent without contextual usage cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get topics in a channel (stream)
| Name | Required | Description | Default |
|---|---|---|---|
| channel_id | Yes | The ID of the stream |
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 states the basic action but lacks critical details: it doesn't specify if this is a read-only operation, what the output format looks like (e.g., list of topics with metadata), whether there are rate limits, or if authentication is required. This leaves significant gaps for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single, clear sentence that directly states the tool's purpose without any fluff. It is front-loaded with the core action and resource, making it efficient and easy to parse. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one required parameter, no nested objects) and the lack of annotations and output schema, the description is minimally adequate. It states what the tool does but doesn't provide enough context for full understanding, such as output details or behavioral traits. This meets the minimum viable threshold but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'channel_id' clearly documented as 'The ID of the stream'. The description adds no additional parameter information beyond what the schema provides, such as format examples or constraints. According to the rules, with high schema coverage, the baseline is 3 even without param details in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get topics') and the resource ('in a channel (stream)'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'zulip_get_channel_history' which might also retrieve channel-related information, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. For example, it doesn't specify if this is for listing all topics versus searching for specific ones, or how it differs from 'zulip_get_channel_history' which might include topic information. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get list of users in the Zulip organization
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 states the tool retrieves a user list but doesn't mention any behavioral traits such as pagination, rate limits, authentication needs, or what data is included in the list, leaving significant gaps for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any wasted words. It is appropriately sized and front-loaded, making it easy to understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't address behavioral aspects like return format, pagination, or error handling, which are crucial for a list-retrieval tool, leaving the agent with insufficient context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately avoids redundant parameter details, aligning with the baseline for zero parameters, though it doesn't add extra semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get list') and resource ('users in the Zulip organization'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'zulip_list_channels' or 'zulip_get_topics' that also retrieve lists, missing full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description lacks context about use cases, prerequisites, or comparisons to siblings like 'zulip_get_channel_history' for user-related data, offering no explicit or implied usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available channels (streams) in the Zulip organization
| Name | Required | Description | Default |
|---|---|---|---|
| include_private | No | Whether to include private streams | |
| include_web_public | No | Whether to include web-public streams | |
| include_subscribed | No | Whether to include streams the bot is subscribed to |
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 states it's a list operation, implying read-only behavior, but doesn't cover aspects like pagination, rate limits, authentication requirements, or what the output format looks like (e.g., list of objects with IDs and names). This leaves significant gaps for an agent to use it effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action ('List available channels'), making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete for a tool with three parameters and no structured output information. It doesn't explain what the list returns (e.g., channel objects with properties), potential limitations, or error cases, leaving the agent with insufficient context for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, clearly documenting all three boolean parameters with defaults. The description adds no parameter-specific information beyond implying a general listing function, so it doesn't enhance the schema's details. This meets the baseline of 3 when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('available channels (streams) in the Zulip organization'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'zulip_get_channel_history' or 'zulip_get_topics', which also retrieve channel-related information but with different scopes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention scenarios like initial channel discovery, filtering needs, or how it compares to siblings such as 'zulip_get_channel_history' for historical data or 'zulip_subscribe_to_channel' for subscription management.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Post a new message to a Zulip channel (stream)
| Name | Required | Description | Default |
|---|---|---|---|
| channel_name | Yes | The name of the stream to post to | |
| topic | Yes | The topic within the stream | |
| content | Yes | The message content to post |
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 states this is a 'Post' operation (implying a write/mutation) but doesn't cover important aspects like authentication requirements, rate limits, error conditions, or what happens on success (e.g., message ID returned). This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any unnecessary words. It's appropriately sized and front-loaded with the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the tool returns, error handling, or behavioral constraints. Given the complexity of posting messages in a chat system, more context about permissions, formatting, or response format would be needed for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so all parameters are documented in the schema itself. The description adds no additional parameter information beyond what's already in the schema, which meets the baseline expectation when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Post a new message') and target resource ('to a Zulip channel (stream)'), making the purpose immediately understandable. However, it doesn't explicitly distinguish this tool from sibling tools like 'zulip_send_direct_message', which would require a 5 score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'zulip_send_direct_message' or 'zulip_add_reaction'. It also doesn't mention prerequisites such as needing to be subscribed to the channel or having appropriate permissions, leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a direct message to one or more users
| Name | Required | Description | Default |
|---|---|---|---|
| recipients | Yes | Email addresses or user IDs of recipients | |
| content | Yes | The message content to send |
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 states the action ('send') but lacks details on permissions required, rate limits, error handling, or what happens upon success (e.g., message ID returned). This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It is appropriately sized and front-loaded, with every word earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain behavioral aspects like authentication needs, potential side effects, or return values, leaving significant gaps for an AI agent to operate effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents both parameters ('recipients' and 'content') with clear descriptions. The tool description adds no additional meaning beyond what the schema provides, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('send') and resource ('direct message to one or more users'), making the tool's purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'zulip_post_message' (which might be for channels), leaving some ambiguity about when to choose one over the other.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., authentication), exclusions, or comparisons to siblings like 'zulip_post_message', leaving the agent to infer usage context without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Subscribe the bot to a channel (stream)
| Name | Required | Description | Default |
|---|---|---|---|
| channel_name | Yes | The name of the stream to subscribe to |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('Subscribe') but does not explain what this entails—e.g., whether it requires admin permissions, if it's idempotent (safe to call multiple times), or what happens on success/failure. This leaves significant gaps 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any fluff or redundancy. It is front-loaded and appropriately sized for a simple tool with one parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral aspects (e.g., permissions, idempotency) and expected outcomes, which are crucial for an agent to use it correctly in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with 'channel_name' clearly documented as 'The name of the stream to subscribe to'. The description adds no additional parameter semantics beyond this, so it meets the baseline of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Subscribe') and the target ('the bot to a channel (stream)'), making the purpose specific and unambiguous. It distinguishes this tool from siblings like 'zulip_list_channels' (list) or 'zulip_post_message' (post), as it focuses on subscription management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as whether it's for initial setup, re-subscription, or specific contexts. It lacks any mention of prerequisites (e.g., bot permissions) or exclusions, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
zulip_add_reactionzulip_get_channel_historyzulip_get_topicszulip_get_userszulip_list_channelszulip_post_messagezulip_send_direct_messagezulip_subscribe_to_channelEach tool has a clearly distinct purpose targeting different Zulip operations: reactions, message history, topics, users, channels, posting messages, direct messages, and subscriptions. There is no overlap or ambiguity between these functions, making tool selection straightforward for an agent.
All tools follow a consistent 'zulip_verb_noun' pattern with snake_case, such as 'zulip_add_reaction' and 'zulip_get_channel_history'. This predictable naming convention enhances readability and usability across the tool set.
With 8 tools, this server is well-scoped for interacting with Zulip's core features like messaging, channels, users, and subscriptions. Each tool serves a specific, necessary function without bloat or redundancy, making the count appropriate for the domain.
The tool set covers essential Zulip operations including reading and posting messages, managing channels and users, and handling reactions. Minor gaps exist, such as updating or deleting messages, but agents can likely work around these with the provided tools for most workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Enable secure connectivity between Sentry issues and debugging data, and LLM clients, using a Model Context Protocol (MCP) server.
A Model Context Protocol server for Wix AI tools
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Monadical-SAS/zulip-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
