Which integrations are available for this server?

Provides tools to read and write Apple Reminders via iCloud CalDAV, allowing management of reminder lists and individual reminders.

How do I use icloud-reminders-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@icloud-reminders-mcp list today's reminders from my Work list" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

icloud-reminders-mcp

by Lingnik

Overview Schema Source Related Servers Discussions Admin

Python

Remote

icloud-reminders-mcp

A local MCP server that gives an AI agent (e.g. Claude Code) read + write access to Apple Reminders over iCloud CalDAV — no Mac required. It talks only to Apple's servers and the local MCP client, and manages the same reminder lists that sync to your iPhone/iPad, including lists shared via Family Sharing.

Reminders are VTODO items in CalDAV; each reminder list is a task-capable calendar collection. Calendar events (VEVENT), Contacts, Mail, and Notes are out of scope.

IMPORTANT

Viability depends on your account. Since iOS 13 / macOS 10.15, Apple moved Reminders to a newer (CloudKit) store. Only reminder lists that were never "upgraded" to the new format remain reachable over CalDAV. On some accounts that is zero lists. Run scripts/doctor.py (below) once before relying on this — it is a go/no-go probe. Apple may remove CalDAV access at any time; this is an undocumented, partially-compliant surface.

Why CalDAV (and not `pyicloud`)

Apple exposes no REST/JSON API for Reminders. CalDAV (RFC 4791) is the only official-protocol, cross-platform route. Auth is a static app-specific password — no interactive 2FA, no token refresh. We deliberately avoid pyicloud (a private web API that broke on Apple's SRP-6a auth change).

Related MCP server: Apple Reminders MCP Server

Requirements

Python 3.11+
An Apple ID with an app-specific password (see below)
uv (recommended) or pip + venv

Install

git clone https://github.com/Lingnik/icloud-reminders-mcp
cd icloud-reminders-mcp
uv venv && uv pip install -e ".[dev]"

Generate an app-specific password

Sign in at appleid.apple.com.
Sign-In & Security → App-Specific Passwords → Generate.
Label it (e.g. icloud-reminders-mcp). You get xxxx-xxxx-xxxx-xxxx.
This is the kill switch: revoke it there to instantly cut access. Changing your Apple ID password also invalidates it.

An app-specific password is all-or-nothing — it grants access to your whole iCloud account at Apple's end, not just Reminders. Treat it as a secret, and see SECURITY.md.

Configure

Configuration is via environment variables only (never committed). Copy .env.example to .env and fill it in, or — preferred on a host with 1Password CLI — keep the real values in 1Password and inject them at launch:

# ~/.secrets holds op:// references, not secrets:
#   ICLOUD_USERNAME="op://<vault>/icloud-reminders-mcp/username"
#   ICLOUD_APP_PASSWORD="op://<vault>/icloud-reminders-mcp/password"
op run --env-file ~/.secrets -- icloud-reminders-mcp

Variable	Required	Default	Purpose
`ICLOUD_USERNAME`	yes	—	Apple ID email
`ICLOUD_APP_PASSWORD`	yes	—	App-specific password (`xxxx-xxxx-xxxx-xxxx`)
`ICLOUD_CALDAV_URL`	no	`https://caldav.icloud.com/`	Root URL; the library discovers your account's `pNN` shard from it — do not hardcode a shard
`REMINDERS_ALLOW_DELETE`	no	`false`	Enable the destructive `delete_reminder` tool
`REMINDERS_LIST_ALLOWLIST`	no	(all)	Comma-separated list names the server may touch
`ICLOUD_REQUEST_TIMEOUT`	no	`30`	Per-request timeout (seconds)

Go/no-go probe

Run once against your real account to confirm CalDAV reachability and a full create → read → complete → delete round-trip:

op run --env-file ~/.secrets -- python scripts/doctor.py --list "Reminders"

It fails loudly if no VTODO-capable list is found, and reports which fields survived the round-trip. It is never run in CI. After it succeeds, confirm the throwaway reminder appeared (and cleared) on your iPhone.

Use with Claude Code

Add to your MCP config (e.g. ~/.claude/mcp.json or via claude mcp add). Using 1Password so no secret is written into the config file:

{
  "mcpServers": {
    "icloud-reminders": {
      "command": "op",
      "args": [
        "run", "--env-file", "/home/you/.secrets", "--",
        "uv", "--directory", "/home/you/git/icloud-reminders-mcp", "run",
        "icloud-reminders-mcp"
      ]
    }
  }
}

If you would rather put values inline (less safe), set them under "env" and call uv directly:

{
  "mcpServers": {
    "icloud-reminders": {
      "command": "uv",
      "args": ["--directory", "/home/you/git/icloud-reminders-mcp", "run", "icloud-reminders-mcp"],
      "env": {
        "ICLOUD_USERNAME": "you@icloud.com",
        "ICLOUD_APP_PASSWORD": "xxxx-xxxx-xxxx-xxxx",
        "REMINDERS_ALLOW_DELETE": "false"
      }
    }
  }
}

Tools

Tool	Type	Purpose
`list_lists`	read	Reminder lists (`list_id`, `list_name`, url, count)
`list_reminders`	read	Filter by list / completed / due range; paginated (`limit`/`offset`)
`get_reminder`	read	One reminder by uid
`create_reminder`	write	New VTODO (title, list, due, notes, priority, url)
`complete_reminder`	write	Mark complete
`update_reminder`	write	Patch fields; preserves everything it doesn't manage
`delete_reminder`	destructive	Gated by `REMINDERS_ALLOW_DELETE` and `confirm: true`

Reminder JSON shape (normalized from VTODO):

{
  "uid": "…", "list_id": "…", "list_name": "Family TODOs", "list_url": "…",
  "title": "…", "notes": "…|null",
  "due": "2026-07-10T09:00:00-07:00|2026-07-10|null", "due_all_day": false,
  "completed": false, "completed_at": "…|null",
  "priority": 0, "priority_label": "none|low|medium|high",
  "percent_complete": 0, "url": "…|null",
  "created": "…", "modified": "…", "etag": "…"
}

Notes on the model:

Lists are keyed by list_id (stable, URL-derived), with list_name as a mutable label. Tools accept either an id or a name.
Priority is the raw iCalendar 0–9 integer plus a friendly label. Apple's UI only has none/low/medium/high and will collapse arbitrary integers to 1/5/9 when you edit in the app — fidelity beyond the four buckets is not guaranteed.
Updates preserve unknown properties. update_reminder/complete_reminder parse the existing VTODO and mutate only known fields, so RRULE, VALARM, RELATED-TO (subtasks), and X-APPLE-* extensions survive. Editing recurrence/subtasks is not supported in v1 (they're preserved, not managed).
Update field semantics: an omitted/null field is left unchanged; pass an empty string ("") to clear notes, due, or url.

Development

uv run ruff check .
uv run pytest

Tests are network-free: pure mapping/config unit tests plus a fake-CalDAV layer exercising discovery filtering, pagination, ETag-conflict retry, and delete gating. Fixtures are synthetic — never captured from a real account.

Troubleshooting

No lists found / empty. Most likely the CloudKit-upgrade issue above. Try a list you know is old, or one freshly created that you have not migrated.
401 / auth rejected. You're using your Apple ID password, not an app-specific password, or it was revoked/expired. Generate a new one.
PROPFIND hangs / flaky connects. A known iCloud quirk on dual-stack hosts; try forcing IPv4 or IPv6 (e.g. disable one stack, or set a hosts/route preference) and retry. Raise ICLOUD_REQUEST_TIMEOUT if needed.
A field didn't stick. iCloud may normalize or drop properties on write. The doctor script's round-trip report tells you what your account actually preserves.

License

MIT — see LICENSE.

Available Tools

7 tools

complete_reminderA

Idempotent

Mark a reminder complete (STATUS:COMPLETED + COMPLETED + PERCENT-COMPLETE:100).

ParametersJSON Schema

Name	Required	Description	Default
`uid`	Yes
`list`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond annotations (idempotentHint=true, readOnlyHint=false), the description adds specific state changes (STATUS, PERCENT-COMPLETE), though it does not detail other behavioral aspects like side effects on related items.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence with essential details front-loaded. The parenthetical addition adds precise status changes without extra verbiage. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Adquate for a simple write operation with output schema present, but lacks parameter explanations and usage guidance. With only 2 params and 0% schema coverage, more parameter context would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the description provides no explanation of the 'uid' and 'list' parameters. The agent cannot infer the meaning or required format from the description alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action: 'Mark a reminder complete' with specific status fields (STATUS:COMPLETED, PERCENT-COMPLETE:100), distinguishing it from siblings like update_reminder which would modify other fields.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implied usage for completing reminders, but no explicit guidance on when to use this tool vs siblings like update_reminder or delete_reminder. Does not mention prerequisites or when not to use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

create_reminderB

Create a reminder (VTODO). list is required unless exactly one exists.

due is an ISO-8601 date (all-day) or datetime with timezone.

ParametersJSON Schema

Name	Required	Description	Default
`due`	No
`url`	No
`list`	No
`notes`	No
`title`	Yes
`priority`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate a write operation (readOnlyHint=false) and open-world hint. The description adds minimal behavioral context beyond 'VTODO' type. No disclosure of side effects or auth requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise: two sentences, front-loaded with action, no unnecessary words. Efficiently delivers key parameter notes.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 6 parameters, a required parameter, and an output schema (unknown), the description is too brief. It lacks context on what a reminder is, how to use other parameters, or response details. Incomplete for a creation tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so description must compensate. It explains 'list' and 'due' meaningfully but omits descriptions for 'url', 'notes', 'priority', and 'title'. Partial coverage (2 of 6 parameters) rescues from lower score.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (create) and resource (reminder, VTODO). It distinguishes from sibling tools (complete, delete, get, lists, update) by being the creation tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives a guideline for the 'list' parameter (required unless one exists) but does not provide explicit when-to-use or when-not-to-use guidance compared to alternatives. Usage is implied but not elaborated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

delete_reminderA

Destructive

Permanently delete a reminder. Gated: requires REMINDERS_ALLOW_DELETE=true on the server AND an explicit confirm=true argument.

ParametersJSON Schema

Name	Required	Description	Default
`uid`	Yes
`list`	No
`confirm`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.2/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Describes permanent deletion and gating conditions, which go beyond annotations that already indicate destructiveHint=true. Adds context about the required server setting and confirmation flag.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no wasted words, front-loaded with purpose. Highly concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers gating and confirm requirement but lacks parameter descriptions. Output schema exists but not referenced. Adequate but not fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only mentions confirm parameter in description; uid and list are not described. With 0% schema coverage, description should compensate more.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states 'Permanently delete a reminder' with specific resource and verb. No ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Specifies two explicit conditions: server flag REMINDERS_ALLOW_DELETE=true and confirm=true argument. Does not explicitly mention when not to use, but conditions serve as clear guidelines.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_reminderA

Read-only

Fetch a single reminder by its uid (optionally scoped to one list).

ParametersJSON Schema

Name	Required	Description	Default
`uid`	Yes
`list`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint and openWorldHint. The description adds that the list parameter is optional for scoping, which provides some behavioral context beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence with no wasted words, front-loading the core action and key parameter.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema covers return values, the description adequately defines purpose and parameter roles. However, it could briefly note that 'uid' must be unique and contrast with 'list_reminders' for completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must explain parameters. It clarifies 'uid' as the identifier and 'list' as optional scoping, but lacks details on format or allowed values.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'Fetch' and identifies the resource 'reminder' with its key 'uid', clearly distinguishing it from sibling tools like 'list_reminders' which fetches multiple reminders.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when a single reminder is needed by uid, but does not explicitly state when not to use it or mention alternatives like 'list_reminders' for multiple reminders.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_listsA

Read-only

List the iCloud reminder lists (VTODO collections) this server can see.

Returns each list's stable list_id, mutable list_name, URL, and item count.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate read-only and open-world behavior. The description adds value by detailing the exact fields returned (list_id, list_name, URL, item count), providing transparency beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences with no wasted words. The purpose is front-loaded, and the second sentence adds necessary detail about the output structure.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero parameters and the presence of an output schema, the description fully covers what the tool does and what it returns. No gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters; schema coverage is 100% (no params). The description appropriately focuses on output, earning the baseline score of 4 for parameter-less tools.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the action (list) and resource (iCloud reminder lists/VTODO collections). It clearly distinguishes from sibling tools like list_reminders by specifying the resource type.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implicitly clear when to use: to get the list of reminder collections. No explicit exclusions or alternatives, but given the tool's simplicity and zero parameters, this is adequate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_remindersA

Read-only

List reminders, earliest-due first (undated last). Defaults to incomplete only.

list accepts a list_id or display name (all lists if omitted). due_before / due_after are ISO-8601 dates or datetimes. Results are paginated via limit/offset; the response includes total and a truncated flag.

ParametersJSON Schema

Name	Required	Description	Default
`list`	No
`limit`	No
`offset`	No
`completed`	No
`due_after`	No
`due_before`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide readOnlyHint and openWorldHint. The description adds concrete behavioral details: default ordering, default filtering (incomplete only), pagination via limit/offset with total and truncated flag, and date format requirements. Minor omission: no mention of error handling or empty results.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: two sentences plus parameter details. Every word adds value, with purpose front-loaded. No extraneous information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema (total and truncated flag mentioned), the description covers key aspects: ordering, filtering, pagination, date formats. Minor gap: does not specify default limit value or explain behavior for duplicate due dates. Still adequate for a list tool with 6 parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description compensates by explaining the list parameter (accepts list_id or display name), due date parameters (ISO-8601), and pagination (limit/offset). However, the completed parameter is only indirectly described via 'Defaults to incomplete only' and limit's default value is not restated.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists reminders and specifies ordering (earliest-due first, undated last) and default filtering (incomplete only). It distinguishes from sibling tools like get_reminder (single reminder) and list_lists (lists).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies this tool is for listing multiple reminders but does not explicitly state when to use it versus alternatives like get_reminder or list_lists. No when-not or alternative tool mentions are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

update_reminderA

Idempotent

Patch mutable fields of a reminder, preserving everything else.

Omitted/null fields are left unchanged; pass an empty string ("") to clear notes, due, or url. Set completed true/false to complete/reopen. Uses ETag optimistic concurrency and retries on conflict.

ParametersJSON Schema

Name	Required	Description	Default
`due`	No
`uid`	Yes
`url`	No
`list`	No
`notes`	No
`title`	No
`priority`	No
`completed`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate a write operation (readOnlyHint=false) and idempotency (idempotentHint=true). The description adds valuable behavioral details: ETag optimistic concurrency, retries on conflict, and the patch semantics of leaving omitted/null fields unchanged.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three concise sentences. First states purpose, second clarifies clearing and completion, third mentions concurrency. No unnecessary words, well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 8 parameters and an output schema, the description covers key aspects: partial update, clearing, completion toggle, and concurrency. It omits explanation of the 'list' parameter but overall provides sufficient context for a patch tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema coverage, the description compensates by explaining clearing fields with empty strings for notes, due, url, and setting completed to true/false. However, it does not cover all 8 parameters (e.g., title, priority, list).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool patches mutable fields of a reminder, preserving others. It differentiates from sibling tools like create_reminder and delete_reminder, and clarifies that it can also set completed, overlapping with complete_reminder but explaining the scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not explicitly specify when to use this tool versus alternatives like complete_reminder. It implies usage for partial updates but lacks direct guidance on selection based on operation scope.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

7 tool updatesv0.1.0Jul 7, 2026
- First observedcomplete_reminder
- First observedcreate_reminder
- First observeddelete_reminder
- First observedget_reminder
- First observedlist_lists
- First observedlist_reminders
- First observedupdate_reminder

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.2/5.0

Scored 2026-07-07 00:20 across 7 tools

Disambiguation5/5

Each tool has a unique and clear purpose: complete, create, delete, get, list lists, list reminders, and update. No overlap or ambiguity.

Naming Consistency5/5

All tools follow a consistent verb_noun snake_case pattern (e.g., complete_reminder, list_reminders), making them predictable and easy to understand.

Tool Count5/5

7 tools is well-scoped for a reminders server, covering all essential CRUD operations plus list management without unnecessary bloat.

Completeness5/5

The set provides full lifecycle management for reminders: create, read, update (including complete/reopen), delete, and list. It also includes list listing, which is necessary for context.

Maintenance

ActivityStale

ResponsivenessUnresponsive

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

reminders-bridgeOAuth
io.github.IsaiahDupree
MCP connector for Apple Reminders — search, create, complete, and edit via your own Mac.
Calendar Management App Automation Workplace & Productivity
1
SuperlistOAuth
io.github.superlistapp
Manage Superlist tasks and lists in plain language from any MCP-compatible AI agent.
Project Management Workplace & Productivity
2
Chronary A
ai.chronary
Calendar API for AI agents: events, availability, Google/Microsoft setup, scheduling, and iCal.
Calendar Management Workplace & Productivity
542
Kalender Sync A
de.kalender-sync
GDPR-compliant calendar access for AI assistants: read, create, edit, RSVP. Google, MS 365, Apple.
Calendar Management Workplace & Productivity
81

Related MCP Servers

Apple Reminders MCP Server
App Automation Note Taking OS Automation
pongsapakl
A
license
Not graded
quality
D
maintenance
Enables management of Apple Reminders on macOS, including creating, updating, and querying reminders with due dates, priorities, and completion status across different reminder lists.
Updated 8 months ago (2026-01-15 01:42 UTC)
MIT
Apple Reminders MCP Server
Workplace & Productivity App Automation
leawn
A
license
A
quality
D
maintenance
Enables AI assistants to manage Apple Reminders lists and reminders on macOS, including creating, updating, completing, and deleting reminders.
Updated 8 months ago (2026-01-24 17:41 UTC)
7
89 npm
5
MIT
Apple MCP
Email Calendar Management Note Taking
thetaroot
A
license
Not graded
quality
C
maintenance
Enables AI agents to access iCloud Calendar, Reminders, and Mail with configurable scope and read-only modes.
Updated 23 days ago (2026-08-23 06:57 UTC)
1
MIT
apple-reminders-mcp
Project Management Note Taking
dbmcco
A
license
A
quality
F
maintenance
Enables Claude to manage Apple Reminders on macOS, including creating, reading, updating, deleting, and searching reminders across multiple lists with due dates, priorities, and notes.
Updated a year ago (2025-10-25 20:03 UTC)
6
89 npm
29
MIT

icloud-reminders-mcp

Why CalDAV (and not pyicloud)

Requirements

Install

Generate an app-specific password

Configure

Go/no-go probe

Use with Claude Code

Tools

Development

Troubleshooting

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Why CalDAV (and not `pyicloud`)