模型上下文协议 (MCP) 服务器允许 Claude 访问和管理您的本地 Microsfot Outlook 日历（仅限 Windows）。
查看日历事件：列出日期范围内的事件，查看事件详细信息，检查参与者状态
管理日历事件：创建新事件和会议，更新现有事件
日历智能：查找空闲的时间段进行安排，确定最佳会议时间
多日历支持：在 Outlook 配置文件中访问不同的日历
Related MCP server: Enhanced Outlook MCP Server
Windows操作系统
已安装 Microsoft Outlook 桌面客户端
Node.js（版本 14.x 或更高版本）
npm（Node.js 附带）
npm install -g outlook-calendar-mcp您也可以使用 npx 直接运行它而无需安装：
npx outlook-calendar-mcp克隆此存储库或下载源代码
安装依赖项：
npm install运行服务器：
npm start要将此工具与 Claude 一起使用，您需要将其添加到您的 MCP 设置配置文件中。
将以下内容添加到您的 Claude Desktop 配置文件（位于%APPDATA%\Claude\claude_desktop_config.json ）：
{
"mcpServers": {
"outlook-calendar": {
"command": "outlook-calendar-mcp",
"args": [],
"env": {}
}
}
}{
"mcpServers": {
"outlook-calendar": {
"command": "npx",
"args": ["-y", "outlook-calendar-mcp"],
"env": {}
}
}
}{
"mcpServers": {
"outlook-calendar": {
"command": "node",
"args": ["path/to/outlook-calendar-mcp/src/index.js"],
"env": {}
}
}
}将以下内容添加到您的 Claude VSCode 扩展 MCP 设置文件（位于%APPDATA%\Code\User\globalStorage\saoudrizwan.claude-dev\settings\cline_mcp_settings.json ）：
{
"mcpServers": {
"outlook-calendar": {
"command": "outlook-calendar-mcp",
"args": [],
"env": {}
}
}
}{
"mcpServers": {
"outlook-calendar": {
"command": "npx",
"args": ["-y", "outlook-calendar-mcp"],
"env": {}
}
}
}{
"mcpServers": {
"outlook-calendar": {
"command": "node",
"args": ["path/to/outlook-calendar-mcp/src/index.js"],
"env": {}
}
}
}对于源安装，请将path/to/outlook-calendar-mcp替换为您安装此工具的实际路径。
配置完成后，Claude 将可以使用以下工具：
list_events
- startDate: Start date in MM/DD/YYYY format
- endDate: End date in MM/DD/YYYY format (optional)
- calendar: Calendar name (optional)例如：“列出我下周的日历事件”
create_event
- subject: Event subject/title
- startDate: Start date in MM/DD/YYYY format
- startTime: Start time in HH:MM AM/PM format
- endDate: End date in MM/DD/YYYY format (optional)
- endTime: End time in HH:MM AM/PM format (optional)
- location: Event location (optional)
- body: Event description (optional)
- isMeeting: Whether this is a meeting with attendees (optional)
- attendees: Semicolon-separated list of attendee email addresses (optional)
- calendar: Calendar name (optional)例如：“添加周五下午 2 点与 John 讨论项目提案的会议”
find_free_slots
- startDate: Start date in MM/DD/YYYY format
- endDate: End date in MM/DD/YYYY format (optional)
- duration: Duration in minutes (optional)
- workDayStart: Work day start hour (0-23) (optional)
- workDayEnd: Work day end hour (0-23) (optional)
- calendar: Calendar name (optional)例如：“本周我什么时候有空参加 1 小时的会议？”
get_attendee_status
- eventId: Event ID
- calendar: Calendar name (optional)例如：“谁还没有回复我的团队会议邀请？”
重要提示：使用需要事件 ID 的操作（update_event、delete_event、get_attendee_status）时，必须使用 list_events 响应中的
id字段。这是 Outlook 用于标识事件的唯一 EntryID。
update_event
- eventId: Event ID to update
- subject: New event subject/title (optional)
- startDate: New start date in MM/DD/YYYY format (optional)
- startTime: New start time in HH:MM AM/PM format (optional)
- endDate: New end date in MM/DD/YYYY format (optional)
- endTime: New end time in HH:MM AM/PM format (optional)
- location: New event location (optional)
- body: New event description (optional)
- calendar: Calendar name (optional)例如：“将明天的团队会议从下午 2 点改为下午 3 点开始”
get_calendars例如：“显示我的可用日历”
首次使用时，Outlook 可能会显示安全提示以允许脚本访问
该工具仅访问您的本地 Outlook 客户端，不会将日历数据发送到外部服务器
所有日历操作均在您的计算机上本地执行
Outlook 安全提示：如果您看到来自 Outlook 的安全提示，则需要允许脚本访问您的 Outlook 数据
脚本执行策略：如果遇到脚本执行错误，则可能需要调整 PowerShell 执行策略
路径问题：确保 MCP 配置文件中的路径指向工具的正确位置
欢迎为 Outlook 日历 MCP 工具做出贡献！请参阅我们的贡献指南，了解如何开始贡献。
通过参与此项目，您同意遵守我们的行为准则。
该项目根据 MIT 许可证获得许可 - 有关详细信息，请参阅LICENSE文件。
Create a new calendar event or meeting
| Name | Required | Description | Default |
|---|---|---|---|
| attendees | No | Semicolon-separated list of attendee email addresses (optional) | |
| body | No | Event description/body (optional) | |
| calendar | No | Calendar name (optional) | |
| endDate | No | End date in MM/DD/YYYY format (optional, defaults to start date) | |
| endTime | No | End time in HH:MM AM/PM format (optional, defaults to 30 minutes after start time) | |
| isMeeting | No | Whether this is a meeting with attendees (optional, defaults to false) | |
| location | No | Event location (optional) | |
| startDate | Yes | Start date in MM/DD/YYYY format | |
| startTime | Yes | Start time in HH:MM AM/PM format | |
| subject | Yes | Event subject/title |
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 creates events but doesn't mention whether this requires authentication, what happens on conflicts, if notifications are sent to attendees, rate limits, or the response format. For a mutation tool with zero annotation coverage, 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 directly states the tool's function without unnecessary words. It's appropriately sized and front-loaded, 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?
For a mutation tool with 10 parameters and no annotations or output schema, the description is insufficient. It doesn't address authentication needs, error conditions, what the return value contains, or how it interacts with sibling tools. The high parameter count and lack of structured behavioral data require more descriptive context than provided.
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 schema description coverage is 100%, with all 10 parameters well-documented in the input schema. The description adds no parameter-specific information beyond the generic 'create' action, so it doesn't enhance understanding of individual parameters. The baseline score of 3 reflects adequate but minimal value added by the description.
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 verb ('create') and resource ('calendar event or meeting'), making the purpose unambiguous. However, it doesn't differentiate this tool from its sibling 'update_event' beyond the obvious creation vs. update distinction, nor does it specify if this is for personal calendars, shared calendars, or specific platforms.
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 like 'update_event' for modifying existing events or 'find_free_slots' for scheduling. It doesn't mention prerequisites (e.g., calendar access permissions) or contextual cues for when creation is appropriate versus listing or deleting events.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a calendar event by its ID
| Name | Required | Description | Default |
|---|---|---|---|
| calendar | No | Calendar name (optional) | |
| eventId | Yes | Event ID to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but lacks behavioral details. It states the action ('Delete') but does not disclose critical traits like required permissions, whether deletion is permanent or reversible, error handling (e.g., for invalid IDs), or side effects (e.g., notifications to attendees).
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 is front-loaded with the core action and resource, 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations and no output schema, the description is incomplete. It lacks context on permissions, consequences, error cases, or return values, leaving significant gaps for safe and effective use by an AI agent.
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 both parameters ('calendar' as optional name, 'eventId' as required ID). The description adds no additional meaning beyond implying 'eventId' is used for deletion, aligning with but not enriching the schema. 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Delete') and resource ('a calendar event'), with precise targeting ('by its ID'). It distinguishes from siblings like 'create_event', 'update_event', and 'list_events' by focusing on removal rather than creation, modification, or listing.
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 does not mention prerequisites (e.g., needing an existing event ID), exclusions (e.g., not for recurring events), or comparisons to siblings like 'update_event' for modifications instead of deletion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find available time slots in the calendar
| Name | Required | Description | Default |
|---|---|---|---|
| calendar | No | Calendar name (optional) | |
| duration | No | Duration in minutes (optional, defaults to 30) | |
| endDate | No | End date in MM/DD/YYYY format (optional, defaults to 7 days from start date) | |
| startDate | Yes | Start date in MM/DD/YYYY format | |
| workDayEnd | No | Work day end hour (0-23) (optional, defaults to 17) | |
| workDayStart | No | Work day start hour (0-23) (optional, defaults to 9) |
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 only states the basic action. It doesn't cover critical aspects like whether this is a read-only operation, how results are formatted, if there are rate limits, or authentication requirements, leaving significant gaps for an agent to understand tool behavior.
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 directly states the tool's purpose without unnecessary words. It's front-loaded and appropriately sized for a simple query tool, with no wasted information.
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 (6 parameters, no output schema, and no annotations), the description is incomplete. It fails to explain return values, error conditions, or behavioral traits, making it inadequate for an agent to fully understand how to use this tool effectively in context.
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 input schema has 100% description coverage, so parameters like 'duration', 'workDayStart', and 'endDate' are well-documented there. The description adds no additional parameter semantics beyond implying time slot availability, which aligns with the schema but doesn't provide extra value, meeting 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 verb ('Find') and resource ('available time slots in the calendar'), making the purpose immediately understandable. However, it doesn't distinguish this tool from potential sibling tools like 'list_events' or 'get_calendars' that might also involve calendar queries, missing full differentiation.
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 like 'list_events' or 'get_calendars' from the sibling list. It lacks context about prerequisites, such as needing calendar access or when free slot queries are appropriate over other calendar operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the response status of meeting attendees
| Name | Required | Description | Default |
|---|---|---|---|
| calendar | No | Calendar name (optional) | |
| eventId | Yes | Event ID |
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 ('Check') but doesn't describe what 'response status' entails (e.g., accepted, declined, tentative), whether it requires specific permissions, or how results are returned (e.g., as a list, with timestamps). This leaves significant gaps in understanding the tool's behavior beyond its basic purpose.
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 directly states the tool's purpose without unnecessary words. It is front-loaded with the core action and resource, making it easy to parse. Every word earns its place, adhering to best practices for conciseness.
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 (checking attendee statuses, which could involve permissions or data formats) and the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'response status' means, how results are structured, or any prerequisites like authentication. This leaves the agent with insufficient information to use the tool effectively in real scenarios.
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 input schema has 100% description coverage, with clear documentation for 'calendar' (optional calendar name) and 'eventId' (required event ID). The description doesn't add any meaning beyond this, such as explaining how 'calendar' affects the lookup or what format 'eventId' should be in. Since the schema does the heavy lifting, the baseline score of 3 is appropriate.
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 ('Check') and resource ('response status of meeting attendees'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_events' or 'get_calendars', which might also provide attendee information in different contexts, so it falls short of a perfect score.
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. For example, it doesn't specify if this is for checking statuses after an event, during planning, or how it differs from 'list_events' which might include attendee details. This lack of context leaves the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available calendars
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. 'List available calendars' implies a read operation but doesn't disclose behavioral traits like whether it lists all calendars or only accessible ones, pagination, rate limits, or authentication requirements. This leaves significant gaps 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description 'List available calendars' is a single, efficient sentence that front-loads the core purpose with zero wasted words. It's appropriately sized for a simple tool with no parameters.
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 no annotations, no output schema, and multiple sibling tools, the description is incomplete. It doesn't explain what 'available' means (e.g., user-accessible vs. all), return format, or differentiation from similar tools, leaving the agent with insufficient context for optimal 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?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description doesn't need to add parameter details, and it appropriately doesn't mention any, earning a baseline score of 4 for this scenario.
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 'List available calendars' clearly states the verb ('List') and resource ('available calendars'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'list_events' or 'get_attendee_status', which prevents a perfect score.
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. With siblings like 'list_events' (for events within calendars) and 'find_free_slots' (for availability), there's clear need for differentiation, but the description offers none.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List calendar events within a specified date range
| Name | Required | Description | Default |
|---|---|---|---|
| calendar | No | Calendar name (optional) | |
| endDate | No | End date in MM/DD/YYYY format (optional) | |
| startDate | Yes | Start date in MM/DD/YYYY format |
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 basic action but lacks critical details: it doesn't mention whether this requires authentication, how results are returned (e.g., pagination, format), rate limits, or what happens if parameters are omitted. For a read 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without any wasted words. It's appropriately sized for a straightforward list operation, making it easy for an agent 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 (3 parameters, no output schema, no annotations), the description is incomplete. It lacks information on authentication needs, result format, pagination, error handling, or how it differs from siblings like 'find_free_slots'. Without annotations or output schema, the description should provide more context 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 the schema fully documents all three parameters (calendar, endDate, startDate) with their types, optionality, and format. The description adds no additional parameter semantics beyond implying date-range filtering, which is already covered in the schema. 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 verb ('List') and resource ('calendar events') with scope ('within a specified date range'). It distinguishes from siblings like 'create_event' or 'delete_event' by indicating a read operation, but doesn't explicitly differentiate from similar read tools like 'find_free_slots' or 'get_attendee_status'.
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 like 'find_free_slots' or 'get_calendars'. It mentions a date range but doesn't specify when this is preferable over other event-related tools, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing calendar event
| Name | Required | Description | Default |
|---|---|---|---|
| body | No | New event description/body (optional) | |
| calendar | No | Calendar name (optional) | |
| endDate | No | New end date in MM/DD/YYYY format (optional) | |
| endTime | No | New end time in HH:MM AM/PM format (optional) | |
| eventId | Yes | Event ID to update | |
| location | No | New event location (optional) | |
| startDate | No | New start date in MM/DD/YYYY format (optional) | |
| startTime | No | New start time in HH:MM AM/PM format (optional) | |
| subject | No | New event subject/title (optional) |
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 this is an update operation, implying mutation, but fails to describe critical behaviors: whether it requires specific permissions, if changes are reversible, how partial updates are handled, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Update an existing calendar event') with zero wasted words. It is appropriately sized for a tool with a clear name and well-documented schema, making it easy for an agent 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 complexity of a mutation tool with 9 parameters, no annotations, and no output schema, the description is incomplete. It lacks behavioral context (e.g., permissions, error handling), usage guidelines, and details on return values, leaving significant gaps for an agent to operate effectively. The high schema coverage helps but doesn't compensate for these omissions.
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 schema description coverage is 100%, with all 9 parameters well-documented in the input schema (e.g., formats like 'MM/DD/YYYY' for dates). The description adds no additional parameter semantics beyond what's in the schema, such as explaining interdependencies or default behaviors. With high schema coverage, the baseline score of 3 is appropriate as 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 verb ('Update') and resource ('an existing calendar event'), making the tool's function immediately understandable. It distinguishes this from 'create_event' (creating new) and 'delete_event' (removing), though it doesn't explicitly mention these siblings. The purpose is specific but lacks explicit sibling differentiation for a perfect score.
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 like 'create_event' or 'delete_event', nor does it mention prerequisites (e.g., needing an existing event ID) or contextual constraints. It simply states what the tool does without indicating appropriate scenarios, leaving the agent to infer usage from the tool name alone.
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.
v1.0.0create_eventdelete_eventfind_free_slotsget_attendee_statusget_calendarslist_eventsupdate_eventScored across 7 tools
Every tool has a clearly distinct purpose with no overlap: create, delete, list, and update events are separate operations, while find_free_slots, get_attendee_status, and get_calendars target unique aspects of calendar management. An agent can easily distinguish between them without confusion.
All tools follow a consistent verb_noun pattern using snake_case (e.g., create_event, list_events, get_calendars). The naming is predictable and readable throughout, with no deviations in style or convention.
With 7 tools, this server is well-scoped for managing an Outlook calendar. Each tool earns its place by covering essential operations like event CRUD, calendar listing, attendee tracking, and scheduling assistance, avoiding bloat or thin coverage.
The tool set provides complete CRUD/lifecycle coverage for calendar events (create, list, update, delete) and extends to key domain functions like finding free slots, checking attendee status, and listing calendars. There are no obvious gaps that would hinder agent workflows.
AI-native scheduling: check availability, book meetings, cancel and reschedule via MCP
Manage Google, Outlook & Apple calendars and create private sync rules from chat.
AI-native scheduler that lives in Claude. Describe meetings in plain English; Heldly does the rest.
Calendar API for AI agents: events, availability, Google/Microsoft setup, scheduling, and iCal.