Servidor MCP para la API de Zulip, que permite que los asistentes de IA como Claude interactúen con los espacios de trabajo de Zulip.
zulip_list_channels
Enumere los canales (transmisiones) disponibles en la organización Zulip
Entradas opcionales:
include_private (booleano, valor predeterminado: falso): si se deben incluir transmisiones privadas
include_web_public (booleano, valor predeterminado: verdadero): si se deben incluir transmisiones web públicas
include_subscribed (booleano, valor predeterminado: verdadero): si se deben incluir las transmisiones a las que está suscrito el bot
Devuelve: Lista de transmisiones con sus identificaciones e información
zulip_post_message
Publicar un nuevo mensaje en un canal de Zulip (transmisión)
Entradas requeridas:
channel_name (cadena): El nombre de la transmisión en la que se publicará
topic (cadena): El tema dentro de la secuencia
content (cadena): el contenido del mensaje a publicar
Devoluciones: Confirmación de publicación del mensaje e ID
zulip_send_direct_message
Envía un mensaje directo a uno o más usuarios
Entradas requeridas:
recipients (cadena[]): direcciones de correo electrónico o ID de usuario de los destinatarios
content (cadena): El contenido del mensaje a enviar
Devoluciones: Confirmación de envío del mensaje e ID
zulip_add_reaction
Agregar una reacción emoji a un mensaje
Entradas requeridas:
message_id (número): El ID del mensaje al que se debe reaccionar
emoji_name (cadena): nombre del emoji sin dos puntos
Devoluciones: Confirmación de reacción
zulip_get_channel_history
Obtener mensajes recientes de un canal (transmisión) y tema
Entradas requeridas:
channel_name (cadena): El nombre de la transmisión
topic (cadena): el nombre del tema
Entradas opcionales:
limit (número, predeterminado: 20): Número de mensajes a recuperar
anchor (cadena, valor predeterminado: "más nuevo"): ID del mensaje desde el que comenzar
Devuelve: Lista de mensajes con su contenido y metadatos
zulip_get_topics
Obtener temas en un canal (transmisión)
Entradas requeridas:
channel_id (número): El ID de la transmisión
Devuelve: Lista de temas en la secuencia
zulip_subscribe_to_channel
Suscribir el bot a un canal (transmisión)
Entradas requeridas:
channel_name (cadena): el nombre de la transmisión a la que suscribirse
Devoluciones: Confirmación de suscripción
zulip_get_users
Obtener la lista de usuarios de la organización Zulip
Devuelve: Listado de usuarios con su información básica
Related MCP server: Slack MCP Server
Crear un bot Zulip:
Inicie sesión en su instancia de Zulip
Vaya a Configuración > Personal > Bots
Haga clic en "Agregar un nuevo bot"
Seleccione el tipo "Bot genérico"
Complete la información requerida
Haga clic en "Crear bot"
Permisos:
De forma predeterminada, los bots de Zulip tienen permisos limitados
Asegúrate de suscribir el bot a todas las transmisiones a las que necesita acceder.
Si necesita que el bot tenga más permisos, considere usar una cuenta de usuario completa en su lugar
Obtenga las credenciales de la API:
Dirección de correo electrónico del bot
Clave API del bot (se muestra cuando creas el bot)
URL de instancia de Zulip (por ejemplo, https://example.zulipchat.com )
Agregue lo siguiente a su 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"
}
}
}
}Si encuentra errores de permisos, verifique que:
La clave API del bot es correcta
El bot se ha suscrito a los canales a los que necesita acceder.
La URL de Zulip es correcta y accesible
Compilación de Docker:
docker build -t mcp/zulip .Este servidor MCP tiene licencia 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
