Zulip API 的 MCP 服务器，使 Claude 等 AI 助手能够与 Zulip 工作区进行交互。
zulip_list_channels
列出 Zulip 组织中的可用频道（流）
可选输入：
include_private （布尔值，默认值：false）：是否包含私有流
include_web_public (布尔值，默认值：true)：是否包含网络公共流
include_subscribed （布尔值，默认值：true）：是否包含机器人订阅的流
返回：流及其 ID 和信息的列表
zulip_post_message
向 Zulip 频道（流）发布新消息
必需输入：
channel_name （字符串）：要发布到的流的名称
topic （字符串）：流中的主题
content （字符串）：要发布的消息内容
返回：消息发布确认和ID
zulip_send_direct_message
向一个或多个用户发送直接消息
必需输入：
recipients （string[]）：收件人的电子邮件地址或用户 ID
content （字符串）：要发送的消息内容
返回：消息发送确认和ID
zulip_add_reaction
在消息中添加表情符号反应
必需输入：
message_id （数字）：需要响应的消息的 ID
emoji_name （字符串）：不带冒号的表情符号名称
返回：反应确认
zulip_get_channel_history
从频道（流）和主题获取最新消息
必需输入：
channel_name （字符串）：流的名称
topic （字符串）：主题名称
可选输入：
limit （数字，默认值：20）：要检索的消息数量
anchor （字符串，默认值：“最新”）：从中开始的消息 ID
返回：消息及其内容和元数据的列表
zulip_get_topics
获取频道（流）中的主题
必需输入：
channel_id （数字）：流的ID
返回：流中的主题列表
zulip_subscribe_to_channel
将机器人订阅到频道（流）
必需输入：
channel_name (string)：要订阅的流的名称
返回：订阅确认
zulip_get_users
获取 Zulip 组织中的用户列表
返回：用户列表及其基本信息
Related MCP server: Slack MCP Server
创建 Zulip 机器人：
登录您的 Zulip 实例
导航至“设置”>“个人”>“机器人”
点击“添加新机器人”
选择“通用机器人”类型
填写所需信息
点击“创建机器人”
权限：
默认情况下，Zulip 机器人的权限有限
确保为机器人订阅它需要访问的任何流
如果您需要机器人拥有更多权限，请考虑使用完整用户帐户
获取 API 凭证：
机器人的电子邮件地址
机器人的 API 密钥（创建机器人时显示）
Zulip 实例 URL（例如https://example.zulipchat.com ）
将以下内容添加到您的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"
}
}
}
}如果遇到权限错误，请验证：
机器人 API 密钥正确
该机器人已订阅其需要访问的频道
Zulip URL 正确且可访问
Docker 构建：
docker build -t mcp/zulip .此 MCP 服务器根据 MIT 许可证获得许可。
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
