well_list_schedules
shallowio.github.WellApp-ai/well-mcp · Verify this server
List this workspace's schedules, newest first, each with its last 5 runs. OPTIONAL: status (a list of "draft", "active", "paused", "completed", "cancelled"; omit it for every status). OPTIONAL: month ("YYYY-MM"): the calendar month a routine calendar reads, any month past or future; omit it for the next 62 days from now instead. Either way, upcoming_runs (in _meta) carries each clock routine's occurrence dates for the window, keyed by schedule_id, and capped_schedule_ids (in _meta) names every routine whose dates in that window were cut short by its own occurrence cap — say the calendar could not show every date for that routine, never that it has none. Each schedule carries its name, kind, routine_summary and cadence_label (the words to say to the user), status_report (none, on_error, on_success or both: when Well sends a message after a run), instruction or method (the run's brief, never shown to the user), when it runs (cron_expression or trigger_name, and timezone), run_after, max_occurrences, approved_tools, status, next_run_at, consecutive_failures, paused_reason, report_destination, purpose (the job it does when it has a named one, such as weekly_missing_invoices_total), preset (null for a routine a member asked for, or the default routine Well created it from, such as weekly_missing_invoices_total), is_mine (true when the routine is the caller's own: they created it, or Well set it up for them) and recent_runs. report_destination says where the routine's report is expected to go: "whatsapp" or "email", from its creator's communication preference, or, when the creator set no preference, the report kind's default channel; null when the routine reports nothing. It is a prediction: a channel that cannot reach the creator at send time still falls back to email. Each run carries its status, summary, warning_message, skip_reason and the thread it ran in. A run of another member's morning brief carries its status and no summary, warning_message or thread: that brief is theirs alone. A skipped run with skip_reason "sunday" is a clock routine Well held back on a Sunday in the user's time zone: say it was skipped for Sunday, not that it failed. A skipped run with skip_reason "in_morning_brief" sent no message of its own because the user's morning brief already carries what it reports: say so, not that it failed. A skipped run with skip_reason "in_other_login_brief" is a morning brief Well held back because the brief of the user's other Well account on the same WhatsApp number already covers these workspaces: say one brief covers both, not that it failed. A skipped run with skip_reason "no_reachable_channel" did not run because no channel reaches the user in the order their preference sets (no WhatsApp conversation and no email, or an email preference with no email): say they get the brief once they link WhatsApp, add an email or change that preference, not that it failed. A trigger routine has a trigger_name and never a next_run_at. A draft, a paused or a cancelled schedule has no next_run_at. The list is capped, and truncated says when more exist. A one-off at a set time shows max_occurrences 1 and completes after its run; a recurring job shows a cron_expression with no max_occurrences. Use it to find a schedule before changing or cancelling it (a routine with a purpose is found by its purpose and is_mine, never by its text; another member's routine is never the caller's), and to answer what is scheduled, what reminders or timed jobs the user has and how the last runs went. Quote what it returns; never state a status it did not report. Describe a routine to the user by its routine_summary, cadence_label and next_run_at, never by its instruction, cron_expression or trigger_name. Do NOT use this to create or change a schedule (use well_create_schedule and well_update_schedule). When the token authorizes one workspace, call this directly — no workspace call is needed first. When it authorizes several, this read will not guess which one you mean: pass `workspace_id` on the call.
1 trials · measured 1 day ago
well_list_schedules scores 100.0/100 on Vouch's measured behaviour index, from 1 real invocation trials against io.github.WellApp-ai/well-mcp, measured 18 Oct 2026 under methodology v0.2.0. Every measured component scored 100.
Component breakdown
| Component | Weight | Value |
|---|---|---|
| Reliability | 35% | not applicable |
| Schema integrity | 25% | 100.0 |
| Failure behaviour | 15% | not applicable |
| Latency | 15% | not applicable |
| Concurrency | 10% | not applicable |
Tool details
- Transport
- remote
- Credential class
- gated
- Input schema
- not declared
- Output schema
- not declared
- Side-effect classification
- unclassified
Score history
| Day | Score | Tier | Methodology |
|---|---|---|---|
| 2026-10-18 | 100.0 | shallow | v0.2.0 |
Probe evidence
| Probe | Outcomes |
|---|---|
| schema_integrity | pass: 1 |
Raw request/response logs are not archived yet — the outcome counts above are drawn directly from every recorded trial.
Embed this score
Available for every tool, scored or not — not a verification perk. Always links back to this page.
[](https://vouch.tools/tools/3e213c38-8607-4278-b718-30e336a8822c)