The server defines 6 tools with complete JSON Schema input definitions and descriptions, but has significant gaps in parameter-level documentation, output schema clarity, and error handling guidance. Tool naming follows verb_noun convention well (check_, add_, update_, remove_, change_, get_). However, parameter descriptions are minimal or missing in several tools, and output schemas are undocumented. The server lacks actionable error messages, recovery guidance, and confirmation patterns for destructive operations. Tool definitions are explicitly visible in the source code with proper schema registration via FastMCP decorators.
Add a new subscriber to Listmonk. Args: email: Subscriber email address name: Subscriber name lists: List of mailing list IDs to subscribe to status: Subscriber status (enabled, disabled, blocklisted) attributes: Custom subscriber attributes preconfirm: Whether to preconfirm subscriptions
Change subscriber status. Args: subscriber_id: ID of the subscriber status: New status (enabled, disabled, blocklisted)
Check if Listmonk server is healthy and accessible.
Get all mailing lists. Returns a list of all mailing lists with their IDs, UUIDs, names, subscriber counts, and types.
Remove a subscriber from Listmonk. Args: subscriber_id: ID of the subscriber to remove
Output schemas are not documented. Tools return free-text strings instead of structured objects. LLMs cannot parse responses to extract IDs for chaining calls.
Parameter descriptions are vague or missing context. 'status' parameter lacks enum constraint or valid value documentation; 'lists' parameter lacks explanation of list ID format; 'attributes' is generic without examples or constraints.
Destructive operations (remove_subscriber) lack confirmation/dry-run patterns. No guidance for LLM on whether the operation is safe to retry or has irreversible consequences.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Update an existing subscriber. Args: subscriber_id: ID of the subscriber to update email: New email address name: New name status: New status (enabled, disabled, blocklisted) lists: New list of mailing list IDs attributes: New custom attributes
Error handling is generic. The safe_execute_async() wrapper catches exceptions but does not provide actionable recovery guidance. LLM receives no hint about what went wrong or what to do next.
update_subscriber has all optional parameters except subscriber_id. Partial update semantics are undocumented, does omitting 'email' preserve the current email or clear it? This ambiguity invites bugs.
get_subscriber_by_id resource is partially implemented (code is cut off). Pagination, limit constraints, and output schema are not visible. Cannot assess full resource quality.
No enum constraints on 'status' parameter across add_subscriber, update_subscriber, change_subscriber_status. Description mentions valid values (enabled, disabled, blocklisted) but schema lacks enum definition. LLMs will hallucinate invalid statuses.