Official MCP server for FastAlert, providing tools to list channels and send notifications.
FastAlert MCP server demonstrates good tool definition quality with proper naming conventions, detailed descriptions, and complete input schemas. Both tools follow verb_noun patterns (list_channels, send_message). Descriptions are LLM-optimized and contextual. Input parameters have types and descriptions. However, output schemas are not documented, error handling lacks recovery guidance, and tool annotations are absent. The server shows solid fundamentals but misses advanced patterns expected of production-grade tools.
List all channels accessible to the user. Can optionally filter by channel name to find specific channels. Returns channel details including UUID, name, and subscriber count. Use this to find channel UUIDs when users refer to channels by name.
Send a message/alert to one or more channels. Requires channel UUIDs (use list_channels first if you only have channel names). Supports optional actions like call buttons, email links, website links, or images.
Output schemas not documented. Tool descriptions state what is returned ('channel details including UUID, name, and subscriber count' for list_channels, implicit success for send_message) but the actual JSON response structure is not declared. LLMs cannot reliably plan downstream tool calls or extract fields without knowing the response schema.
Missing error handling guidance. send_message is a destructive operation (sends messages to live channels) but provides no error recovery instructions, no retryable vs fatal error classification, and no validation error examples. An agent encountering a channel UUID validation failure or API error has no guidance on recovery.
Missing tool annotations. Neither tool has readOnlyHint, destructiveHint, or idempotentHint annotations. send_message modifies state (sends messages) and should be marked destructive, but the schema does not declare this via annotations. This prevents agents and clients from enforcing approval workflows or rate limiting on sensitive operations.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 62 | <=2025-11-25 | v2 |
send_message has mutually exclusive parameters that are not documented. The 'action' enum is 'call|email|website|image', and 'action_value' provides the value. But when action='image', is the 'image' parameter also required? Are 'action' and 'image' mutually exclusive or complementary? The schema is ambiguous.
list_channels filter is optional but no guidance on discovery. The description mentions 'partial matches are supported' but does not explain pagination behavior if results exceed a limit. Does a partial name match return 10, 100, or all channels? An agent searching for 'alert' could receive thousands of results, degrading reasoning.
send_message does not confirm before destructive action. Sending alerts to multiple channels is irreversible and high-impact. The tool lacks a dry-run mode or explicit confirmation step, risking accidental mass alerts if an agent misinterprets user intent.