macOS Calendar MCP Server

by xybstone

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, but 'list-today-events' and 'list-week-events' could be confused with 'search-events' as they all retrieve events. The descriptions clarify that 'list-today-events' and 'list-week-events' are time-specific listings, while 'search-events' is keyword-based, but the overlap in functionality might cause misselection in some contexts.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with hyphens (e.g., create-event, list-calendars, delete-events-by-keyword). The naming is predictable and readable throughout the set, with no deviations in style or convention.
Tool Count5/5
With 8 tools, the server is well-scoped for macOS calendar management. Each tool serves a clear purpose, such as creating, listing, deleting, and fixing events, without unnecessary redundancy or bloat, making it appropriate for the domain.
Completeness4/5
The tool set covers core operations like creating, listing, searching, and deleting events, as well as managing calendars. However, there are minor gaps, such as the lack of an 'update-event' tool for modifying existing events, which agents might need to work around by deleting and recreating events.
Average 2.8/5 across 8 of 8 tools scored. Lowest: 2.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
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

Behavior1/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. '搜索事件' gives no information about whether this is a read-only operation, what permissions might be required, whether it's paginated, what the return format looks like, or any rate limits. For a search tool with zero annotation coverage, this is completely inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just two characters ('搜索事件'), which is appropriately sized for what little information it conveys. There's no wasted text or unnecessary elaboration. However, this conciseness comes at the cost of being under-specified rather than truly efficient.
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 a search operation with 2 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what constitutes an 'event', how search results are returned, what fields are searchable, or any behavioral characteristics. 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?
Schema description coverage is 100%, so the schema already documents both parameters (query and calendar) with their descriptions. The tool description adds no additional meaning about parameters beyond what the schema provides. The baseline of 3 is appropriate when the schema does the heavy lifting, even though the description contributes nothing about parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description '搜索事件' (search events) is a tautology that restates the tool name without adding specificity. It doesn't clarify what type of events, what scope, or how the search works. While it includes a verb ('搜索') and resource ('事件'), it lacks differentiation from sibling tools like 'list-today-events' or 'list-week-events'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 are multiple sibling tools for event-related operations (list-today-events, list-week-events, delete-events-by-keyword), but the description offers no context about when this search tool is appropriate versus those listing tools or when it should be avoided.
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 full burden. '创建' (create) implies a write/mutation operation, but it doesn't disclose behavioral traits such as permissions required, whether events are created synchronously/asynchronously, error handling for partial failures, or rate limits. For a batch mutation tool, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single phrase '批量创建事件' (batch create events), which is extremely concise and front-loaded with the core action. Every word earns its place, with no wasted text or redundancy.
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 a batch creation tool with no annotations and no output schema, the description is incomplete. It lacks information on behavioral aspects (e.g., mutation effects, error handling), usage context relative to siblings, and expected outputs. The agent must rely heavily on the schema and inference, which is insufficient for safe operation.
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%, with parameters 'events' and 'calendar' documented in the schema. The description adds no additional meaning beyond the schema, such as explaining the structure of events or the significance of the calendar parameter. Baseline 3 is appropriate as the schema handles parameter documentation adequately.
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 '批量创建事件' (batch create events) clearly states the verb (create) and resource (events) with the batch operation modifier. It distinguishes from the sibling 'create-event' by specifying batch capability, though it doesn't explicitly contrast them. The purpose is specific and actionable.
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 'create-event' for single events or other event-related tools. There's no mention of prerequisites, constraints, or comparative context with siblings, leaving the agent to infer usage scenarios.
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 only states the basic action. It doesn't mention whether this requires calendar permissions, what happens on creation failure, whether events are editable after creation, or any rate limits. For a mutation tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
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 in Chinese that directly states the tool's purpose without any wasted words. It's appropriately sized and front-loaded with the essential information.
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 mutation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what happens after creation (success/failure responses), doesn't mention permission requirements, and provides no behavioral context. Given the tool's complexity (creating calendar events) and lack of structured metadata, the description should do more to guide the agent.
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 has 100% description coverage with clear parameter documentation, so the baseline is 3. The tool description adds no additional parameter information beyond what's already in the schema descriptions, but doesn't need to compensate for any gaps since schema coverage is complete.
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 action ('创建新事件' - create new event) and target resource ('在macOS日历中' - in macOS calendar), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'create-batch-events' or explain how this single-event creation differs from batch creation.
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?
No guidance is provided about when to use this tool versus alternatives. With siblings like 'create-batch-events' for multiple events and 'search-events' for finding existing events, the description offers no context about appropriate use cases, prerequisites, or when to choose this tool over others.
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 full burden. It states '删除' (delete) which implies a destructive mutation, but lacks details on permissions needed, whether deletions are permanent/reversible, rate limits, or what happens if no events match the keyword. For a destructive tool with zero annotation coverage, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise with a single sentence that directly states the tool's purpose. No wasted words or unnecessary elaboration, making it easy to parse quickly.
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 destructive mutation tool with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects like safety (e.g., confirmation via 'confirm' parameter), error handling, or return values, leaving significant gaps for agent understanding.
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 three parameters (keyword, calendar, confirm). The description adds no additional meaning beyond implying keyword-based filtering, matching the baseline score 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 '根据关键词删除事件' (Delete events by keyword) clearly states the action (delete) and target resource (events) with a specific mechanism (by keyword). It distinguishes from siblings like create-event or list-events, though it doesn't explicitly differentiate from other deletion tools (none listed).
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?
No guidance on when to use this tool versus alternatives like search-events or other deletion methods. The description implies usage for keyword-based deletion but doesn't mention prerequisites, exclusions, or comparison with sibling tools.
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. It states the tool corrects event times from midnight to correct times, implying a mutation operation, but lacks critical behavioral details: it doesn't specify permissions required, whether changes are reversible, how it handles multiple matching events, error conditions, or what the response looks like. For a mutation tool with zero annotation coverage, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence in Chinese that directly states the tool's purpose without redundancy. It's front-loaded with the core action and resource, and there's no wasted verbiage. Every word earns its place, making it highly concise and well-structured for quick understanding.
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 (a mutation operation with 3 required parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like side effects, error handling, or response format, and it provides minimal usage guidance. For a tool that modifies calendar events, this leaves the agent under-informed about critical operational 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 description coverage is 100%, so the schema already documents all three parameters (calendar, datePattern, corrections) with descriptions. The description adds no additional parameter semantics beyond implying the tool operates on events with incorrect times (e.g., midnight). Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description provides minimal extra value.
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 action ('修正' meaning 'correct/fix') and the resource ('事件时间' meaning 'event times'), specifying it fixes incorrect times from midnight to correct times. It distinguishes from siblings like create-event or delete-events-by-keyword by focusing on correction rather than creation or deletion. However, it doesn't explicitly differentiate from all siblings (e.g., it could overlap with search-events in finding events).
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 minimal guidance: it implies usage when event times are incorrectly set to midnight. However, it offers no explicit when-to-use criteria, no prerequisites (e.g., requires existing events), no when-not-to-use warnings, and no alternatives among sibling tools (e.g., whether to use search-events first). This leaves the agent with insufficient context for optimal tool selection.
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 states the action ('list') but doesn't describe what 'list' entails—whether it returns all events, paginates results, includes metadata like times/locations, or has any rate limits. For a read operation with zero annotation coverage, this leaves significant gaps in understanding the tool's behavior.
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 in Chinese that directly states the tool's purpose. It's front-loaded with the core action and resource, with no wasted words or redundant phrasing. Every part of the sentence earns its place by specifying the time scope.
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 simplicity (1 parameter, no output schema, no annotations), the description is incomplete. It doesn't explain what 'events' include (e.g., meetings, reminders), how results are structured, or any limitations (e.g., max events returned). For a list operation that agents need to interpret results from, more context is needed despite the low complexity.
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%, with the single parameter 'calendar' documented as '日历名称' (calendar name) with a default of '个人' (personal). The description adds no additional meaning beyond the schema—it doesn't explain what calendars are available, how naming works, or implications of the default. Baseline 3 is appropriate since 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 '列出今天的事件' (List today's events) clearly states the verb ('list') and resource ('events') with a specific time scope ('today'). It distinguishes from siblings like 'list-week-events' and 'search-events' by specifying the time filter, but doesn't explicitly differentiate from 'list-calendars' which lists a different resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention when to choose 'list-today-events' over 'list-week-events' or 'search-events', nor does it specify prerequisites like required calendar access. The time scope 'today' is implied but not explicitly positioned against other filtering options.
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 states the action (list events) but doesn't describe traits like read-only vs. destructive (implied read-only from 'list'), authentication needs, rate limits, pagination, or return format. For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior.
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 in Chinese ('列出指定周的事件') that directly states the tool's purpose with zero waste. It's appropriately sized and front-loaded, making it easy to parse quickly 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 no annotations and no output schema, the description is incomplete for a tool with 2 parameters. It doesn't explain return values (e.g., event details, format), error handling, or behavioral constraints. While the schema covers parameters well, the overall context lacks necessary information for safe and effective use, especially for a listing operation.
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%, with clear descriptions for both parameters: 'weekStart' (week start date in YYYY-MM-DD format) and 'calendar' (calendar name, default '工作'). The description adds no additional meaning beyond the schema, such as explaining how 'weekStart' defines the week range or what '工作' means. Baseline 3 is appropriate since 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 '列出指定周的事件' (List events for a specified week) clearly states the verb (list) and resource (events) with a temporal scope (specified week). It distinguishes from siblings like 'list-today-events' (today-specific) and 'search-events' (general search), but doesn't explicitly differentiate from 'list-calendars' (different resource). The purpose is specific and actionable.
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 siblings like 'list-today-events' for today's events or 'search-events' for broader queries, nor does it specify prerequisites or exclusions. Usage is implied by the name and description alone, with no explicit context.
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 states the action ('list') but doesn't describe what 'all' entails (e.g., scope, permissions, or format), whether it's read-only, or any side effects. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
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 in Chinese that directly states the tool's function without any wasted words. It's front-loaded and appropriately sized for a simple listing tool.
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 the tool's low complexity (0 parameters, no annotations, no output schema), the description is minimally adequate but lacks depth. It covers the basic purpose but doesn't provide behavioral details or usage context, which could be helpful despite the simplicity. It meets the minimum for a straightforward tool but doesn't excel.
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?
The tool has 0 parameters, and the schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, and it correctly implies no inputs are required, aligning with the schema. A baseline of 4 is appropriate for a parameterless tool.
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 verb ('列出' meaning 'list') and resource ('macOS日历' meaning 'macOS calendars'), making the purpose immediately understandable. It doesn't distinguish from siblings like 'list-today-events' or 'list-week-events', which filter by time, but it's still specific about what it lists.
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 'list-today-events' or 'list-week-events', nor does it mention any prerequisites or exclusions. It's a basic statement of function without contextual usage advice.
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:

[![macos-calendar-mcp MCP server](https://glama.ai/mcp/servers/xybstone/macos-calendar-mcp/badges/card.svg)](https://glama.ai/mcp/servers/xybstone/macos-calendar-mcp)

Score Badge

Copy to your README.md:

[![macos-calendar-mcp MCP server](https://glama.ai/mcp/servers/xybstone/macos-calendar-mcp/badges/score.svg)](https://glama.ai/mcp/servers/xybstone/macos-calendar-mcp)

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/xybstone/macos-calendar-mcp'

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