The Apple MCP server provides a unified interface to interact with native Apple apps and services:
Contacts: Search and retrieve contacts
Notes: Search, list, and create notes
Messages: Send, read, schedule, and check unread messages
Mail: Read unread emails, search emails, send emails with attachments, list mailboxes
Reminders: Search, create, list, and open reminders
Web Search: Search the web using DuckDuckGo and retrieve content
Calendar: Search, create, open, and list calendar events
Maps: Search locations, save favorites, get directions, manage guides, and add places to guides
Enables interaction with native Apple applications and services, providing access to Messages, Notes, Contacts, Mail, Reminders, and Calendar for sending messages, reading/searching notes, managing contacts, sending/scheduling emails, creating reminders, and managing calendar events.
Mentioned as a planned future feature to search and open music in Apple Music app.
Enables web search functionality using DuckDuckGo to retrieve and process content from search results.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Apple MCP send a message to John Doe about our meeting tomorrow at 3pm"
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.
This is a collection of apple-native tools for the MCP protocol.
Here's a step-by-step video about how to set this up, with a demo. - https://x.com/DhravyaShah/status/1892694077679763671
{
"mcpServers": {
"apple-mcp": {
"command": "bunx",
"args": ["--no-cache", "apple-mcp@latest"]
}
}
To install Apple MCP for Claude Desktop automatically via Smithery:
npx -y @smithery/cli@latest install @Dhravya/apple-mcp --client claude... and for cursor, you can do:
npx -y @smithery/cli@latest install @Dhravya/apple-mcp --client cursorMessages:
Send messages using the Apple Messages app
Read out messages
Notes:
List notes
Search & read notes in Apple Notes app
Contacts:
Search contacts for sending messages
Emails:
Send emails with multiple recipients (to, cc, bcc) and file attachments
Search emails with custom queries, mailbox selection, and result limits
Schedule emails for future delivery
List and manage scheduled emails
Check unread email counts globally or per mailbox
Reminders:
List all reminders and reminder lists
Search for reminders by text
Create new reminders with optional due dates and notes
Open the Reminders app to view specific reminders
Calendar:
Search calendar events with customizable date ranges
List upcoming events
Create new calendar events with details like title, location, and notes
Open calendar events in the Calendar app
Web Search:
Search the web using DuckDuckGo
Retrieve and process content from search results
Maps:
Search for locations and addresses
Save locations to favorites
Get directions between locations
Drop pins on the map
Create and list guides
Add places to guides
TODO: Search and open photos in Apple Photos app
TODO: Search and open music in Apple Music app
You can also daisy-chain commands to create a workflow. Like: "can you please read the note about people i met in the conference, find their contacts and emails, and send them a message saying thank you for the time."
(it works!)
You just need bun, install with brew install oven-sh/bun/bun
Now, edit your claude_desktop_config.json with this:
{
"mcpServers": {
"apple-mcp": {
"command": "bunx",
"args": ["@dhravya/apple-mcp@latest"]
}
}
}Now, ask Claude to use the apple-mcp tool.
Can you send a message to John Doe?find all the notes related to AI and send it to my girlfriendcreate a reminder to "Buy groceries" for tomorrow at 5pmRelated MCP server: Local MCP
git clone https://github.com/dhravya/apple-mcp.git
cd apple-mcp
bun install
bun run index.tsenjoy!
Search, create, and open calendar events in Apple Calendar app
| Name | Required | Description | Default |
|---|---|---|---|
| operation | Yes | Operation to perform: 'search', 'open', 'list', or 'create' | |
| searchText | No | Text to search for in event titles, locations, and notes (required for search operation) | |
| eventId | No | ID of the event to open (required for open operation) | |
| limit | No | Number of events to retrieve (optional, default 10) | |
| fromDate | No | Start date for search range in ISO format (optional, default is today) | |
| toDate | No | End date for search range in ISO format (optional, default is 30 days from now for search, 7 days for list) | |
| title | No | Title of the event to create (required for create operation) | |
| startDate | No | Start date/time of the event in ISO format (required for create operation) | |
| endDate | No | End date/time of the event in ISO format (required for create operation) | |
| location | No | Location of the event (optional for create operation) | |
| notes | No | Additional notes for the event (optional for create operation) | |
| isAllDay | No | Whether the event is an all-day event (optional for create operation, default is false) | |
| calendarName | No | Name of the calendar to create the event in (optional for create operation, uses default calendar if not specified) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but provides minimal information. It mentions the Apple Calendar app context but doesn't describe what happens during operations (e.g., whether 'create' opens the app, saves automatically, requires confirmation), error conditions, rate limits, or permission requirements. For a multi-operation tool with 13 parameters, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 8 words, front-loading the core functionality without any wasted words. It efficiently communicates the three main operations and target application in a single, clear phrase.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 13 parameters, 4 distinct operations, and no annotations or output schema, the description is inadequate. It doesn't explain what the tool returns for different operations, how operations differ behaviorally, what happens in the Apple Calendar app, or any system dependencies. The agent would struggle to use this tool effectively based solely on the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no parameter-specific information beyond what's already in the schema, which has 100% coverage. While the schema thoroughly documents all 13 parameters with descriptions and requirements, the description doesn't add any additional context about parameter interactions, default behaviors, or usage patterns across different operations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Search, create, and open calendar events in Apple Calendar app', which specifies the actions (search, create, open) and resource (calendar events). It distinguishes from siblings like contacts or mail by focusing on calendar events, though it doesn't explicitly differentiate from other potential calendar tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose 'search' vs 'list' operations, when to use this tool over other calendar management options, or any prerequisites for operations like 'create' that might require specific permissions or app states.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search and retrieve contacts from Apple Contacts app
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Name to search for (optional - if not provided, returns all contacts). Can be partial name to search. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool searches and retrieves contacts, implying a read-only operation, but doesn't specify permissions needed, whether it accesses local or synced data, rate limits, or what the return format looks like (e.g., list of contacts with fields). This leaves significant gaps for a tool interacting with personal data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It front-loads the core purpose ('Search and retrieve contacts') and specifies the source ('from Apple Contacts app'), making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (searching personal contacts), lack of annotations, and no output schema, the description is minimally adequate. It states what the tool does but omits critical context like return format, error handling, or data sensitivity considerations. It relies heavily on the schema for parameter details, leaving behavioral aspects underspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema fully documents the single optional parameter. The description adds no additional parameter semantics beyond what's in the schema (e.g., no examples of search syntax or format). This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Search and retrieve') and resource ('contacts from Apple Contacts app'). It distinguishes itself from siblings like calendar or mail by focusing on contacts, but doesn't explicitly differentiate from potential contact-related tools that might exist in other contexts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, limitations, or scenarios where other tools might be more appropriate. The agent must infer usage from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Interact with Apple Mail app - read unread emails, search emails, and send emails
| Name | Required | Description | Default |
|---|---|---|---|
| operation | Yes | Operation to perform: 'unread', 'search', 'send', 'mailboxes', 'accounts', or 'latest' | |
| account | No | Email account to use (optional - if not provided, searches across all accounts) | |
| mailbox | No | Mailbox to use (optional - if not provided, uses inbox or searches across all mailboxes) | |
| limit | No | Number of emails to retrieve (optional, for unread, search, and latest operations) | |
| searchTerm | No | Text to search for in emails (required for search operation) | |
| to | No | Recipient email address (required for send operation) | |
| subject | No | Email subject (required for send operation) | |
| body | No | Email body content (required for send operation) | |
| cc | No | CC email address (optional for send operation) | |
| bcc | No | BCC email address (optional for send operation) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it lists operations (read unread emails, search emails, send emails), it doesn't disclose critical behavioral traits: whether operations require specific permissions, if sending emails triggers notifications, rate limits, error conditions, or what the return format looks like (no output schema). For a multi-operation tool with mutation capabilities (send), this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise - a single sentence that states the domain and core operations. It's front-loaded with the main purpose. However, it could be slightly more structured by explicitly listing all six operations from the schema to avoid confusion.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, 6 operations including mutation operations like 'send'), lack of annotations, and no output schema, the description is incomplete. It doesn't cover all operations listed in the schema, provides no behavioral context for mutations, and offers no guidance on error handling or return values. For a multi-operation tool with both read and write capabilities, this is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 all 10 parameters thoroughly. The description mentions three operations ('unread', 'search', 'send') that map to the 'operation' parameter, but doesn't add any semantic context beyond what's in the schema. It doesn't explain parameter dependencies or operation-specific requirements. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Interact with Apple Mail app - read unread emails, search emails, and send emails'. It specifies the application domain (Apple Mail) and lists three core operations. However, it doesn't distinguish this tool from potential sibling tools like 'messages' or 'contacts' that might also handle communication, and it doesn't mention all six operations listed in the schema (missing 'mailboxes', 'accounts', 'latest').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'messages' or 'contacts', nor does it specify scenarios where this tool is preferred over others. The only implicit usage context is 'Apple Mail app', but this doesn't help an agent decide between this and other communication-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search locations, manage guides, save favorites, and get directions using Apple Maps
| Name | Required | Description | Default |
|---|---|---|---|
| operation | Yes | Operation to perform with Maps | |
| query | No | Search query for locations (required for search) | |
| limit | No | Maximum number of results to return (optional for search) | |
| name | No | Name of the location (required for save and pin) | |
| address | No | Address of the location (required for save, pin, addToGuide) | |
| fromAddress | No | Starting address for directions (required for directions) | |
| toAddress | No | Destination address for directions (required for directions) | |
| transportType | No | Type of transport to use (optional for directions) | |
| guideName | No | Name of the guide (required for createGuide and addToGuide) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While it mentions operations like 'save favorites' and 'get directions,' it fails to describe authentication requirements, rate limits, data persistence, error conditions, or what the tool returns. For a multi-operation tool with 9 parameters, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that lists key capabilities without unnecessary words. It's appropriately sized for a multi-function tool, though it could be more front-loaded with the most common use cases rather than a flat list.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 9 parameters, 7 distinct operations, no annotations, and no output schema, the description is inadequate. It doesn't explain return values, error handling, operation-specific behaviors, or how parameters interact across different operations. The description should provide more operational context given the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 all parameters thoroughly. The description adds no parameter-specific information beyond what's in the schema. The baseline of 3 is appropriate since the schema does the heavy lifting, though the description doesn't compensate with additional context about parameter interactions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs (search, manage, save, get) and resources (locations, guides, favorites, directions) using Apple Maps. It distinguishes this as a maps tool among siblings like calendar and contacts, though it doesn't explicitly differentiate from potential alternative mapping tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives or when specific operations are appropriate. It lists capabilities but offers no context about prerequisites, constraints, or decision criteria for choosing between operations like search vs. directions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Interact with Apple Messages app - send, read, schedule messages and check unread messages
| Name | Required | Description | Default |
|---|---|---|---|
| operation | Yes | Operation to perform: 'send', 'read', 'schedule', or 'unread' | |
| phoneNumber | No | Phone number to send message to (required for send, read, and schedule operations) | |
| message | No | Message to send (required for send and schedule operations) | |
| limit | No | Number of messages to read (optional, for read and unread operations) | |
| scheduledTime | No | ISO string of when to send the message (required for schedule operation) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions operations like 'send' and 'schedule,' which imply mutations, but doesn't state whether these require user confirmation, have rate limits, or affect device state. For a tool with multiple operations including writes, this is inadequate, as it omits critical behavioral traits like safety or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, stating the core purpose in a single sentence. It efficiently lists the four operations without unnecessary details. However, it could be slightly more structured by grouping related operations or adding brief context, but overall, it avoids waste and is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity with 5 parameters, multiple operations including mutations, no annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects, usage contexts, or return values, leaving gaps that could hinder an AI agent's ability to invoke the tool correctly. For a multi-operation tool with no structured safety hints, more detail is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal meaning beyond the input schema, which has 100% coverage. It implies that parameters are tied to specific operations (e.g., 'message' for 'send'), but doesn't elaborate on semantics like format constraints or dependencies. Since the schema descriptions are comprehensive, the baseline score of 3 is appropriate, as the description doesn't significantly enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Interact with Apple Messages app - send, read, schedule messages and check unread messages.' It specifies the verb ('interact with') and resource ('Apple Messages app'), and lists the four operations. However, it doesn't explicitly differentiate from sibling tools like 'contacts' or 'mail,' which could have overlapping communication functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It lists operations but doesn't specify contexts, prerequisites, or exclusions. For example, it doesn't mention if 'schedule' requires specific permissions or if 'read' is limited to recent messages. With sibling tools like 'calendar' and 'reminders' that might handle scheduling, this lack of differentiation is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search, retrieve and create notes in Apple Notes app
| Name | Required | Description | Default |
|---|---|---|---|
| operation | Yes | Operation to perform: 'search', 'list', or 'create' | |
| searchText | No | Text to search for in notes (required for search operation) | |
| title | No | Title of the note to create (required for create operation) | |
| body | No | Content of the note to create (required for create operation) | |
| folderName | No | Name of the folder to create the note in (optional for create operation, defaults to 'Claude') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral disclosure. It mentions three operations but doesn't describe what 'retrieve' means (likely mapping to 'list'), whether operations require specific permissions, how search results are returned, or any rate limits. For a multi-operation tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single sentence that efficiently communicates the core functionality. Every word earns its place with no wasted text, though this conciseness comes at the cost of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a multi-operation tool with 5 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain return values, error conditions, or behavioral nuances. The tool handles both read (search/list) and write (create) operations, but the description doesn't address these different security implications or usage patterns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 5 parameters. The description adds no parameter-specific information beyond what's in the schema. The baseline of 3 is appropriate when the schema does all the heavy lifting for parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('search, retrieve and create') and resource ('notes in Apple Notes app'). It distinguishes from sibling tools like calendar or contacts by specifying the Notes app domain. However, it doesn't differentiate between the three operations within the tool itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus the sibling tools (calendar, contacts, etc.) or when to choose between the three operations (search, list, create). The description only lists operations without context about appropriate use cases or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search, create, and open reminders in Apple Reminders app
| Name | Required | Description | Default |
|---|---|---|---|
| operation | Yes | Operation to perform: 'list', 'search', 'open', 'create', or 'listById' | |
| searchText | No | Text to search for in reminders (required for search and open operations) | |
| name | No | Name of the reminder to create (required for create operation) | |
| listName | No | Name of the list to create the reminder in (optional for create operation) | |
| listId | No | ID of the list to get reminders from (required for listById operation) | |
| props | No | Properties to include in the reminders (optional for listById operation) | |
| notes | No | Additional notes for the reminder (optional for create operation) | |
| dueDate | No | Due date for the reminder in ISO format (optional for create operation) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only mentions operations without behavioral details. It doesn't disclose permissions needed, rate limits, whether operations are destructive (e.g., 'create' modifies data), or how 'open' behaves. This leaves critical behavioral traits unspecified for a multi-operation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads key operations. It avoids redundancy but could be more structured by clarifying operation distinctions. Every word earns its place, though it's slightly under-specified for a multi-operation tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain return values, error conditions, or how operations interact with parameters (e.g., which params are needed for each operation). Given the complexity, more context is needed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented in the schema. The description adds no additional meaning beyond listing operations, which the schema's 'operation' enum already covers. Baseline 3 is appropriate as the schema handles parameter semantics effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool can 'Search, create, and open reminders in Apple Reminders app', which provides a general purpose but lacks specificity about what 'reminders' are or how operations differ. It distinguishes from siblings like 'calendar' or 'notes' by mentioning 'Apple Reminders app', but doesn't clarify functional boundaries between operations (e.g., 'list' vs 'listById').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'notes' or 'calendar', or when to choose between operations (e.g., 'list' vs 'search'). The description lists operations but doesn't provide context for selection, leaving usage decisions to the agent without support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
calendarcontactsmailmapsmessagesnotesremindersScored across 7 tools
Each tool corresponds to a distinct Apple app (Calendar, Contacts, Mail, Maps, Messages, Notes, Reminders) with clearly separated purposes. There is no overlap in functionality, as each tool handles a specific domain like events, contacts, emails, locations, messages, notes, or reminders, making tool selection straightforward for an agent.
All tool names are singular nouns (calendar, contacts, mail, maps, messages, notes, reminders) that directly reference the Apple apps they interact with. This consistent naming pattern is simple, predictable, and enhances readability across the tool set.
With 7 tools, the server is well-scoped for its purpose of interacting with Apple's core productivity apps. Each tool earns its place by covering a major app, avoiding bloat while providing comprehensive coverage across common user workflows like communication, organization, and navigation.
The tool set offers strong coverage for basic CRUD operations across key Apple apps, such as searching, creating, and retrieving items. Minor gaps exist, like no explicit update or delete operations in some tools (e.g., notes, reminders), but agents can likely work around this using create and search functions for most use cases.
Let ChatGPT, Claude & Cursor use your Mac: email, calendar, iMessage, Teams, files. Local, free.
Search, read, and write your Apple Notes from ChatGPT/Claude via a local Mac agent + MCP relay.
MCP connector for iMessage & Contacts via a local Mac agent + Vercel relay
Persistent context for Claude. Your AI always knows your projects and next actions across sessions.
