EWS Meeting MCP

by ap311036

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.17
Disambiguation5/5
All tools have clearly distinct purposes, with preview/confirmed pairs clearly differentiated and supporting tools (find, list, resolve, suggest) addressing separate needs. No overlap or ambiguity.
Naming Consistency5/5
All tools follow a consistent 'ews_verb_noun' pattern, with clear conventions for preview vs confirmed flows (e.g., ews_create_meeting_preview, ews_create_meeting_confirmed). No naming irregularities.
Tool Count5/5
17 tools is well-scoped for a meeting management server, covering setup, inspection, scheduling, creation, update, cancellation, and verification. Each tool serves a distinct and necessary function.
Completeness5/5
The tool surface covers the full lifecycle of meeting management from setup and attendee resolution to create/update/cancel with preview/confirmed flows, plus supporting tools like free/busy, room listing, and audit log. No obvious gaps for an organizer-focused server.
Average 3.9/5 across 17 of 17 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 6 commits in the last 12 weeks
- No stable releases found
- 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?
No annotations provided; description does not disclose behavioral traits like read-only nature, authentication needs, or return format. Only states the basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no wasted words, but it omits critical information, making it less useful despite brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter, no output schema, and no annotations, the description is severely incomplete. It does not explain the 'days' parameter, the output format, or usage restrictions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The 'days' parameter (integer, default 7, minimum 1) is not mentioned in the description. With 0% schema coverage, the description fails to add any meaning beyond the schema.
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?
Clearly states the action (list) and resource (upcoming events from the configured user's default calendar). Differentiates from sibling tools like ews_list_rooms and ews_find_calendar_events through specificity.
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 siblings such as ews_find_calendar_events. Does not mention alternatives or prerequisites.
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, description carries full burden. Only hints at non-destructive behavior ('without creating'). Does not disclose what information the preview returns, whether it checks availability, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single focused sentence with no wasted words. Front-loaded with the core purpose.
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?
Despite 8 parameters and no output schema, description is too sparse. Does not hint at return value, usage patterns, or how to interpret results. Incomplete for an agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 50% of parameters with descriptions. Description adds no additional meaning; critical required params like 'subject' and 'attendees' lack explanation.
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?
Description clearly states it previews a meeting invite without creating or sending, using specific verbs and resource ('preview', 'meeting invite'). Distinguishes from sibling 'ews_create_meeting_confirmed' which creates the event.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives like 'ews_update_meeting_preview' or 'ews_resolve_attendees'. Lacks context for prerequisites or use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions two sources (Exchange and static) and hints at credentials (static never requires them), but does not disclose rate limits, error handling, authentication requirements for the Exchange path, or what happens when no rooms are found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence (18 words) that front-loads the action and key differentiators. It earns its place without fluff, though it could be slightly more structured.
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?
The description lacks an explanation of the return format, which is important given no output schema. While the tool's parameters and sources are covered, the vague 'structured options' does not fully inform the agent about what to expect, such as properties of room objects or pagination.
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 80%, baseline is 3. The description adds some value beyond schema by clarifying that attendee_count hides rooms with insufficient capacity and that 'static' source never requires credentials. However, most parameter descriptions are similar to the schema.
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 verb 'List', the resource 'Exchange meeting rooms', and differentiates between dynamic room lists and static fallback. It also mentions the output as 'structured options for user selection', which distinguishes it from sibling tools that handle meetings, calendar events, or audits.
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 explicit guidance on when to use this tool versus alternatives. Given the 16 sibling tools, there is no mention of when not to use it or which other tools might be more appropriate for related tasks like finding free slots or resolving attendees.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It mentions using local policy defaults for workday_start, workday_end, and avoid, but lacks details on time zone handling, error conditions, or performance traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) and front-loaded with the main purpose. It could be slightly more structured but is effective.
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?
With 10 parameters and no output schema, the description is insufficient. It does not explain return format, how conflicts are resolved, or what 'nearest overlapping' means in practice.
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 coverage is 70%, so parameter descriptions exist. The description adds context about defaulting omitted parameters to local policy, but does not significantly extend beyond the schema.
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 tool suggests nearest overlapping free meeting slots for multiple attendees and optional rooms, which distinguishes it from siblings like ews_get_free_busy or ews_find_calendar_events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for finding free slots but does not explicitly state when to use this tool over alternatives, nor does it provide exclusions or when-not scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It lists returned data but does not state side effects, read-only nature, or authentication requirements. It adds some context but has 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?
Single sentence conveys purpose and outputs clearly without unnecessary words. Well-structured and front-loaded.
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?
No output schema, so description should cover return values. It lists them but not complete specifics. Could mention error behavior or typical use cases. Adequate but not thorough.
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?
Schema coverage is 100%, baseline 3. Description adds context beyond schema: explains that id comes from create/search and changekey from create/search/update/cancel preview, providing useful source information.
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 tool verifies a calendar item by EWS id and changekey, using a specific verb and resource. Among siblings with verbs like create, update, cancel, find, 'verify' is unique and distinguishes this tool's purpose.
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 ews_find_calendar_events or ews_probe. No explicit context or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains the resolution process but does not disclose side effects, permissions, or behavior on no match. Adequate but could be more thorough.
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?
Two sentences with no filler. Front-loaded with the core purpose, followed by direct usage guidance. Every sentence adds value.
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?
For a simple directory resolution tool with no output schema, the description covers purpose and key usage. However, it omits what happens if no match is found and the format of the returned data. Adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% only for 'attendees', and the description repeats that info. The 'limit' parameter lacks description in both schema and description, leaving its purpose unclear. Description fails to compensate for low schema coverage.
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?
Clearly states the tool resolves attendee names against a company Exchange directory, with specific verb 'Resolve' and resource 'attendees, aliases, or email addresses'. Distinct from sibling tools that handle meetings and calendar events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions 'before scheduling' as the context and instructs to ask the user if multiple matches occur. Does not explicitly exclude alternatives, but sibling tools don't offer similar functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes operation as 'Read', indicating non-destructive behavior. No annotations provided, so description carries full burden; lacks details on rate limits, error handling, or data freshness aspects.
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?
Single sentence, front-loaded with verb and resource, no wasted words.
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?
No output schema, and description does not explain the format of free/busy blocks. However, the tool name is self-explanatory and sibling tools exist for richer context.
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?
Adds meaning beyond schema by clarifying that 'attendees' are email addresses. Schema coverage is 67% (start and end have descriptions), but description compensates by specifying 'attendee email addresses' for the first parameter.
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?
Clearly states 'Read free/busy blocks' with specific resource (attendee email addresses). Distinguishes from siblings like ews_suggest_slots (suggest times) and ews_find_calendar_events (events).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage for reading free/busy blocks, but no explicit guidance on when to use vs alternatives like ews_find_calendar_events or ews_suggest_slots.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description bears full burden. Mentions move to trash and confirms boolean guard. Doesn't detail cancellation notices or reversibility.
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?
Two sentences: purpose and prerequisite. No filler, front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a confirmation tool: goal, key params, prerequisite action. No return value details needed. Highlights non-recurring limitation.
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 covers all 5 params with descriptions. Description only echoes confirm and confirmation_id, adding no new meaning beyond schema.
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?
Describes canceling a non-recurring meeting by moving it to trash. Verb 'cancel' and resource 'organizer meeting' are specific. Distinct from preview sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
States prerequisite: requires confirm=true and confirmation_id from preview. Implies workflow after preview. No explicit when-not, but clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states it checks connectivity and does not read calendar items, which is transparent but limited. It could be improved by explicitly stating that it makes a test connection and indicating no side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no extraneous information. The primary action is front-loaded, and the 'does not' clarification is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple connectivity check with no parameters and no output schema, the description is mostly complete. It covers what the tool does and what it does not do. Minor improvement could mention expected output or typical result (e.g., success/failure indicator).
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 no parameters, so the description adds no parameter-specific information. According to calibration, a baseline score of 4 is appropriate for zero-parameter tools with 100% schema coverage.
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 verb 'Check' and the resource 'configured EWS account can connect,' making the tool's purpose unambiguous. It also explicitly says 'Does not read calendar items,' which distinguishes it from many sibling tools that operate on calendar data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for verifying connectivity but does not provide explicit guidance on when to use this tool versus alternatives. It includes a negative statement about not reading calendar items, which helps prevent misuse, but lacks prerequisites or context for when this probe is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description clearly discloses the primary behavioral trait: no save or send. It adds context about requiring exact id and changekey. Could mention any temporary state changes or whether the preview modifies anything.
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, front-loaded sentence with no fluff. Every word adds value.
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?
The tool has 9 parameters and no output schema, yet the description does not specify what the preview returns (e.g., a diff, a summary). This leaves the agent uncertain about the output format.
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 baseline is 3. The description reiterates the required parameters ('exact id and changekey') but does not add new meaning or clarify how parameters affect the preview output.
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 uses specific language: 'Preview changes to an existing meeting using exact id and changekey.' It clearly distinguishes from siblings like ews_update_meeting_confirmed by stating it does not save or send updates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the tool is for previewing and does not save/send, which guides appropriate use. However, it does not explicitly name the confirmed sibling as the alternative for actual updates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 discloses that the tool does not delete, move, or send cancellations, indicating it is a read-only preview. However, it does not mention any other behavioral traits like whether it modifies state, requires specific permissions, or has rate limits. For a preview tool, the disclosure is adequate but not exhaustive.
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 sentence that is front-loaded and contains no redundant information. Every word serves a purpose.
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 no annotations and no output schema, the description is fairly complete for a preview tool. However, it does not describe the return value or what the preview actually shows (e.g., list of affected attendees). This is a gap that could be filled.
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?
Schema coverage is 100% with clear descriptions. The description adds value by emphasizing the use of 'exact' id and changekey, and implicitly clarifies that the send_meeting_cancellations parameter is ignored (since it states 'does not send cancellations'). This provides semantic context beyond the schema.
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 tool's purpose: 'Preview cancellation of an existing meeting using exact id and changekey.' It also explicitly states what it does not do ('does not delete, move, or send cancellations'), distinguishing it from siblings like ews_cancel_meeting_confirmed that actually send cancellations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is for previewing before actual cancellation, with the sibling ews_cancel_meeting_confirmed for the actual action. However, it does not explicitly state prerequisites (e.g., need to have the id/changekey from a previous fetch) or scenarios when to choose this over other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It reveals read-only behavior and explicitly states no external calls or credential reading. It does not cover limit behavior or return format, but given the simplicity, it is adequate.
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?
Two succinct sentences with no redundant information. The first sentence front-loads the purpose, and the second clarifies a key behavioral aspect.
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 three parameters and no output schema, the description covers purpose and read-only nature but omits expected return format or pagination behavior. It is adequate but incomplete for a fully self-contained description.
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 coverage is 67% (two of three parameters have descriptions). The description does not add meaning beyond the schema; it only restates the action and status filters without extra detail. The 'limit' parameter is left undocumented in schema and description, so baseline 3 is appropriate.
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 verb 'Read' and the resource 'recent local lifecycle audit entries for meeting preview, confirmed, duplicate, in-progress, and error actions.' It also distinguishes from other tools by noting it does not read EWS credentials or call Exchange.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage (reading local audit entries) and hints that it is not for Exchange operations. However, it does not explicitly state when to use it vs. alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It clearly labels the tool as 'Read-only' and specifies return metadata (id and changekey), but does not cover authorization requirements or potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, each adding value: first sentence defines purpose and nature, second sentence details return metadata. No redundant or irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 7 parameters and no output schema, the description covers key behavioral aspects (read-only, return metadata). It lacks details on pagination or error handling, but the schema fills in parameter specifics.
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 coverage is 86%, and the schema already has detailed descriptions for each parameter. The description adds minimal new meaning beyond stating 'time window' for start/end. No further parameter guidance is provided.
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 provides a specific verb ('search') and resource ('calendar events'), clearly distinguishing this read-only tool from sibling mutation tools like ews_create_meeting_confirmed. It explicitly mentions the EWS id and changekey metadata, which are unique to this tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states the tool is for 'safe preview-confirm update or cancel flows,' giving context for when to use it. However, it does not explicitly exclude other scenarios or compare with siblings like ews_suggest_slots or ews_get_free_busy.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses key requirements (confirm=true, confirmation_id) and field limitations, but it does not mention behavioral traits such as the default sending of meeting invitations, permission needs, or idempotency. Some transparency is present but gaps remain.
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: two sentences that front-load the purpose and immediately provide essential requirements and limitations. Every sentence contributes meaning without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 11 parameters (4 required) and no output schema, the description covers the core workflow (preview then confirmed) and lists updatable fields. It lacks details on return behavior or the send_meeting_invitations parameter, but it is sufficiently complete for the primary use case.
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?
Schema coverage is 100% (baseline 3). The description adds value by emphasizing that only subject, start, end, location, and body are supported for updates, which clarifies the role of id and changekey as identifiers. This context goes beyond the schema descriptions.
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 verb 'Update an existing meeting' and the specific resource. It distinguishes from sibling tools like ews_update_meeting_preview by emphasizing the confirmed step, and it lists the limited set of supported fields, making the purpose highly specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use this tool: after obtaining confirmation_id from ews_update_meeting_preview and with confirm=true. It provides clear context but does not explicitly exclude other sibling tools like create or cancel, though the name and description imply the use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description responsibly discloses that the tool does not reveal the password and returns required_action and setup_command if credentials are missing. It could further clarify the return format when credentials are present, but the safety and action implications are covered.
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?
A single concise sentence that front-loads the main purpose and includes a critical usage instruction. Every word adds value, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool with no output schema, the description sufficiently covers purpose, behavioral constraints, and required user action. The agent can correctly select and invoke the tool.
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?
There are no parameters, and the schema coverage is 100%. The description does not need to add parameter details. Baseline 4 is appropriate.
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 tool checks EWS password credential availability from environment variables or macOS Keychain without revealing the password. It specifies the resource and action, and implicitly distinguishes from siblings like ews_setup_check by focusing on credential status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use (to check credentials) and provides an important usage note: the returned setup_command must be shown verbatim. However, it does not explicitly state when not to use or suggest alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 discloses that the tool returns a ready flag and, if false, provides user_message or setup_command. This is adequate for a simple check tool, though it does not detail error handling or throttling, which are likely not applicable.
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, using two sentences that front-load the purpose and then provide actionable guidance. Every sentence adds value and there is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has zero parameters and no output schema, the description is complete. It explains the tool's role in the EWS workflow (setup check before scheduling) and what information it provides (ready flag, user_message/setup_command). No additional details are needed.
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 no parameters, so the description adds meaning beyond the empty schema by explaining what the tool returns and the conditions under which it returns different values. This helps the agent understand the tool's behavior without needing an output schema.
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 tool's purpose: 'Return whether EWS setup is ready', and specifies the checks performed (env and password/Keychain). It distinguishes itself from sibling tools which focus on meetings and calendar operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implicit usage guidance by saying 'stop before scheduling when ready is false', indicating the tool should be used before scheduling operations. It does not explicitly mention when not to use it or list alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states the tool sends invitations (destructive) and requires confirm=true and matching confirmation_id. It doesn't mention side effects like email notifications or idempotency, but the core behavior is disclosed clearly.
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?
Two sentences: first states purpose, second gives usage condition. No redundant information. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters, 6 required, and no output schema, the description covers purpose, prerequisite (preview), and required flags. It does not describe return value or error cases, but for a create tool with sibling preview, this is adequate.
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?
Schema description coverage is 60% and already documents most parameters. The description adds context that confirmation_id must match the one from ews_create_meeting_preview and that confirm must be true. This adds semantic meaning beyond the schema.
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?
Description clearly states 'Create a meeting and send invitations', providing a specific verb and resource. It distinguishes from sibling tools like ews_create_meeting_preview (preview step) and ews_update_meeting_confirmed (update vs create).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Only call after the user explicitly confirms the exact attendees, time, subject, body, and location' and specifies required parameters confirm and confirmation_id. This gives clear when-to-use guidance and implies when not to use (before user confirmation).
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:

[![ews-meeting-mcp MCP server](https://glama.ai/mcp/servers/ap311036/ews-meeting-mcp/badges/card.svg)](https://glama.ai/mcp/servers/ap311036/ews-meeting-mcp)

Score Badge

Copy to your README.md:

[![ews-meeting-mcp MCP server](https://glama.ai/mcp/servers/ap311036/ews-meeting-mcp/badges/score.svg)](https://glama.ai/mcp/servers/ap311036/ews-meeting-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/ap311036/ews-meeting-mcp'

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