Loading ToolBench
An MCP server that enables AI agents to notify users via local voice notifications when tasks complete or require input. Integrates with ntfy for message delivery and Qwen3-TTS or macOS system voice for speech synthesis.
Single tool 'ntfy_publish_message' has a basic schema with 4 parameters (title, message, priority, tags) but critical gaps undermine quality. The tool description (89 chars) is below the 194-char baseline and lacks context on when/why to use it. Parameters lack descriptions entirely, 'priority' is documented as 'Priority level (1-5)' but no guidance on what each level means or consequences. 'tags' parameter description is generic ('Optional tags for the notification'). No output schema documented. No error handling guidance. The tool is a simple write operation but lacks idempotency guarantees, retry semantics, or recovery instructions. Tool name 'ntfy_publish_message' is acceptable (verb_noun pattern) but the implementation is minimal.
Publish a notification message to the ntfy service with title, message content, priority level, and optional tags
Parameter descriptions are missing or trivial. 'priority' lacks explanation of what 1-5 means; 'tags' is generic. LLMs cannot infer valid values or consequences.
No output schema documented. Tool response structure is unknown to the LLM, it cannot plan downstream actions or validate success.
Tool description (89 chars) is below baseline (194 chars) and lacks WHEN/WHY context. Does not explain when to call this vs other notification methods or what happens on failure.
No error handling guidance. Tool is a write operation (WRITE risk) but lacks recovery instructions, retry semantics, or idempotency guarantees.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 43 | <=2025-11-25 | v2 |
Priority parameter accepts integer 1-5 but no enum constraint or explanation of what each level means (e.g., 1=low, 5=urgent). LLMs will guess or hallucinate values.