outlook-web-mcp-server

by ma-nakaya

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.0
Disambiguation5/5
Each tool targets a distinct resource and action: auth status, email search, folder listing, email retrieval, read state, calendar events, and reply drafts. No two tools appear to do the same thing, and the descriptions clarify the boundaries (e.g., search_emails returns metadata only, get_email returns body).
Naming Consistency4/5
Most tools follow a consistent verb_noun pattern: search_emails, list_mail_folders, get_email, set_email_read_state, list_calendar_events, create_reply_draft. The outlier is outlook_auth_status, which uses a noun phrase and server prefix, breaking the verb-first convention slightly. Overall the pattern is still predictable and readable.
Tool Count5/5
Seven tools is well within the ideal range for an email/calendar integration. Each tool covers a distinct core operation without unnecessary bloat, and the count matches the apparent scope of the server.
Completeness4/5
The tool surface covers the key email workflows: searching, reading, marking read/unread, listing folders, and creating drafts. Calendar events are read-only. Minor gaps exist such as no move/delete email or create calendar events, but these are not fatal for typical agent use cases, and draft creation (as opposed to sending) is a deliberate safety choice.
Average 3.8/5 across 7 of 7 tools scored. Lowest: 3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description does not contradict them. The description adds the specific folder options, but does not disclose behavior around pagination, recursion, or authentication requirements, which is not covered by 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 12-word sentence that is front-loaded with the verb and resource. It is concise, direct, and contains no filler words.
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 6 parameters and an output schema, but the description only covers a fraction of the functionality. It omits the purpose of most parameters, does not describe the output shape (though the output schema exists), and offers no context about recursion or starting points, making it incomplete for correct invocation.
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?
With 0% schema description coverage, the description must compensate for parameter meanings. It only hints at the 'folder' parameter by naming Inbox, Sent, Drafts, while leaving storeId, maxDepth, recursive, maxResults, and parentFolderId entirely unexplained.
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 states a clear action ('List') and resource ('Inbox, Sent, Drafts, or a selected Outlook Web folder tree'), which distinguishes it from sibling tools that handle emails or calendar events. The only vagueness is 'selected' – it's unclear whether that means a specific named folder or a folder tree root.
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 gives no explicit guidance on when to use this tool versus alternatives like search_emails or get_email. It implies usage for folder enumeration, but does not mention exclusions or mention 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds the valuable warning that the email body is 'untrusted data', which is a non-obvious security consideration. However, it does not mention potential truncation via maxBodyCharacters or what happens if the email is not found, but with annotations covering the core safety traits, this extra context earns a 4.
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 that front-loads the action ('Read') and includes a critical security note. It is efficient with no waste, though one could argue it is so brief that it under-specifies usage and parameters. Still, it earns a 4 for being appropriately compact without being tautological.
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?
While the tool has an output schema (so return values are covered) and annotations for safety, the description is incomplete for a 3-parameter tool. It gives no usage guidance, no parameter semantics, and only a glimpse of behavior (untrusted body). The agent would need to infer too much, making the context incomplete.
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 0% and the description does not explain any parameters. It only hints at emailId via 'one selected', but storeId and maxBodyCharacters are completely unexplained. The description fails to compensate for the lack of schema descriptions.
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 a specific action ('Read') and a specific resource ('one selected Outlook Web email'). It distinguishes itself from siblings like search_emails and list_mail_folders by implying direct access to a single email, but it does not explicitly name alternatives or contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus siblings. It does not mention that this is for retrieving a specific email when you have an ID, or that search_emails should be used to find emails first. There is no when-not or alternative mention.
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 this as non-read-only, idempotent, and non-destructive, providing the core safety profile. The description adds 'Explicitly' and 'one selected', reinforcing the mutating and scoped nature, but does not disclose additional behavior such as persistence or side effects beyond what annotations imply.
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, focused sentence with no filler. It states the action, the resource, and the possible outcomes in a clear, front-loaded manner.
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?
The tool is simple and the description covers its core purpose. An output schema exists, so return values need not be described. Annotations handle safety aspects. The description could be slightly more explicit about parameter roles, but overall it is sufficient for a low-complexity tool.
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 0%, so the description must compensate. It clarifies that 'emailId' selects the email and 'isRead' sets the state, but 'storeId' is left unexplained. The description partially maps to two of three parameters but leaves a key parameter ambiguous.
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 ('mark') with a clear resource ('Outlook Web email') and a precise outcome ('read or unread'). It also specifies scope ('one selected'), effectively distinguishing it from siblings like get_email (which reads) and create_reply_draft (which composes).
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 changing the read state of an email, which is a distinct operation from the siblings. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites.
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 the key behavioral constraint that the tool never sends the email, which goes beyond the annotations (readOnlyHint: false, destructiveHint: false). It also clarifies the draft is for manual review. It doesn't mention potential side effects like overwriting existing drafts, but the core non-sending behavior is transparent.
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 direct, front-loaded, and brief. It communicates the action and key caveat with no unnecessary 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?
The description covers the core purpose and the critical non-sending behavior, but with 0% parameter coverage in the schema, it does not fully specify how to use the parameters. It also lacks mention of prerequisites or error scenarios, though the presence of an output schema may cover return values.
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 0%, so the description must compensate. The phrase 'reply or reply-all' maps to the replyAll boolean, but the required parameters emailId, storeId, and body are not explained in the description, leaving their roles ambiguous beyond their names.
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 saves a reply or reply-all draft and explicitly notes it never sends the email. This distinguishes it from any sending tool and from sibling tools that search, read, or update emails, establishing a specific action and resource.
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 drafts for manual review, and the 'never send it' caveat provides important usage context. However, it does not explicitly name alternatives or exclusion conditions, though no direct sending tool exists among the siblings.
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, idempotentHint, and destructiveHint=false, so the safety profile is established. The description adds valuable behavioral context beyond annotations by explaining that only metadata is returned and bodies require a separate get_email call, which is not implied by the annotations alone.
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 action and resource, contains no filler, and earns its place by adding a key behavioral caveat about message bodies. It is concise and well-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?
Despite strong annotations and an output schema, the tool has 9 optional parameters with no schema description coverage, and the description does not explain how those parameters should be used. This makes the overall tool description minimally viable but with clear gaps in parameter guidance and usage context.
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 0% with 9 parameters, and the description does not explain any parameter semantics (e.g., query, folder, daysBack, unreadOnly). The agent must rely entirely on the input schema, which provides types and defaults but no deeper meaning about how the parameters interact or should be used.
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 ('Search') and resource ('Outlook Web mail metadata'), and it distinguishes itself from get_email by noting that message bodies are opt-in via get_email. This clearly identifies both what the tool does and how it differs from a sibling 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 provides a clear usage context: it searches metadata and points to get_email for message bodies, which is a useful alternative. However, it does not explicitly state when to use search_emails versus list_mail_folders or other search scenarios, so it's slightly below full 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds valuable behavioral context: the 31-day maximum range and the ISO 8601 format requirement for the date strings, which are not encoded in the annotations or schema. This goes 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 core action ('List Outlook Web calendar events') and appends the key constraint. No wasted words; 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?
Given the presence of a rich annotations block and an output schema, the description is mostly complete. It clearly states the range constraint and format. The only missing contextual piece is behavior around maxResults, but overall the tool is adequately specified for its low complexity.
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?
With 0% schema description coverage, the description must compensate for all three parameters. It only explains the date range concept ('ISO 8601 range') which covers startsAfter and endsBefore implicitly, but it completely ignores maxResults. The parameter names are self-explanatory to some degree, but the lack of any mention of maxResults leaves a significant gap.
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 and resource: 'List Outlook Web calendar events', which clearly distinguishes this tool from sibling email tools like search_emails and get_email. The additional scope of 'ISO 8601 range of at most 31 days' further clarifies the 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for retrieving calendar events within a bounded date range, which is distinct from sibling tools. There is no explicit exclusion or alternative guidance, but the context is clear enough for an agent to select this tool over email-focused siblings.
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 indicate read-only, idempotent, non-destructive behavior. The description adds valuable context that the tool may refresh the auth token ('Refresh when possible') and that the returned status is non-secret, which is not covered by annotations. This enriches the behavioral profile.
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 of nine words, conveying all key points: refresh behavior, return of auth status, and non-secret nature. It is front-loaded, direct, and every word earns its place. There is no redundancy or 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 tool with no parameters and an output schema, the description is fully sufficient. It indicates the tool may refresh and returns non-secret status, which is essential context. The output schema handles return value details, so no further elaboration is 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 zero parameters, so there are no parameter descriptions to add. The baseline for zero-parameter tools is 4, and the description appropriately avoids inventing unnecessary parameter details. It focuses on the tool's behavior instead.
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: return Outlook authentication status, with the additional nuance of refreshing when possible. It uses a specific verb ('return') and resource ('Outlook authentication status'), and it is distinct from sibling tools that handle emails 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?
The description implies the tool is for checking authentication status, which is clear from context. It does not explicitly mention alternatives or exclusions, but no sibling tool has a similar purpose, so the usage context is evident. It provides adequate guidance for a niche auth tool.
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-web-mcp-server MCP server](https://glama.ai/mcp/servers/ma-nakaya/outlook-web-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/ma-nakaya/outlook-web-mcp-server)

Score Badge

Copy to your README.md:

[![outlook-web-mcp-server MCP server](https://glama.ai/mcp/servers/ma-nakaya/outlook-web-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/ma-nakaya/outlook-web-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/ma-nakaya/outlook-web-mcp-server'

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