Loading ToolBench
Phone Alert MCP that gives a calling LLM a tool to physically buzz the user's phone. The server pushes alerts to ntfy and/or Pushover backends, and can place SIP calls via baresip.
Single-tool server with a well-defined alert_me tool. The tool has a clear verb-noun name (alert_me), comprehensive description (321 chars), and detailed parameter documentation including severity levels and use-case guidance. Input schema is properly structured with types and descriptions. However, output schema is not documented (tool description doesn't explain what the call returns), and error handling guidance is minimal. The tool's description is exceptionally well-written for LLM reasoning (includes severity semantics, decision criteria, and real-world examples), but lacks actionable recovery paths when calls fail.
Physically buzz the user's phone with an urgent push notification. The user is NOT watching the screen. Calling this interrupts them in the real world, so use it only when that interruption is justified.
Output schema not documented. Tool description does not specify what alert_me returns on success or failure (e.g., confirmation ID, delivery status, error details). LLMs cannot infer return structure and may fail to handle responses.
No error recovery guidance. Tool description lacks actionable error messages. When alert fails (e.g., network timeout, invalid credentials, rate limit), LLM receives no guidance on whether to retry, escalate, or skip. Pattern requires: 'Error responses must tell the LLM what to do next.'
No idempotency guarantee documented. Sending an alert twice should be idempotent (same request = same alert, not duplicate notifications). The tool description doesn't guarantee this, risking duplicate buzzes if agent retries on timeout.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 62 | 2026-07-28+ | v2 |
Parameter 'severity' has good enum semantics, but 'message' and 'title' lack format constraints. No mention of max length, character restrictions, or format requirements. LLMs may pass excessively long or special-character-laden strings that break rendering or cause API errors.