This is a STDIO-only server with 4 tools. While tool registration is visible and schemas are present using Zod, there are critical definition gaps: (1) tool descriptions lack LLM-optimized context and contain anti-patterns (example values, unclear when to use each tool); (2) parameter descriptions are minimal or absent; (3) no output schema documentation; (4) error handling provides no recovery guidance; (5) the server relies on external state (cron-job.org API, Slack/Telegram webhooks) without documenting prerequisites or failure modes. The baseline for most community servers is 40-60; this falls in the poor (D) range due to missing descriptions, incomplete parameter docs, and lack of error guidance despite having visible schemas.
Tools (4)
create-reminderwriteauthsource verified60/100
Create a reminder
You MUST call this function before 'get-current-time' to obtain the current time.
Descriptions lack LLM-optimized context and contain misleading instructions. 'create-reminder' tells LLMs 'You MUST call this function before get-current-time', this is an implementation detail, not a user-facing instruction. LLMs should decide call order, not be dictated by tool text.
Parameter descriptions are sparse or missing. 'title' in create-reminder has a description, but 'deletionType' and 'title' in delete-reminder lack context (e.g., what happens when deletionType='processed'? Are processed reminders auto-marked, or is this a custom state?). LLMs cannot infer semantics.
No output schema documentation. Callers don't know what get-reminders, get-current-time, create-reminder, or delete-reminder return. LLMs cannot plan downstream calls or extract required fields (e.g., does create-reminder return job_id? Does get-reminders return enabled/disabled status?).
Expand tool descriptions to 50-150 chars following the pattern: '[ACTION] [CONTEXT]. Returns [RESULT]. Requires: [PREREQUISITES]. [SIDE EFFECTS if any].' Example for create-reminder: 'Schedule a reminder to trigger at a specific date/time via Slack or Telegram. Requires cron-job.org API credentials and notification platform setup.'
Add output schema documentation to every tool. Example for create-reminder: 'Returns { jobId: number, title: string, schedule: { ... }, url: string }.' For get-reminders: 'Returns { jobs: Array<{ id: number, title: string, enabled: boolean, schedule: { ... }, lastExecution: Date | null }>, total: number }.'
Enhance parameter descriptions with constraints and semantics. For delete-reminder.title: 'The reminder title to delete. Required if deletionType is "title". Case-sensitive.' For delete-reminder.deletionType: 'Deletion scope. "title" deletes matching title; "processed" deletes reminders marked as completed; "all" deletes all reminders (irreversible).'
Remove prescriptive language from tool descriptions. Delete 'You MUST call this function before get-current-time' from create-reminder. LLMs should decide orchestration. If datetime must be in a specific timezone, document it in the parameter description instead.
Document dependencies and error paths. Add a note to create-reminder: 'If cron-job.org API key is invalid or notification platform is misconfigured, creation will fail with a platform error. Ensure CRON_JOB_API_KEY and NOTIFICATION_PLATFORM env vars are set before calling.'
Error handling provides no recovery guidance. If create-reminder fails due to invalid datetime format, invalid cron-job.org credentials, or notification platform misconfiguration, the handler (not visible here) likely returns a raw error. LLMs get no actionable next steps.
Tools lack destructive operation warnings in descriptions. delete-reminder is destructive (removes reminders permanently) but its description does not state this or warn about irreversibility. LLMs should know which calls have permanent consequences.
Parameter naming lacks explicitness. 'datetime' in create-reminder is clear, but delete-reminder uses 'deletionType' (enum) + 'title' (optional string). If deletionType='title' but title is omitted, what happens? The description says 'required if deletionType is title' but the schema marks it optional. This ambiguity invites LLM errors.
Tools depend on external services (cron-job.org API, Slack/Telegram webhooks) without documenting prerequisites, authentication, or failure modes. The descriptions do not mention environment setup (CRON_JOB_API_KEY, NOTIFICATION_PLATFORM, SLACK_WEBHOOK_URL/TELEGRAM_BOT_TOKEN). An LLM calling these tools has no awareness of infrastructure requirements.
create-reminderdelete-reminderget-reminders
Mark destructive operations explicitly. Update delete-reminder description to start with: '[DESTRUCTIVE] Delete reminders...' or add a note: 'WARNING: Deletion is permanent and cannot be undone. Consider fetching reminders first to confirm target before deleting.'
Clarify enum semantics. For delete-reminder.deletionType, expand the description to explain each option: '"title", delete reminder(s) by exact title match; "processed", delete all reminders marked as sent/completed; "all", delete every reminder in the account (irreversible).'
Validate inputs and return actionable errors. If datetime is malformed, return 'Invalid datetime: expected ISO 8601 format (YYYY-MM-DDTHH:mm:ss), got "2024-13-45". Use create-reminder with a valid future date.' If API key is missing, return 'CRON_JOB_API_KEY environment variable not set. Configure it and restart the server.'
Consider adding a 'dry-run' or 'preview' parameter to delete-reminder to let LLMs confirm which reminders match before destructive action: 'dry_run: boolean (optional, default false). If true, returns matching reminders without deleting.'
Add pagination to get-reminders if the job list is large. Return { jobs: [...], total: number, limit: number, offset: number } and accept optional limit and offset parameters.