Loading ToolBench
MCP Notifications with SSE server, Next.js webapp, and PocketBase backend. Lightweight Node.js server for sending webhook notifications. Supports Discord, Slack, Teams, Feishu, ntfy, and custom webhooks.
This legacy MCP server exposes 2 notification tools with moderate schema completeness but significant gaps in description clarity and output documentation. The 'notify' tool is straightforward with adequate parameter schemas; 'full_notify' offers advanced features with complex nested structures but lacks output schema documentation. Both tools have descriptions but they are generic and do not explain error handling, prerequisites, or recovery paths. The server is STDIO-only, which severely limits its practical utility in production agentic contexts. Tool naming is reasonable (verb_noun convention) but descriptions fall short of LLM-optimization standards (194-char baseline for A+ tools). No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present. Error handling is not documented in tool definitions.
Send a detailed notification with advanced options (link, image, priority, attachments, actions, template data)
Send a simple notification with body, optional title, and optional template (e.g., 'status', 'question', 'progress', 'problem')
Missing output schema documentation for both tools. LLMs cannot plan downstream actions without knowing what fields are returned (e.g., notification_id, timestamp, status). This violates the tool composition pattern.
Descriptions are generic and do not explain WHEN to use each tool (simple notify vs full_notify), what happens on failure, or recovery paths. Description for 'notify' is only ~110 chars; for 'full_notify' only ~140 chars. Baseline is 194 chars. Neither explains prerequisites (e.g., are credentials required?) or error scenarios.
No tool annotations present. Both tools are destructive (they send notifications) and should carry destructiveHint=true. This prevents agents from reasoning about side effects and retry safety.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | F | 49 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 55 | - | v1 |
Parameter 'template' in 'notify' is required but 'full_notify' makes it required without default. Inconsistent constraint between similar tools. Additionally, enum values (status, question, progress, problem) lack descriptions explaining when to use each.
Complex nested parameter 'actions' in 'full_notify' has conditional logic (http method/headers/body only apply when action='http') but this dependency is not documented. LLMs cannot infer parameter relationships without explicit guidance.
No error handling guidance in tool descriptions. What happens if image upload to Imgur fails? What if a webhook endpoint is unreachable? How should the agent retry? No recovery guidance.