Zulip API 用の MCP サーバー。Claude などの AI アシスタントが Zulip ワークスペースと対話できるようになります。
zulip_list_channels
Zulip 組織内の利用可能なチャンネル（ストリーム）を一覧表示します
オプション入力:
include_private (ブール値、デフォルト: false): プライベートストリームを含めるかどうか
include_web_public (ブール値、デフォルト: true): Web公開ストリームを含めるかどうか
include_subscribed (ブール値、デフォルト: true): ボットが購読しているストリームを含めるかどうか
戻り値: IDと情報を含むストリームのリスト
zulip_post_message
Zulip チャンネル (ストリーム) に新しいメッセージを投稿する
必要な入力:
channel_name (文字列): 投稿先のストリームの名前
topic (文字列): ストリーム内のトピック
content (文字列): 投稿するメッセージの内容
戻り値: メッセージ投稿の確認とID
zulip_send_direct_message
1人または複数のユーザーにダイレクトメッセージを送信する
必要な入力:
recipients (文字列[]): 受信者のメールアドレスまたはユーザーID
content (文字列): 送信するメッセージの内容
戻り値: メッセージ送信確認とID
zulip_add_reaction
メッセージに絵文字リアクションを追加する
必要な入力:
message_id (数値): 反応するメッセージのID
emoji_name (文字列): コロンを除いた絵文字名
返品：反応確認
zulip_get_channel_history
チャンネル（ストリーム）とトピックから最近のメッセージを取得する
必要な入力:
channel_name (文字列): ストリームの名前
topic (文字列): トピック名
オプション入力:
limit （数値、デフォルト：20）：取得するメッセージの数
anchor （文字列、デフォルト："newest"）：開始するメッセージID
戻り値: メッセージとその内容およびメタデータのリスト
zulip_get_topics
チャンネル（ストリーム）内のトピックを取得する
必要な入力:
channel_id (数値): ストリームのID
戻り値: ストリーム内のトピックのリスト
zulip_subscribe_to_channel
ボットをチャンネル（ストリーム）に登録する
必要な入力:
channel_name (文字列): 購読するストリームの名前
返品: サブスクリプションの確認
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
