Loading ToolBench

Reading the current corpus…

ntfy-me-mcp MCP server · C · ToolBench

ntfy-me-mcp

An ntfy MCP server for sending ntfy notifications to your self-hosted ntfy server from AI Agents (supports secure token auth & more - use with npx or docker!)

2025-06-18+STDIO2 tools

64/100

Definition Quality81

Protocol Readiness47

Supportability48

Spec posture

Inferred effective spec 2025-06-18+·current baseline 2026-07-28

Static source inference · medium confidence · detected: Logging

Deprecated protocol patterns detected

Summary

ntfy-me-mcp provides two well-named, focused tools with comprehensive input schemas and clear descriptions. Both tools start with verbs ('ntfy_me', 'ntfy_me_fetch') and are documented. However, output schemas are entirely undocumented, neither tool specifies what fields are returned, their types, or structure. Parameter descriptions are thorough (72 chars average), but the lack of return type documentation violates a critical pattern (D. SCHEMAS & OUTPUT). Error handling exists but lacks recovery guidance. No tool annotations present. The server demonstrates mid-range quality: good parameter definition but incomplete output contracts.

Tools (2)

ntfy_mewriteauthsource verified84/100

Send a notification to the user via ntfy. Use this tool when the user asks to 'send a notification', 'notify me', 'send me an alert', 'message me', 'ping me', or any similar request. This tool is perfect for sending status updates, alerts, reminders, or notifications about completed tasks.

ntfy_me_fetchread onlyauthsource verified77/100

Fetch cached messages from an ntfy server topic. Use this tool when the user asks to 'show notifications', 'get my messages', 'show my alerts', 'find notifications', 'search notifications', or any similar request. Great for finding recent notifications, checking message history, or searching for specific notifications by content, title, tags, or priority.

Issues (5)

CRITICALD. SCHEMAS & OUTPUT ↗

Output schemas completely undocumented. Neither tool specifies return type, fields, or structure. LLMs cannot plan downstream operations or extract data reliably without knowing what to expect.

ntfy_mentfy_me_fetch

HIGHProtocol Readiness: Tool Annotations ↗

No tool annotations present. Tools lack readOnlyHint, destructiveHint, or idempotentHint. ntfy_me modifies state (sends notification) but LLM cannot detect this from tool definition alone.

ntfy_mentfy_me_fetch

HIGHE. ERROR HANDLING ↗

Error handling provides no recovery guidance. Tools throw errors but do not tell the LLM what to do next or how to self-correct. E.g., invalid priority should return 'Got X, must be one of: min, low, default, high, max' not a bare error.

ntfy_mentfy_me_fetch

MEDIUMD. SCHEMAS & OUTPUT ↗

ntfy_me_fetch accepts complex filtering (messageId, messageText, messageTitle, priorities, tags) but no result limit or pagination declared. Could return unbounded results, exhausting context window.

Recommendations

Add documented output schema to ntfy_me: specify returned fields (e.g., message_id, status, timestamp, topic, url) and types. Example: {"type": "object", "properties": {"message_id": {"type": "string"}, "status": {"type": "string", "enum": ["success", "queued"]}, "topic": {"type": "string"}, "timestamp": {"type": "string", "format": "date-time"}}}
Add documented output schema to ntfy_me_fetch: specify returned message list structure, including per-message fields (id, title, message, priority, tags, timestamp) and total count or next cursor for pagination.
Add tool annotations: register ntfy_me with destructiveHint=true (sends external notification), register ntfy_me_fetch with readOnlyHint=true (read-only fetch). Use MCP SDK's tool annotation API.
Enhance error messages with recovery guidance. Wrap validation errors with actionable hints: 'Invalid priority "urgent", must be one of: min, low, default, high, max. Retrying with default.' Similarly for ntfy_me_fetch: 'No messages found with tags "error". Available tags in topic: warning, success, info.'
Document result limits for ntfy_me_fetch. Add to description: 'Returns up to 50 most recent messages. Use the since parameter to paginate older messages.' Implement client-side cap if needed.
Add validation examples in parameter descriptions. E.g., topic: 'ntfy topic name (alphanumeric + dashes, e.g., my-alerts, status-updates)', url: 'ntfy server URL (e.g., https://ntfy.sh or https://ntfy.example.com)'.
Clarify markdown parameter for ntfy_me: 'When true, the message field is parsed as CommonMark and rendered with formatting. Plain text is treated as literal markdown syntax if not escaped.'

Spec posture evidence

Inferred effective spec: 2025-06-18+.

Relies on Logging (deprecated) - log to stderr or use OpenTelemetry

Score history

Overall score trend

↑ 18 points across a rubric change (v1 → v2)

64/100

Scored	Grade	Overall	Spec posture	Rubric
2026-09-22	C	64	2025-06-18+	v2
2026-03-09	F	46	-	v1