CLI and MCP server for DoubleTick email read tracking
The server defines 3 tools with consistent Zod schemas and descriptions. Naming follows verb_noun pattern (send_tracked_email, check_tracking_status, list_tracked_emails). However, descriptions are brief (average ~150 chars) and lack critical context about prerequisites, output structure, and error recovery. Parameters are typed but descriptions are minimal. No documented output schemas. Error handling returns plain text rather than structured guidance. The tool composition is reasonable but lacks depth in parameter constraints and chaining guidance.
Check if a tracked email has been opened. Returns open count, device info, and timestamps.
List recent tracked emails with their open status.
Send an email with read tracking via Gmail. Body accepts markdown (converted to HTML automatically). The email is sent immediately via Gmail API.
No output schemas documented. Tool descriptions do not specify what fields or structure to expect from responses. LLMs cannot plan downstream chaining without knowing return types.
Parameter descriptions are minimal and lack actionable constraints. 'Tracking ID returned from send_tracked_email' assumes prior successful send; no guidance on format, length, or valid value ranges. 'limit' parameter has no minimum/maximum bounds stated in description.
Error handling returns plain-text messages without recovery guidance. 'Not authenticated. Run `doubletick login` in the terminal first.' is user-facing, not LLM-actionable. No categorization (retryable vs. user-fixable vs. fatal).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 62 | 2026-07-28+ | v2 |
| 2026-03-09 | C | 61 | - | v1 |
Tool descriptions lack prerequisites and context. No mention that authentication is required upfront. No indication that send_tracked_email has irreversible side effects (email sent immediately). No guidance on when to use check_tracking_status vs. list_tracked_emails.
send_tracked_email accepts 'cc' and 'bcc' as comma-separated strings but provides no regex pattern or length constraint in the description. LLMs may pass invalid email lists.
No idempotence guarantees. send_tracked_email performs immediate send on every call, no dry-run or confirmation step. If an LLM retries on ambiguous failure, emails are sent multiple times.
Response text is unstructured. check_tracking_status and list_tracked_emails return free-form text strings for parsing. No JSON structure means LLMs cannot reliably extract trackingId, openCount, device info, or email subjects for downstream operations.