ews-outlook-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct resource/action combination: email operations (list, search, get, send, reply, forward, move, flag) are clearly separated from calendar operations (list, create, update, delete, accept, decline, add_attendee) and contact resolution. No two tools have overlapping or ambiguous purposes.
Naming Consistency4/5
The vast majority of tools follow the ews_verb_noun pattern consistently (e.g., ews_list_inbox, ews_create_event, ews_forward_message). The only deviation is ews_today_summary, which lacks a verb and breaks the otherwise uniform convention.
Tool Count4/5
At 18 tools, the set is slightly above the typical well-scoped range, but the count is justified by covering two major Outlook domains (email and calendar) plus contacts. Each tool has a clear role, so the size feels reasonable rather than bloated.
Completeness4/5
Core workflows for email (list, read, send, reply, forward, move, flag) and calendar (list, create, update, delete, accept/decline invitations, add attendees) are covered. Notable gaps include lack of email deletion and no dedicated get-event tool, but these are workaroundable via list and update/delete.
Average 4.1/5 across 18 of 18 tools scored. Lowest: 3.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 7 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is not read-only and not destructive, so the description adds no extra behavioral context. It does not mention side effects (e.g., sending a response to the organizer or updating the calendar), missing an opportunity to enrich the agent's understanding.
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 redundant information. It efficiently communicates the purpose and the input mechanism.
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 two-parameter accept action, the description, schema, and annotations provide a basic functional picture. However, it lacks usage differentiation and behavioral side-effect context, leaving some gaps for a fully self-contained understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both eventId and comment described. The description mentions the ItemId input but adds no additional semantic value beyond the schema, so the baseline of 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 tool accepts a received meeting invitation using the ItemId, which is a specific verb+resource combination. It distinguishes from sibling tools like ews_decline_event (declines) and ews_update_event (updates).
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 by indicating it operates on a received invitation, but it does not explicitly state when to use this tool versus alternatives like accept vs decline. No exclusions or alternative references 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?
Annotations already signal a mutation (readOnlyHint=false). The description adds that it composes and sends an email, which is consistent. But it does not disclose additional behavioral traits such as immediate sending, irreversibility, or any prerequisites. It adds some value but not rich context beyond the annotations.
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, well-structured sentence that front-loads the action and resource, with a parenthetical exclusion. Every word earns its place; no redundancy or filler.
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 is adequate for a simple send operation with complete schema and annotations, but it lacks explicit guidance on distinguishing from forwarding, a key sibling tool. This creates an ambiguous edge case for an AI agent deciding between ews_send_message and ews_forward_message.
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% parameter coverage with descriptions for to, subject, body, and cc. The description itself adds no parameter-level semantics, so it relies on the schema. This meets 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 action ('Redacta y envía') and resource ('un correo nuevo'), and explicitly excludes replies ('no una respuesta'). However, it does not mention distinguishing from forwards, despite ews_forward_message being a sibling tool. This is a minor differentiation gap.
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 gives an explicit when-not-to-use hint by saying 'no una respuesta', which excludes reply tools. However, it omits the forward alternative entirely, so the guidance is partial and does not cover a likely sibling. It falls between 'implied usage' and 'clear context with exclusions'.
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?
Annotations already declare readOnlyHint=true, so safety is covered. The description adds the behavioral details of returning messages from newest to oldest and focusing on the most recent, but it does not disclose potential return format, pagination behavior, or what happens when more messages exist than the limit. This is similar to the high-calibration example.
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, concise sentence that immediately conveys the core action and scope. No redundant information, and it is front-loaded with the verb and resource.
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 list tool with two optional, well-documented parameters and read-only annotations, the description is largely adequate. It clearly communicates the purpose and ordering, though it lacks explicit mention of pagination or return fields. Given the absence of an output schema, a bit more detail could improve completeness, but it is not severely deficient.
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% for both parameters (limit and unreadOnly), so the schema fully documents them. The description does not add extra meaning beyond what the schema already provides, hence the baseline score of 3.
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 lists the most recent inbox messages, newest to oldest. The verb 'Lista' and resource 'bandeja de entrada' are specific, and the scope (recent, ordered) distinguishes it from sibling tools like ews_search_inbox or ews_get_message.
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 retrieving recent inbox messages, but it does not explicitly state when to use this tool over alternatives (e.g., for searching, use ews_search_inbox). It provides no exclusions or alternative guidance beyond the inherent implication.
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?
Annotations already indicate this is a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds minor context about moving messages, but does not go beyond annotations in disclosing side effects, permissions, or edge cases. It provides adequate but not rich behavioral detail.
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 that directly states the core action and provides useful examples. Every word contributes meaning, with no unnecessary elaboration or repetition. It is highly concise and well-structured.
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 tool with 2 parameters, full schema coverage, and annotations, the description is largely complete. It states the purpose, gives examples, and relies on the schema for parameter details. However, it does not explicitly clarify that only the enum folder values are allowed, and the 'follow-up folder' example could mislead users since it is not an available enum value. Additionally, it does not mention that moving to 'deleteditems' is effectively an archive/delete action, though the schema does. Overall, it is adequate but with minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description itself does not add parameter-specific details; it merely mentions moving to 'another folder' and gives generic examples. The schema already documents the folder enum and itemId, so the description adds no significant semantic value 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 function: 'Mueve un mensaje a otra carpeta del buzón' (Moves a message to another mailbox folder). It specifies a distinct action (move) and resource (message), setting it apart from sibling tools like send, reply, or flag. The examples ('archivar, mover a una carpeta de seguimiento') further clarify intended use.
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 through examples (archiving, follow-up organization) but does not explicitly state when to use this tool versus alternatives. It lacks clear exclusions or direct comparisons to sibling tools. This is enough for an implied understanding, but not explicit guidance.
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?
The description goes beyond the annotations by disclosing that it sends an invitation to the new attendee and does not modify existing attendees, which are important side effects. It also reveals the underlying UpdateItem call, providing technical 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?
It is a single, well-structured sentence that packs all key information: the action, the API method, the side effect, and the guarantee about other attendees. No wasted words.
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 tool with two simple parameters and no output schema, the description covers the action, the side effects, and the constraint on other attendees. It could optionally mention error cases or return value, but the tool's simplicity and schema descriptions make the current description sufficient.
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 already fully describes both parameters, and the description adds only the nuance that the attendee is added as 'requerido' (required). This adds minor semantic value beyond the schema, so it meets the baseline for 100% coverage without needing to compensate.
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 adds a required attendee to an existing meeting, specifying it uses UpdateItem and sends the invitation, while not affecting other attendees. This distinguishes it from siblings like ews_update_event or ews_create_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?
The description implies the tool is for adding an attendee to an existing meeting, but it does not explicitly state when to use it over alternatives or provide exclusions. The context is clear but lacks the explicitness of naming alternative tools, so it gets an implied-use score.
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?
Annotations provide baseline safety info (readOnlyHint=false, destructiveHint=false). The description adds the detail that it operates on the invitation message's ItemId, but it does not disclose behavioral traits such as whether a decline response is sent to the organizer or what happens to the calendar event. With annotations present, this is adequate but not rich.
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, direct sentence with no filler or redundancy. It communicates the action, resource, and input method efficiently, earning the maximum score.
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's low complexity (2 params, full schema coverage, annotations present), the description provides sufficient context. It lacks explicit details about return values or side effects, but these are not strictly necessary for such a simple mutation tool. Slight elevation from 3 because the description clarifies the specific input identifier type, making it more complete than a generic 'declines an invitation'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters already described in the schema. The description only minimally reinforces the meaning of eventId (por ItemId del mensaje de invitación) without adding substantial new information, so 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Rechaza') and resource ('invitación de reunión'), clearly distinguishing it from sibling tools like accept_event, delete_event, and update_event. It also specifies the input method (por ItemId del mensaje de invitación), making the tool's purpose unambiguous.
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 usage context (declining a received meeting invitation) and specifies the required identifier type (ItemId of the invitation message). However, it does not explicitly differentiate from accept_event or delete_event, nor does it mention any preconditions or when not to use this tool, which would merit a 5.
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?
Annotations already declare readOnlyHint=true, covering the read-only safety profile. The description adds the date-range scope and a concrete ISO 8601 example, but does not disclose return structure, ordering, pagination, or boundary inclusivity.
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 with the verb and resource. It contains no filler or redundant 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 simple 2-parameter listing tool with useful annotations, the description provides enough context for selection and invocation. No output schema exists, so return details are not specified, but 'list events' inherently implies a collection of calendar events.
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 input schema fully documents both parameters with ISO 8601 descriptions, giving a baseline of 3. The description adds value by providing a concrete example with a timezone offset (2026-07-30T00:00:00-05:00), clarifying the expected string format 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 uses the specific verb 'Lista' with the resource 'eventos del calendario' and scopes the operation to a date range in ISO 8601 format. This clearly distinguishes it from sibling tools like create_event, update_event, or list_inbox.
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 date-range condition implies when to use this tool: to retrieve calendar events between two dates. However, it does not explicitly mention alternatives or exclusions, such as 'use get_message for a single message' or 'use today_summary for a daily overview.'
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?
The annotation readOnlyHint=true already communicates that this is a safe read operation. The description adds useful context by specifying the search scope (Inbox) and behavior (simple substring search on subject). However, it does not disclose additional behavioral details like result ordering, case sensitivity, or pagination behavior, which could be relevant for an agent.
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, concise sentence that front-loads the verb and resource. Every word earns its place, avoiding unnecessary detail or repetition. It is appropriately succinct for a simple tool.
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 simple search tool with clear annotations (readOnlyHint=true), a well-defined schema, and no output schema, the description is complete enough. It states what is searched, where, and how (substring on subject), and the schema handles parameters. No additional context is necessary for correct 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 50%: 'query' has a description in the schema ('Texto a buscar en el asunto del correo'), and the tool description reinforces its meaning. The 'limit' parameter has no schema description, but its name and constraints (integer, default 15, max 50) are self-explanatory. The description does not add detail beyond the schema, but the parameters are simple enough that this is acceptable.
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: to search messages in the Inbox by subject substring. It uses a specific verb ('Busca'), indicates the target resource ('mensajes en Inbox'), and specifies the filter criterion ('Asunto contenga el texto indicado'). This distinguishes it from sibling tools like ews_list_inbox (lists all) and ews_get_message (retrieves a specific message).
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 when to use the tool: when you need to find messages in the Inbox by subject text. However, it does not explicitly mention alternatives or when not to use it, such as when full-text search or folder-wide search is needed. It lacks the explicit exclusionary guidance seen in top-tier examples.
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?
Annotations indicate readOnlyHint=false, so the agent knows it's a write operation. The description adds the behavioral trait that passing attendees sends meeting invitations, which is beyond the schema and annotations, providing useful side-effect context without contradiction.
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 concise sentences, front-loaded with the primary purpose and a behavioral condition. No unnecessary words or repetition.
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 create tool with 6 parameters and no output schema, the description provides essential behavior (create event, optionally send invites) and distinguishes it among 18 siblings. It doesn't describe return values, but the schema covers parameter details adequately.
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 explicitly mentions the attendees condition, reinforcing the schema's note, but does not add new parameter-level semantics for subject/start/end beyond what the schema already provides.
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 'Crea un evento en el calendario' (Creates an event in the calendar), specifying the action and resource. It also mentions 'CreateItem CalendarItem' which anchors the EWS operation, distinguishing it from siblings like ews_update_event, ews_delete_event, and ews_accept_event.
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 the tool is for creating calendar events, which differentiates it from update/delete/accept/decline siblings. However, it does not explicitly state when not to use it or point to alternative tools; the condition about attendees is a behavioral note rather than an alternative guide.
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?
Annotations already declare destructiveHint=true and readOnlyHint=false. The description adds valuable behavioral context: that attendees receive cancellation by default, which is not inferable from the annotations. No contradiction.
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 short sentences, front-loaded with the main action, no unnecessary words. Efficient and clear.
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 delete tool with two parameters and no output schema, the description plus annotations provide sufficient context. The attendee-notification behavior is a key extra. Irreversibility is covered by destructiveHint.
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 covers 100% of parameters with descriptions. The description restates the default of notifyAttendees ('por defecto') but does not add significant new semantics beyond the schema. 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 uses a specific verb 'Elimina' (delete) with a clear resource 'evento del calendario' (calendar event), and includes the EWS operation name (DeleteItem). This clearly distinguishes it from sibling tools like ews_update_event or ews_create_event.
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 context is clear: this is the tool for deleting calendar events, with an additional note about notifyAttendees default behavior. However, it does not explicitly mention alternatives or when not to use it, but the deletion purpose is evident.
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?
The description adds behavioral detail beyond the readOnlyHint annotation by specifying exactly what the summary includes (unread count and today's events). It also narrows scope to 'hoy' and 'Inbox', providing useful limitations. No contradictions with annotations.
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 that conveys the exact purpose without fluff. It is concise and well-structured.
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 zero-parameter tool with no output schema, the description adequately explains what to expect: unread email count and today's calendar events. It could elaborate on the format of the events or the timezone, but for a simple summary tool it is sufficiently complete.
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 according to the rubric the baseline is 4. The description does not need to explain parameters; it focuses on the result composition.
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 provides a quick summary of unread Inbox emails and today's calendar events. It uses a specific verb 'Resumen' and specifies the resources (Inbox, calendar), distinguishing it from sibling tools like ews_list_inbox and ews_list_calendar.
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 a quick daily briefing but does not explicitly compare against alternative tools. It lacks guidance on when to choose this over calling ews_list_inbox and ews_list_calendar separately, so the usage context is only implied.
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?
Annotations indicate readOnlyHint=false, signaling a write operation. The description goes further by explicitly enumerating the three possible actions (set, complete, clear) and their outcomes, which is meaningful behavioral context beyond the raw schema enum. It also clarifies the semantic equivalence to Outlook's flag feature. No contradictions with annotations.
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 highly efficient and directly to the point. It conveys the action, scope, and semantic reference without unnecessary elaboration. Both title and description are concise and well-structured.
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 simple, two-parameter tool with no output schema, the description combined with the schema provides complete information. The tool's behavior is fully explained, and no additional context about return values or edge cases is needed. The Outlook analogy aids understanding for users familiar with email clients.
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 100%, with both parameters (itemId, status) having descriptive text and the status parameter including an enum with clear meanings. The description itself does not add parameter-specific detail, but the baseline of 3 applies because the schema fully explains the parameters, so the description does not need to compensate.
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 a specific verb+resource structure: 'Pone, quita o completa la bandera de seguimiento' (sets, removes, or completes the follow-up flag). This clearly states the tool's function and is unique among siblings, as no other tool handles flags. The Outlook analogy provides additional concrete context.
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 clearly implies when to use this tool: to manage follow-up flags on emails. Since no sibling tool performs flag operations, the intended usage is unambiguous. However, it lacks explicit 'use this when' language or explicit exclusions, though these are not necessary given the tool's uniqueness.
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?
Las anotaciones ya indican que no es una operación de solo lectura (readOnlyHint=false). La descripción añade que el envío es 'inmediatamente', un detalle útil pero menor. No contradice las anotaciones ni revela efectos adicionales relevantes.
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?
Una sola oración que comunica la función y la opción clave. Sin redundancias ni información superflua, logra máxima claridad en mínimo espacio.
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?
Para una herramienta simple con 3 parámetros, sin esquema de salida y con anotaciones básicas, la descripción cubre los aspectos esenciales: la acción, el destinatario inmediato y la opción replyAll. Es suficiente para entender el comportamiento y usarla correctamente.
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?
El esquema documenta body e itemId, pero replyAll carece de descripción en el schema. La descripción compensa explicando que replyAll=true corresponde a 'Responder a todos', añadiendo significado a un parámetro que de otro modo sería ambiguo.
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?
La descripción usa un verbo específico ('Responde') y un recurso concreto ('correo existente por ItemId'), diferenciándose claramente de herramientas similares como ews_send_message (enviar nuevo) o ews_forward_message (reenviar). Señala la acción principal y el mecanismo de identificación.
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?
Proporciona un contexto claro: se usa para responder a un correo existente. Aunque no menciona explícitamente cuándo no usarla o alternativas, la referencia a 'existente' delimita el caso de uso y la distingue de crear un mensaje nuevo.
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?
Annotations already declare readOnlyHint=true, so the safety profile is known. The description adds behavioral context beyond that: it performs partial-name matching, returns email addresses, and is scoped to the company's GAL. It doesn't detail result limits or error handling, but the added context is meaningful.
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 concise sentences: the first directly states the tool's function, the second provides usage context. No redundant detail, and the key information is front-loaded.
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 single-parameter, read-only search tool with no output schema, the description adequately covers what it does, what it returns (matches with email), and when to use it. The annotations handle the safety profile, making this complete.
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 100% with the 'nombre' parameter description including an example ('ej. Felipe Castillo'). The description merely restates that the search is by partial name, adding no new parameter-level meaning, so the baseline of 3 applies.
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 searches by partial name in the Global Address List and returns matches with their email, specifying the exact resource ('Global Address List de Integral de Empaques') and the result. This distinguishes it from sibling tools like ews_search_inbox or ews_add_attendee.
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 explicit when-to-use guidance: 'Úsalo antes de invitar a alguien por nombre a una reunión, para confirmar el correo correcto.' It lacks explicit when-not-to-use or alternative tool mentions, but the context is clear enough for a single-purpose tool.
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?
Annotations already establish readOnlyHint=false and destructiveHint=false. The description adds the key behavioral detail that only provided fields are updated (merge semantics), which is not disclosed by annotations. This is valuable context and does not contradict the annotations.
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?
One sentence conveys the core action, scope, and update semantics with zero redundancy. It is appropriately front-loaded with the action ('Cambia') and includes a technical reference (UpdateItem) without excess.
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 straightforward update tool with full schema descriptions and annotations, this description is sufficient. It does not explain error behavior or return values, but that is not necessary given the simple nature and absence of an output schema. The partial-update note is essential and present.
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%, so baseline is 3. The description adds meaning by clarifying that only passed fields are updated, which explains the optionality of start/end/subject/location and reinforces the partial-update behavior. This goes beyond the individual parameter 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 uses a specific verb ('cambia') and names the resource ('evento existente') plus the editable fields (horario, asunto, lugar). Mentioning 'UpdateItem' ties it to EWS and clearly distinguishes it from sibling create, delete, accept, and decline tools.
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 phrase 'evento existente' implies it is for editing existing records, not creating or deleting. 'Solo actualiza los campos que pases' provides explicit partial-update guidance. However, it does not name alternative tools or state when not to use it, so it falls short of explicit exclusion.
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?
The readOnlyHint annotation already marks this as read-only; the description adds value by specifying exactly which parts of the message are returned (body, sender, recipients), which is useful behavioral context beyond the schema. No contradiction.
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, focused sentence that front-loads the action and resource, then adds the essential sourcing information. No filler.
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 simple read tool with one parameter and no output schema, the description covers what it returns (body, sender, recipients), how to get the ID, and is a read operation. It's sufficiently complete for an agent to invoke correctly.
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 schema already provides a description for itemId, but the tool description enriches it by explaining the ItemId's provenance (obtained from ews_list_inbox or ews_search_inbox), which helps agents know how to acquire a valid value.
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 a specific verb 'Obtiene' and specifies the resource 'contenido completo (cuerpo, remitente, destinatarios)' and the identifier 'ItemId'. It also references sibling tools for obtaining the ID, making it clear this is the fetch-full-message tool, distinct from reply/forward etc.
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 clearly indicates the prerequisite: the ItemId comes from ews_list_inbox or ews_search_inbox, implying this tool is used after those list/search operations to retrieve full content. It doesn't explicitly contrast with alternatives, but the context is strong enough.
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?
Discloses that the message is sent immediately and that previous recipients are not carried unless repeated in 'to', adding behavioral context beyond the annotations. Could further mention outcome details like sent item creation, but the current coverage is strong.
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, front-loaded with the core action in the first sentence and a clarifying distinction in the second. No extraneous content, every word earns its place.
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 mutation tool with full schema coverage and no output schema, the description sufficiently covers the main behavior and key differentiator. It might optionally note prerequisites or side effects like sent copy, but the current description is adequate for correct invocation.
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 input schema already has 100% coverage with descriptions for all three parameters. The tool description adds the nuance that recipients are 'nuevos' (new) and reinforces the optionality of the comment, providing a small but meaningful semantic increment over 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 uses the specific verb 'Reenvía' (forwards) and clearly identifies the resource as an existing email by ItemId, with optional comment. It also distinguishes from replying by stating the original thread does not carry previous recipients unless repeated, making it unambiguous among siblings.
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 contrasts with 'responder' (reply) and explains the difference in thread behavior, providing clear guidance on when to forward vs reply. This directly addresses the most similar sibling tool, ews_reply_message.
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?
readOnlyHint already declares the operation safe; the description adds behavioral detail that custom folders are included and unread counts are returned. No contradictions with annotations.
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 concise with two sentences: first states the output, second provides usage timing. No unnecessary words or 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?
Given zero parameters, no output schema, and a readOnly annotation, the description fully covers what the tool does, when to use it, and the scope of folders returned.
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 zero parameters, so the description need not explain parameter semantics. A baseline of 4 is appropriate since there is no parameter burden.
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 lists mailbox folders (Inbox, Archive, custom folders) with unread email counts. This specific verb+resource+scope distinguishes it from sibling ews_list_inbox, which lists messages rather than folders.
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?
The description explicitly says to use this tool before moving an email to a non-standard folder, providing clear when-to-use guidance and implicitly distinguishing it from standard folder moves.
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-Exchange-MCP-Server MCP server](https://glama.ai/mcp/servers/devsergioherrera/Outlook-Exchange-MCP-Server/badges/card.svg)](https://glama.ai/mcp/servers/devsergioherrera/Outlook-Exchange-MCP-Server)

Score Badge

Copy to your README.md:

[![Outlook-Exchange-MCP-Server MCP server](https://glama.ai/mcp/servers/devsergioherrera/Outlook-Exchange-MCP-Server/badges/score.svg)](https://glama.ai/mcp/servers/devsergioherrera/Outlook-Exchange-MCP-Server)

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/devsergioherrera/Outlook-Exchange-MCP-Server'

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