The server implements a single tool 'send' with clear naming and good schema validation using Zod. The tool name correctly starts with a verb (send_), which matches pattern conventions. However, there are gaps in parameter descriptions, missing output schema documentation, and lack of error recovery guidance. The tool description is adequate (52 chars) but parameter descriptions in the schema lack detail about constraints and use cases. The server properly validates inputs via Zod schemas but does not document the validation rules in descriptions for LLM consumption.
Send a notification via Pushover
Parameter descriptions lack constraint details. 'priority' description states 'Priority level from -2 to 2 (optional)' but lacks guidance on what each level means. 'sound' and 'url' descriptions are generic and don't explain expected formats or examples of valid values.
Output schema not documented. The tool returns a TextContent response with success message, but LLMs have no visibility into the response structure. No documentation of what the API returns on success or failure, or what fields the agent can expect.
Error handling lacks recovery guidance. When Pushover API returns an error, the tool throws 'Pushover API error: {JSON}' but does not categorize the error or suggest next steps. LLM has no way to know if the error is retryable, requires user input, or is fatal.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 58 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 46 | - | v1 |
Missing idempotency guidance. The 'send' tool is destructive (sends a notification), but the description and implementation do not clarify whether calling it twice with identical parameters sends twice or is idempotent. Agents may retry on ambiguous failures and duplicate messages.
No rate limiting or timeout guidance. The tool does not set explicit timeouts on the fetch call to Pushover API. A hung API could block the entire agent. No rate limit hints in the description.