Which integrations are available for this server?

Provides tools to manage Apple Calendar events across all configured accounts (iCloud, Google, Exchange, etc.) on macOS. Allows creation, retrieval, updating, deletion, and searching of Google Calendar events via Calendar.app. Allows creation, retrieval, updating, deletion, and searching of iCloud Calendar events via Calendar.app.

How do I use calendar-mcp?

1. Click on "Install 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., "@calendar-mcp create a meeting tomorrow at 2pm" 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.

calendar-mcp

by p-l-ta

Overview Schema Source Related Servers Score Discussions Admin

TypeScript

Local

calendar-mcp

MCP server that gives Claude (and other MCP hosts) full access to Calendar.app on macOS — list, search, create, update, and delete events — across every account configured in Calendar.app (iCloud, Google, Exchange, etc.).

Prerequisites

macOS (Calendar.app required)
Node.js 20+
An MCP host: Claude Desktop or any stdio MCP client

Related MCP server: Apple Calendar MCP

Installation

Claude Desktop — one-click install (recommended)

Download calendar-mcp.mcpb from the latest release
Double-click the .mcpb file — Claude Desktop installs it automatically
Grant the required macOS permissions (see below)

Manual / other hosts

npx @p-l-ta/calendar-mcp

Or install globally:

npm install -g @p-l-ta/calendar-mcp
calendar-mcp

Point your MCP host at the calendar-mcp binary (stdio transport). Example config:

{
  "mcpServers": {
    "calendar-app": {
      "command": "npx",
      "args": ["@p-l-ta/calendar-mcp"]
    }
  }
}

Required macOS permissions

Grant these to the application that runs the MCP host (Claude Desktop, etc.):

Permission	Where to grant
Full Disk Access	System Settings → Privacy & Security → Full Disk Access
Automation → Calendar	System Settings → Privacy & Security → Automation

The MCP server process inherits permissions from the host application that launches it.

Tools

Tool	Description
`list_calendars`	List all calendars with name, color, account, and UUID
`list_events`	List events in a date range, including recurring-event occurrences
`get_event`	Get full details of a single event by UUID, including attendees
`search_events`	Search events by text across title, description, and location
`create_event`	Create a new calendar event
`update_event`	Update properties of an existing event
`delete_event`	Permanently delete an event

How it works

Reads (list_calendars, list_events, search_events, get_event) — query Calendar's SQLite database directly for fast, structured results across all accounts. Recurring events are expanded correctly via Calendar's OccurrenceCache table.
Writes (create_event, update_event, delete_event) — driven by AppleScript automation against Calendar.app, so changes sync to all connected accounts (iCloud, Google, Exchange) just as if you'd made them in the app.

Development

npm install
npm run dev          # tsx watch — live reload
npm run build        # compile TypeScript → dist/
npm run mcpb         # build Claude Desktop extension → build/calendar-mcp.mcpb
npm run smoke        # smoke-test all 7 tools against live Calendar.app data

Note: npm run smoke requires Terminal.app (or your terminal emulator) to have Full Disk Access, since it reads Calendar.sqlitedb directly.

Interactive MCP testing:

npm run build
npx @modelcontextprotocol/inspector node dist/server.js

Privacy Policy

calendar-mcp is a local MCP server that runs entirely on your Mac. It has no backend, no telemetry, and makes no network requests of its own.

What it accesses:

Calendar's SQLite database (~/Library/Group Containers/group.com.apple.calendar/Calendar.sqlitedb) — read-only, used for list/search queries
Calendar.app via AppleScript — to create, update, and delete events

What it does NOT do:

Collect, store, or transmit any data outside your Mac
Connect to any external server or API
Log calendar data anywhere

All calendar data stays on your device and is only passed to the MCP host (Claude Desktop or another client) as part of normal tool responses. You control exactly which tools Claude can invoke.

License

MIT

Available Tools

7 tools

create_eventA

Create a new event in Calendar.app. Goes through AppleScript so Calendar.app syncs the new event to all connected accounts. Returns the uid of the created event. Supports recurring events via the recurrence field.

ParametersJSON Schema

Name	Required	Description
`end`	Yes	ISO 8601 end datetime, e.g. '2026-05-10T10:00:00'.
`url`	No	URL to attach to the event.
`start`	Yes	ISO 8601 start datetime, e.g. '2026-05-10T09:00:00'.
`all_day`	No	True for an all-day event. When true, start/end times are ignored — only the dates are used.
`summary`	Yes	Event title.
`calendar`	Yes	Name of the target calendar (e.g. 'Calendar', 'Work'). Must match an existing calendar name exactly.
`location`	No	Location string.
`recurrence`	No	Recurrence rule. Omit for a one-time event.
`description`	No	Event notes/body.

TDQS

A3.9/5.0

Behavior4/5

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

Adds valuable behavior beyond annotations: it goes through AppleScript, syncs to all connected accounts, returns the created event's uid, and supports recurrence. No contradiction with readOnlyHint=false or destructiveHint=false.

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

Conciseness4/5

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

Four dense sentences with no filler, front-loaded with the core action and followed by mechanism, return value, and capability. Slight redundancy from repeating 'Calendar.app' twice, but overall 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?

For a 9-parameter tool with a nested recurrence object and no output schema, the description supplies the key return value (uid) and the notable sync behavior. Error conditions and calendar prerequisites are left to the schema, but this is reasonably complete.

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 100%, so all parameters are already documented. The description mentions the recurrence field, but that adds little beyond the detailed schema definition; baseline 3 is appropriate.

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?

States the exact action and target ('Create a new event in Calendar.app'), clearly distinguishing it from the sibling update/delete/read tools. Additional detail on the AppleScript mechanism and returned uid reinforces its identity as a 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 verb 'Create' makes the primary use case clear, but the description does not explicitly contrast with update_event or mention prerequisites like existing calendars. Usage is implied rather than directly routed, so it sits at the middle of the scale.

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

delete_eventA

Destructive

Permanently delete a Calendar.app event identified by its uid. Goes through AppleScript so the deletion syncs to all connected accounts. This action cannot be undone.

ParametersJSON Schema

Name	Required	Description	Default
`uid`	Yes	The iCal uid of the event to delete (uid field from list_events, search_events, or get_event).

TDQS

A4.3/5.0

Behavior4/5

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

Adds syncing behavior and irreversibility beyond annotations (destructiveHint=true). No contradiction.

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 focused sentences, front-loaded with action, minimal waste.

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?

Complete for a simple delete with one param; annotations handle destructiveness; syncing note adds context.

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 100% and schema describes uid source. Description adds no extra param info, baseline 3.

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 it deletes a Calendar.app event by uid, distinct from siblings (list, create, update, etc.).

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?

Describes syncing via AppleScript and irreversibility, guiding when to use. Implicitly excludes updates or reads.

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

get_eventA

Read-only

Get full details of a single Calendar.app event by UUID, including attendees and all metadata. The uuid field is returned by list_events and search_events.

ParametersJSON Schema

Name	Required	Description	Default
`uuid`	Yes	The event UUID (or iCal unique_identifier) returned by list_events, search_events, or a prior get_event call.

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value by specifying the return includes attendees and all metadata, but does not mention any additional behaviors like rate limits or permissions. No contradictions.

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 two sentences, front-loaded with the purpose, and contains no unnecessary words. It is efficient and easy to parse.

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 no output schema, the description explains it returns full details including attendees and all metadata, which is sufficiently complete for a simple retrieval tool. It could have listed more fields but is adequate.

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 100%, so the schema already documents the uuid parameter thoroughly. The description adds context about the UUID source, which is useful but minimal beyond the schema.

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 retrieves full details of a single Calendar.app event by UUID. It distinguishes from sibling tools like list_events (which likely returns summaries) and search_events, and specifies the source of the UUID.

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?

The description indicates when to use this tool, by stating the uuid is returned by list_events and search_events. It provides clear context but does not explicitly mention when not to use it or alternative tools for other scenarios.

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

list_calendarsA

Read-only

List all Calendar.app calendars across all accounts, with name, UUID, color, and account info. UUIDs can be passed to list_events, search_events, and get_event to filter by calendar.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds context by specifying it returns data across all accounts and includes specific fields, which is useful beyond annotation hints.

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, front-loaded with action and output details. Every word adds value—no redundancy. Structurally ideal for quick parsing.

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 no output schema, description fully covers return values (name, UUID, color, account info) and links to other tools. Complete for a simple list tool without complex behavior.

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 exist; schema coverage is 100%. Description does not need to add parameter info. Baseline score of 4 for zero-parameter tools is appropriate as no additional explanation required.

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?

Description clearly states 'List all Calendar.app calendars across all accounts' with specific fields (name, UUID, color, account info). Differentiates from sibling tools by explaining UUIDs can be passed to filtering tools.

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?

Explicitly guides usage by noting UUIDs from this tool can be used to filter events in list_events, search_events, and get_event. Implicitly indicates this is for obtaining calendar identifiers before event queries.

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

list_eventsA

Read-only

List calendar events within a date range. Queries the Calendar.app SQLite database via OccurrenceCache, which correctly expands recurring event instances rather than just listing master events. Returns events sorted by start time.

ParametersJSON Schema

Name	Required	Description
`end`	Yes	ISO 8601 end of the window (exclusive). Events whose occurrence starts before this time are included.
`limit`	No
`start`	Yes	ISO 8601 start of the window, e.g. '2026-05-01T00:00:00' or '2026-05-01'. Events whose occurrence starts on or after this time are included.
`calendar_uuid`	No	Restrict results to a single calendar. Pass a UUID from list_calendars.

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already mark readOnlyHint=true and destructiveHint=false. Description adds that the tool queries the OccurrenceCache, expands recurring instances, and sorts by start time, which are useful behavioral details beyond what annotations provide.

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?

Three short sentences, no redundancy. Purpose stated first, then technical detail, then output ordering. Every sentence earns its place.

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?

Covers main behavior, expansion, ordering. No output schema exists, so return format is not described, but the description gives enough context for a list operation. Could mention pagination or default limit behavior more explicitly.

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?

Schema coverage is 75% (3 of 4 params described). Description adds clarification: start and end are ISO 8601, end is exclusive, calendar_uuid should come from list_calendars. This adds practical meaning beyond the schema 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?

Clearly states the verb 'List' and resource 'calendar events within a date range'. Differentiates from siblings like list_calendars (lists calendars) and search_events (likely searches by text).

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 listing events in a date range. No explicit guidance on when not to use or alternatives, but context from description and sibling names provides some differentiation.

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

search_eventsA

Read-only

Search Calendar.app events by text across title, description, and location. Queries CalendarItem directly for fast full-text matching. For recurring events returns the master event; use list_events for occurrence-level detail.

ParametersJSON Schema

Name	Required	Description
`end`	No	ISO 8601 date — only events starting before this date.
`limit`	No
`query`	Yes	Text to search for in event title, description, and location.
`start`	No	ISO 8601 date — only events starting on or after this date.
`calendar_uuid`	No	Restrict results to a single calendar. Pass a UUID from list_calendars.

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already indicate read-only and non-destructive nature. Description adds useful behavioral context: fast full-text matching via direct CalendarItem query and recurrence behavior, which goes 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?

Three sentences with no waste. First sentence states the core purpose, second adds performance hint, third provides recurrence handling and sibling redirection. Front-loaded and efficient.

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?

Covers purpose, usage guidance, and key behavioral trait (recurring event handling). No output schema, but return values are adequately implied. With rich siblings and annotations, the description is nearly complete.

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 high (80%), so baseline is 3. The description does not add significant new meaning for parameters beyond what the schema already provides (e.g., it restates the query field's scope).

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 the action (search), resource (Calendar.app events), and scope (text across title, description, location). Distinguishes from sibling list_events by noting that search_events returns master events for recurring ones.

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?

Explicitly advises to use list_events for occurrence-level detail when dealing with recurring events. Does not provide a full when-not-to-use guide, but the sibling mention suffices.

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

update_eventA

Update properties of an existing Calendar.app event identified by its uid. Only provided fields are changed. Goes through AppleScript so changes sync to all connected accounts.

ParametersJSON Schema

Name	Required	Description
`end`	No	New ISO 8601 end datetime.
`uid`	Yes	The iCal uid of the event to update (uid field from list_events, search_events, or get_event).
`url`	No	New URL. Pass empty string to clear.
`start`	No	New ISO 8601 start datetime.
`summary`	No	New event title.
`location`	No	New location string. Pass empty string to clear.
`description`	No	New event notes/body. Pass empty string to clear.

TDQS

A3.7/5.0

Behavior3/5

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

Annotations already indicate non-readonly and non-destructive nature. Description adds context about AppleScript and syncing, but misses error behavior (e.g., uid not found) and permissions.

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. Purpose and key behavioral note are front-loaded, making it easy to scan.

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?

Given 7 parameters and no output schema, the description explains partial update and sync but omits return value, error handling, and prerequisites (e.g., event existence). Satisfactory but not comprehensive.

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 100% with parameter descriptions. The description adds the key insight of partial updates ('Only provided fields are changed'), but does not further elaborate on parameter semantics beyond schema.

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 verb 'update', the resource 'Calendar.app event', and the unique identifier 'uid'. It distinguishes itself from sibling tools by specifying it modifies existing events.

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 mentions partial updates ('Only provided fields are changed') but does not provide explicit guidance on when to use this tool versus siblings like create_event or delete_event, nor any prerequisites.

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. Dates show when Glama detected each change.

1 tool updatev1.0.1Aug 26, 2026

Changedcreate_event1 field changed

addedInput schema / properties / recurrence

Added value: +{
+  "description": "Recurrence rule. Omit for a one-time event.",
+  "properties": {
+    "count": {
+      "description": "Stop after this many total occurrences (including the first). Mutually exclusive with end_date.",
+      "maximum": 9007199254740991,
+      "minimum": 1,
+      "type": "integer"
+    },
+    "days_of_week": {
+      "description": "For weekly: which days to repeat on (e.g. ['MO','WE','FR'] for MWF). For monthly with week_of_month: the single day of the week (e.g. ['MO'] for 'first Monday').",
+      "items": {
+        "enum": [
+          "MO",
+          "TU",
+          "WE",
+          "TH",
+          "FR",
+          "SA",
+          "SU"
+        ],
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "end_date": {
+      "description": "Stop recurring on or before this date (ISO 8601). Mutually exclusive with count.",
+      "type": "string"
+    },
+    "frequency": {
+      "description": "How often the event repeats.",
+      "enum": [
+        "daily",
+        "weekly",
+        "monthly",
+        "yearly"
+      ],
+      "type": "string"
+    },
+    "interval": {
+      "default": 1,
+      "description": "Repeat every N frequency units. Default 1 (e.g. interval 2 with frequency 'weekly' = every other week).",
+      "maximum": 9007199254740991,
+      "minimum": 1,
+      "type": "integer"
+    },
+    "week_of_month": {
+      "description": "For monthly recurrence by position: 1=first, 2=second, 3=third, 4=fourth, -1=last. Requires exactly one entry in days_of_week (e.g. week_of_month=1, days_of_week=['MO'] = first Monday of each month).",
+      "maximum": 5,
+      "minimum": -1,
+      "type": "integer"
+    }
+  },
+  "required": [
+    "frequency"
+  ],
+  "type": "object"
+}

7 tool updatesv1.0.0Jul 28, 2026
- First observedcreate_event
- First observeddelete_event
- First observedget_event
- First observedlist_calendars
- First observedlist_events
- First observedsearch_events
- First observedupdate_event

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0

Disambiguation5/5

Each tool targets a distinct operation: fetching one event, listing by range, searching by text, listing calendars, and the create/update/delete lifecycle. The overlap between list_events and search_events is clearly resolved by different query methods and return semantics.

Naming Consistency5/5

All tools follow a consistent verb_noun snake_case pattern: get/list/search/create/update/delete plus event/calendars. Pluralization is used sensibly for list operations, so there are no confusing deviations.

Tool Count5/5

Seven tools is well-scoped for a calendar server. Each tool covers a distinct and necessary operation without redundancy, and there is no bloat or overly thin coverage.

Completeness5/5

The event lifecycle is fully covered with create, get, list, search, update, and delete, and calendar enumeration supports filtering and event retrieval. Calendar creation and modification are reasonably left out since calendars are typically account-managed, so there are no critical dead ends.

Maintenance

ActivityMaintained

ResponsivenessUnresponsive

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

cronofy A
io.usefulapi
MCP server for Cronofy — read calendars, events and free/busy, and create, update or delete events.
Calendar Management Workplace & Productivity
82
CalendarMCP
ai.calendarmcp
Hosted Google Calendar MCP server for AI agents. No self-hosting or Google Cloud setup.
Calendar Management Workplace & Productivity
2
nylas A
io.usefulapi
MCP server for Nylas — read email, calendars, events and contacts, and send email or create events.
Email Calendar Management CRM
152
gcal AOAuth
com.mintmcp
A MCP server that works with Google Calendar to manage event listing, reading, and updates.
Calendar Management App Automation
28

Related MCP Servers

Calendar MCP
Calendar Management File Systems
wyattjoh
A
license
Not graded
quality
D
maintenance
MCP server for accessing macOS Calendar events
Updated a year ago (2025-08-05 22:33 UTC)
2
MIT
Apple Calendar MCP
Calendar Management App Automation
yongzhe-wang
A
license
Not graded
quality
D
maintenance
Enables Claude and other MCP clients to directly interact with macOS Calendar.app using AppleScript for local calendar management. Provides tools for listing, searching, creating, updating, and deleting calendar events without cloud APIs or CalDAV setup.
Updated 6 days ago (2026-09-02 07:53 UTC)
18
4
MIT
apple-calendar-mcp
Calendar Management Workplace & Productivity
EgorKurito
A
license
Not graded
quality
D
maintenance
MCP server for Apple Calendar via native EventKit API with proper recurring event support.
Updated 7 months ago (2026-02-07 11:40 UTC)
18
10
MIT
ical-mcp
Calendar Management Workplace & Productivity
aberhamm
A
license
A
quality
B
maintenance
MCP server for Apple Calendar and CalDAV providers. Enables listing, creating, updating, deleting events, and checking free/busy status with per-calendar write protection.
Updated 2 months ago (2026-06-24 17:45 UTC)
6
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/p-l-ta/calendar-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server