Codex-compatible MCP server for reading, triaging, drafting, and safely sending Zulip messages.
Server has solid schema coverage and clear naming conventions. All 16 tools have descriptions and input schemas with proper type definitions. However, parameter descriptions are largely absent, most parameters lack explanatory text beyond their JSON Schema constraints. Output schemas are not documented. Error handling exists but lacks recovery guidance. Approval workflow is well-designed for write operations, but composition could be tighter (e.g., draft_* and send_* pairs could be unified). Baseline: 194 chars avg description length; this server averages ~80 chars, below median. No tool annotations (readOnlyHint/destructiveHint) despite clear risk stratification.
Add an emoji reaction to a Zulip message after approval passes.
Draft a private Zulip message without sending it.
Draft a stream message without sending it.
Fetch recent messages from a specific Zulip stream topic.
Five workflow tools (summarize_topic, triage_mentions, draft_reply, daily_digest, compose_project_update) have no visible descriptions or input schemas in source. Tool definitions are inferred from file paths only, not explicitly registered with metadata.
Parameter descriptions are missing across all 11 core tools. JSON Schema constraints (minLength, oneOf, etc.) exist, but LLM-facing descriptions explaining what each parameter controls are absent. E.g., 'stream' parameter in list_topics has no description text.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 49 | <=2025-11-25 | v2 |
Return unread Zulip private messages with compact conversation context.
Return unread mentions or likely asks that need review.
List available Zulip streams with ids, names, and subscription metadata.
List topics for a Zulip stream by stream name or stream id.
Search Zulip messages with optional stream and topic narrowing.
Send a Zulip private message after approval passes.
Send a Zulip stream message after approval and allowlist checks pass.
Output schemas are not documented. Tools return JSON but LLMs have no schema reference for what fields to expect. E.g., get_topic_messages returns message objects but the response structure is not declared in tool metadata.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk stratification. Write tools (send_stream_message, send_private_message, add_reaction) should be marked destructiveHint=true; read tools should be marked readOnlyHint=true.
Error messages lack recovery guidance. formatError() in server.ts returns constraint violations (e.g., 'Invalid tool input: stream: must be string or integer') but does not suggest next steps or available alternatives.