MCP server for managing and sending messages through multiple messaging channels including Slack, Discord, Telegram, Gmail, Naver, SMTP, KakaoTalk, and Microsoft Teams
Server has 4 tools with basic schemas and descriptions, but significant gaps limit production readiness. All tools have descriptions (10-200 chars range) and input schemas with type definitions. However, parameter descriptions are sparse or missing context. add_channel uses elicitation but lacks enum constraints for the 'type' parameter despite supporting only 8 specific channel types. send_message has conditional required parameters (to/subject required for SMTP only) that are not formally documented in the schema. remove_channel and list_channels are minimal. No output schemas documented. Error handling returns JSON but lacks recovery guidance. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels. Naming is verb-first and clear, but parameter naming could be more consistent (e.g., 'channel' vs 'channel_id').
Adds a new messaging channel by collecting configuration through MCP elicitation. Supported types: slack, telegram, gmail, naver, smtp, kakaotalk, microsoft, discord.
Lists all configured messaging channels. Returns channel ID, type, name, and additional metadata such as the sender address for SMTP channels.
Removes a configured messaging channel and its stored data.
Sends a message through a configured channel. For SMTP channels, 'to' (recipient email) and 'subject' parameters are required. For Slack channels, 'target_channel' can override the default channel.
add_channel 'type' parameter lacks enum constraint. Accepts 8 specific values (slack, telegram, gmail, naver, smtp, kakaotalk, microsoft, discord) but schema defines it as free-form string. LLM may hallucinate invalid types.
send_message has undocumented conditional required parameters. 'to' and 'subject' are required for SMTP channels but optional for others. Schema does not express this dependency; LLM cannot infer when these are mandatory.
No output schemas documented for any tool. LLM cannot predict response structure (e.g., does list_channels return array or object? what fields?). Breaks downstream tool chaining.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels. remove_channel is DESTRUCTIVE, list_channels is READ_ONLY, send_message is WRITE. Annotations enable safer agent planning.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 54 | 2026-07-28+ | v2 |
Error responses lack recovery guidance. Code returns JSON with 'status' and 'error' fields but does not suggest next steps (e.g., 'Channel not found. Call list_channels() to see available channels.').