Outlook Calendar MCP

Overview Schema Related Servers Score Discussions

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness5/5
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.
Average 3/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 2 issues responded to in the last 6 months
- No commit activity data available
- Last stable release on September 20, 2025
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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

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 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.
Conciseness5/5
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.
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 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.
Parameters3/5
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.
Purpose4/5
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.
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 '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.
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 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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
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_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.
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 ('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.
Conciseness5/5
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.
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 (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.
Parameters3/5
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.
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 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.
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. 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.
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 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.
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 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.
Completeness2/5
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.
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 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.
Purpose4/5
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.
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 '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.
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 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.
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 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.
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 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.
Parameters3/5
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.
Purpose4/5
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.
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' 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.
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. '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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters4/5
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.
Purpose4/5
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.
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. 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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
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 ('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.
Purpose5/5
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.
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 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.

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:

[![Outlook_Calendar_MCP MCP server](https://glama.ai/mcp/servers/merajmehrabi/Outlook_Calendar_MCP/badges/card.svg)](https://glama.ai/mcp/servers/merajmehrabi/Outlook_Calendar_MCP)

Score Badge

Copy to your README.md:

[![Outlook_Calendar_MCP MCP server](https://glama.ai/mcp/servers/merajmehrabi/Outlook_Calendar_MCP/badges/score.svg)](https://glama.ai/mcp/servers/merajmehrabi/Outlook_Calendar_MCP)

Latest Blog Posts

Lightport: Open-Sourcing Glama's AI Gateway
By punkpeye on April 27, 2026.
open source
OpenAI
Tool Definition Quality Score (TDQS)
By punkpeye on April 3, 2026.
mcp
The Hackers Who Tracked My Sleep Cycle
By punkpeye on March 26, 2026.
security

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/merajmehrabi/Outlook_Calendar_MCP'

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