Apple MCP Tools

by wearesage

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Each tool is clearly distinct, targeting a specific Apple app or service (Calendar, Contacts, Mail, Maps, Messages, Notes, Reminders, WebSearch). There is no overlap in purpose; an agent can easily differentiate between searching contacts versus searching the web or sending messages versus creating reminders.
Naming Consistency4/5
Seven tools use lowercase, single-word names (calendar, contacts, mail, maps, messages, notes, reminders), which is consistent and readable. However, 'webSearch' deviates with camelCase, breaking the pattern and slightly reducing overall consistency.
Tool Count5/5
With 8 tools, the server is well-scoped for its purpose of interacting with Apple apps and services. Each tool covers a distinct domain, and the count is neither too thin nor overwhelming, fitting typical MCP server ranges (3-15 tools).
Completeness4/5
The tool set provides comprehensive coverage for core Apple apps, including CRUD-like operations (e.g., search, create, read). Minor gaps exist, such as no explicit update or delete functions for some apps, but agents can likely work around this with the available search and create tools.
Average 2.9/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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 mentions the Apple Calendar app context but doesn't describe what happens during operations: whether events are saved locally or synced, if changes are reversible, what permissions are needed, or how errors are handled. For a tool with multiple operations including mutations (create), this lack of behavioral context 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core functionality. It wastes no words while covering the three main operations. Every word earns its place by specifying both actions and target application.
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?
Given the tool's complexity (13 parameters, 4 operations including mutations), no annotations, and no output schema, the description is insufficient. It doesn't explain what the tool returns for different operations, how errors are handled, or the Apple Calendar integration specifics. For a multi-operation tool with create capabilities, more behavioral and contextual information is needed.
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?
The description adds no parameter-specific information beyond what's already in the schema, which has 100% coverage with detailed descriptions for all 13 parameters. The description doesn't explain parameter relationships, such as how operation determines which parameters are relevant, or provide additional context about format requirements beyond ISO dates. With complete schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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 functionality, though it doesn't explicitly differentiate from similar tools like reminders. The description is specific but could be more precise about the 'list' operation mentioned in the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 calendar over reminders for event management, or when to use search versus list operations. There's no context about prerequisites, such as needing the Apple Calendar app installed or having appropriate permissions. Usage is implied through the operation parameter but not explained.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 mentions 'search and retrieve' but doesn't specify whether this is read-only, requires permissions, has rate limits, or describes the return format. This is a significant gap for a tool with no annotation coverage.
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, efficient sentence with zero waste. It's appropriately sized and front-loaded, directly stating the tool's purpose without unnecessary elaboration.
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?
Given the lack of annotations and output schema, the description is incomplete. It doesn't address behavioral aspects like safety, permissions, or return values, which are crucial for a search/retrieve tool. The high schema coverage helps, but overall context is insufficient.
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?
The schema description coverage is 100%, so the schema already documents the single parameter ('name') with its optional nature and partial matching capability. The description adds no additional parameter semantics beyond what the schema provides, meeting the baseline of 3 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.
Purpose4/5
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 and retrieve') and resource ('contacts from Apple Contacts app'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'calendar' or 'mail', which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 prerequisites, appropriate contexts, or exclusions, leaving the agent to infer usage solely from the tool name and purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. It mentions three operations but omits two ('mailboxes' and 'accounts') listed in the schema. It doesn't describe authentication requirements, rate limits, error conditions, or what 'interact' entails beyond basic operations. The description is incomplete for a multi-operation tool with 10 parameters.
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?
The description is efficiently structured in a single sentence listing three main operations. However, it omits two operations from the schema ('mailboxes' and 'accounts'), making it slightly incomplete despite its brevity.
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?
For a complex tool with 10 parameters, 5 operations, and no annotations or output schema, the description is inadequate. It doesn't explain operation differences, return formats, error handling, or prerequisites. The agent would struggle to use this tool correctly without trial and error.
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 fully documents all 10 parameters. The description adds no parameter-specific information beyond what's in the schema. It mentions operations but doesn't clarify which parameters apply to which operations. Baseline 3 is appropriate when schema does all the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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' with specific verbs (read, search, send) and resources (emails). It distinguishes from siblings by focusing on email functionality rather than calendar, contacts, etc., but doesn't differentiate between email 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.
Usage Guidelines2/5
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 specific operations (unread vs search vs send) or when to choose this tool over sibling tools. It lists capabilities but offers no decision criteria or context for selection among the five operation types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. It mentions what the tool can do but fails to describe critical behavioral traits like authentication requirements, rate limits, data persistence for saved items, whether operations are read-only or mutative, or what the return format looks like for different operations.
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, efficient sentence that lists all major functions without unnecessary words. It's appropriately sized and front-loaded with the core capabilities, making every word earn its place.
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?
For a complex tool with 11 parameters, 9 distinct operations, no annotations, and no output schema, the description is insufficient. It doesn't explain how operations differ, what results to expect, error conditions, or behavioral constraints. The description fails to compensate for the lack of structured metadata.
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?
The description mentions four functional areas (search, manage guides, save favorites, get directions) which loosely map to some of the 11 parameters, but with 100% schema description coverage, the schema already documents all parameters thoroughly. The description adds minimal value beyond what's in the schema, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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. However, it doesn't differentiate this multi-function tool from its siblings like webSearch or calendar, which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like webSearch for general searches or other mapping tools. It lists functions but gives no context about appropriate use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 the operations but lacks critical details: it doesn't specify permissions needed (e.g., access to Messages app), side effects (e.g., whether 'send' is immediate or requires confirmation), error handling, or rate limits. For a tool with multiple operations including mutations ('send', 'schedule'), this is a significant gap in transparency.
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?
The description is concise and front-loaded, stating the core purpose in one sentence: 'Interact with Apple Messages app - send, read, schedule messages and check unread messages.' It efficiently lists the four operations without unnecessary elaboration. However, it could be slightly more structured by grouping related operations (e.g., 'send' and 'schedule' as write operations).
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?
Given the tool's complexity (5 parameters, 4 distinct operations including mutations) and lack of annotations and output schema, the description is incomplete. It doesn't address behavioral aspects like authentication, side effects, or return values, which are crucial for safe and effective use. The schema covers parameters well, but overall context for agent decision-making is insufficient.
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 all five parameters thoroughly. The description adds no additional meaning beyond what's in the schema (e.g., it doesn't clarify parameter dependencies or operational nuances). Baseline 3 is appropriate since the schema does the heavy lifting, but the description doesn't compensate or enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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 this tool from its siblings (e.g., calendar, contacts), though the domain (messages vs. other Apple apps) is implied.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 (e.g., when to use 'send' vs. 'schedule', or how this differs from other messaging tools). Without such guidance, the agent must infer usage from the operation parameter alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 lists operations, it doesn't describe what 'retrieve' means (is it fetch by ID? get latest?), doesn't mention authentication requirements, rate limits, error conditions, or what happens when creating duplicate folders. The description is functional but lacks important behavioral context 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise - a single sentence listing the key operations. It's front-loaded with the most important information (search, retrieve, create, list). While efficient, it could be slightly more structured by separating operations or adding brief context about the Apple Notes integration.
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?
For a multi-operation tool (5 operations) with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what 'retrieve' means, doesn't describe return formats for any operation, and provides no context about error handling or Apple Notes-specific constraints. The complexity of the tool (multiple operations with different parameter requirements) demands more comprehensive description than provided.
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 all 5 parameters thoroughly with clear descriptions of each field's purpose and requirements. The description adds no additional parameter semantics beyond what's in the schema - it doesn't explain parameter interactions, default behaviors, or edge cases. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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, create, list) and resources (notes, folders in Apple Notes app). It distinguishes this tool from siblings like calendar or contacts by specifying the Apple Notes domain, though it doesn't explicitly differentiate from other note-taking tools that might exist in the ecosystem.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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' versus 'list', when to create notes versus folders, or how this tool relates to sibling tools like reminders or messages for similar functionality. No explicit when/when-not statements or alternative recommendations are present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 but offers minimal information. It mentions three operations (search, create, open) but omits 'list' and 'listById' from the description, creating inconsistency. It doesn't address permissions, rate limits, platform-specific behaviors, or what 'open' actually does (opens the app? displays details?).
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?
The description is a single, efficient sentence that front-loads the core functionality. However, it's incomplete - it mentions only three of the five available operations ('search, create, and open' while omitting 'list' and 'listById'), which creates a minor structural issue despite the concise phrasing.
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?
For a tool with 8 parameters, 5 distinct operations, no annotations, and no output schema, the description is inadequate. It doesn't explain the relationship between operations, doesn't mention the 'operation' parameter that drives functionality, and provides no guidance on return values or error conditions. The agent would struggle to use this effectively without heavy schema reliance.
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?
The input schema has 100% description coverage, providing detailed documentation for all 8 parameters including required conditions and formats. The description adds no parameter-specific information beyond what's already in the schema, so it meets the baseline of 3 where schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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 reminders in Apple Reminders app' - a specific verb+resource combination that identifies the target application and core operations. However, it doesn't distinguish this from sibling tools like 'calendar' or 'notes' which might have similar CRUD patterns, missing explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There's no mention of when to choose 'reminders' over sibling tools like 'calendar' for time-based tasks, or when to use specific operations like 'search' versus 'list'. The agent must infer usage entirely from the operation parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. While it mentions using DuckDuckGo and retrieving content from search results, it doesn't disclose important behavioral traits like rate limits, authentication requirements, result format, pagination behavior, or whether this is a read-only operation. The description is insufficient for a tool that interacts with external web services.
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?
The description is appropriately concise with a single sentence that efficiently communicates the core functionality. It's front-loaded with the main action ('Search the web') followed by implementation details. There's no wasted verbiage, though it could potentially benefit from slightly more detail given the lack of annotations.
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?
Given the complexity of web search operations and the complete lack of annotations and output schema, the description is insufficiently complete. It doesn't explain what kind of content is retrieved, how results are formatted, whether there are limitations on search scope, or what happens with no results. For a tool that interacts with external services and has no structured output documentation, this leaves significant gaps.
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?
The schema description coverage is 100%, with the single parameter 'query' clearly documented in the schema. The description adds no additional parameter semantics beyond what's already in the schema. According to the scoring guidelines, when schema coverage is high (>80%), the baseline is 3 even with no parameter information in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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 the web', 'retrieve content') and identifies the resource (web via DuckDuckGo). It distinguishes itself from sibling tools like calendar or mail by focusing on web search functionality. However, it doesn't explicitly differentiate from potential similar search 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.
Usage Guidelines2/5
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 specific scenarios where web search is preferred over other information retrieval methods. With sibling tools like notes and reminders available, there's no indication of when web search is the appropriate choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-apple MCP server](https://glama.ai/mcp/servers/wearesage/mcp-apple/badges/card.svg)](https://glama.ai/mcp/servers/wearesage/mcp-apple)

Score Badge

Copy to your README.md:

[![mcp-apple MCP server](https://glama.ai/mcp/servers/wearesage/mcp-apple/badges/score.svg)](https://glama.ai/mcp/servers/wearesage/mcp-apple)

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/wearesage/mcp-apple'

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