mcp-outlook-desktop

by Jpatching

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
Disambiguation4/5
Tools are mostly distinct: message retrieval, listing, searching, drafting/sending, and calendar events are clearly separated. Minor overlap exists between list_messages and search_messages, and between create_draft and send_mail (send_mail can also create a draft if not confirmed), but descriptions clarify the intent.
Naming Consistency5/5
All tool names follow the consistent pattern 'outlook_<verb>_<noun>', such as outlook_list_messages, outlook_create_calendar_event, outlook_check_status. This is highly predictable and clear.
Tool Count5/5
With 9 tools covering email reading, searching, drafting/sending, folder management, calendar events, and status checking, the count is well-scoped for an Outlook desktop MCP server. Each tool serves a distinct function without unnecessary redundancy.
Completeness4/5
The toolset covers core email workflows (list, get, search, draft, send, folders) and calendar operations (list, create), plus connection status. Minor gaps: no update/delete for messages or events, and no calendar event update/delete, but these are less critical for typical automation and the core lifecycle is covered.
Average 3.5/5 across 9 of 9 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 15 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
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description should disclose behavioral traits like scope (entire mailbox vs. folder), result ordering, and whether it returns more than basic fields. It only vaguely says 'Search emails across the mailbox' without details on pagination, sorting, or that it might return metadata not full content.
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 one sentence, concise and front-loaded with the main purpose. However, it omits necessary information, but for what it has, it is appropriately sized with no filler.
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 an output schema (though not detailed here) but lacks parameter descriptions entirely. Given the complexity of search queries and the need for usage guidelines, the description is insufficient. It fails to cover important aspects like how to incorporate sender or subject filters, and how 'top' interacts with the search.
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?
Schema description coverage is 0%, meaning the schema provides no descriptions. The description only mentions 'query terms, sender, subject, etc.' but does not explain the 'top' parameter, which likely controls the number of results. The query parameter's syntax or expected format is not clarified, leaving the agent with minimal guidance.
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 indicates the tool searches emails with query terms, sender, subject, etc., which is a specific verb+resource. It distinguishes from siblings like outlook_list_messages and outlook_get_message, though it could more explicitly 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 gives no guidance on when to use this tool versus alternatives like outlook_list_messages or outlook_get_message. It does not state whether it searches the entire mailbox or if list_messages is for simpler listing. No exclusions or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that the tool creates and schedules, but does not mention side effects like sending invitations, modifying the calendar, permission requirements, or whether online meeting creation involves additional steps. This is a significant gap for a mutation tool.
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, tight sentence that directly conveys the core function. There is no wasted wording or repetition of schema details. It is appropriately front-loaded and easy to parse.
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 the tool's complexity (7 parameters, no annotations, no parameter descriptions), the description is severely under-specified. It does not explain required inputs, datetime format, attendee handling, or behavior for optional fields. The presence of an output schema covers return values, but the description still fails to provide essential context for correct invocation.
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 schema has 0% description coverage across 7 parameters, and the description adds no parameter information at all. It does not mention subject, start/end datetime, attendees, location, body, or online meeting. The word 'schedule' hints at time parameters but provides no format or semantics beyond what the schema's field names already imply.
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 action ('Create and schedule') and the resource ('meeting or event in Outlook Calendar'). This distinguishes it from sibling tools like outlook_list_calendar_events and outlook_send_mail, which perform different operations. The verb-resource combination is specific and unambiguous.
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 is provided on when to use this tool versus alternatives. The description does not mention any preconditions, expected use cases, or exclusions (e.g., when to use outlook_send_mail instead). There is no context about scheduling meetings versus simple events or how attendees are handled.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose any behavior beyond listing events, such as whether it returns only future events, pagination, timezone handling, or whether it excludes certain event types. The description is too brief to convey potential side effects or limitations, leaving the agent with uncertainties.
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 sentence, which is concise, but it is also vague. It is appropriately short for the low complexity, but it could provide more detail without becoming verbose. The structure is simple and front-loaded with the primary purpose, so it earns a 4 for conciseness, though it misses opportunities for clarifying details.
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 having an output schema, which could specify return values, the description lacks details about how the tool filters events (e.g., date range), how parameters interact, and potential limitations. The tool has moderate complexity with 4 parameters and no annotations, so the description is insufficient for full clarity. An output schema exists, but without knowing its contents, it may not cover behavioral aspects.
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 coverage is 0%, meaning the description does not explain any parameters. Although the parameter names (top, days_ahead, start_datetime, end_datetime) are somewhat self-explanatory, the description fails to clarify their usage, e.g., how they interact or what format dates should be in. With 0% coverage, the description must compensate, but it does not.
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 upcoming calendar events and meetings, specifying the resource (calendar events) and the action (list). It distinguishes from siblings like outlook_create_calendar_event and outlook_list_messages by focusing on calendar events, which is clear enough.
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 listing upcoming calendar events, but does not explicitly mention when not to use it or compare to alternatives. However, it intuitively fits a common need and the sibling names are distinct enough that usage is clear. There is no explicit guidance on when to use this instead of other tools, but the tool name and context make it reasonably clear.
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, the description must disclose behavior. It mentions it lists 'recent emails' but does not specify sorting order, default count, effects of unread_only, or what happens if folder doesn't exist. It also doesn't state that it is read-only or any side effects. This leaves significant behavioral ambiguity.
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 conveys the primary purpose. It is front-loaded with the action and resource. It is appropriately sized for a simple listing tool, though it could include a bit more context without becoming verbose.
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 is simple (3 optional params, no nested objects, no required params), the description covers the main purpose. It doesn't detail return structure because an output schema exists. However, it lacks details on parameter behaviors and usage conditions, so it is not fully complete but sufficiently adequate for straightforward 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 0%, so the description must add meaning. It mentions 'folder' (e.g., inbox, sentitems) but does not explain 'top' or 'unread_only' beyond the schema defaults. The folder examples add some value, but overall parameters remain weakly described, leaving the agent to infer semantics from names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and the resource 'emails from an Outlook mail folder', with examples of folders. It distinguishes from siblings like outlook_get_message (retrieve single) and outlook_list_folders (list folders), though it doesn't explicitly name them. It is specific enough for most agents.
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 context (e.g., listing inbox messages) but provides no explicit guidance on when to use this vs. alternatives like outlook_search_messages. The folder parameter hints at use cases, but there is no mention of 'when not to use'. This is adequate but has clear gaps.
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 burden. It mentions 'Content is safely encapsulated,' which hints at safety but is vague. It doesn't disclose whether this is a read-only operation, any authentication requirements, or what happens if the message ID is invalid. The description adds minimal behavioral context beyond the obvious 'get' action.
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, concise and front-loaded. It states the purpose and adds a safety note. 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?
The tool has an output schema (though not shown in detail), which may explain return values. The description is adequate for a simple get-by-ID tool, but it lacks details on error handling, permissions, or what 'full details' includes. Given the simplicity, it's minimally complete but could be more informative.
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 has only one parameter, message_id, with no description. The tool description says 'by its ID' but doesn't add format details (e.g., is it a GUID, a string format). Since schema coverage is 0%, the description should compensate, but it only minimally does. The parameter is self-explanatory, but the description doesn't add much 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?
The description clearly states the tool's purpose: to get full details and content of a specific email message by its ID. It uses a specific verb ('Get') and resource ('email message'), and the mention of 'by its ID' distinguishes it from list/search tools. However, it doesn't explicitly differentiate from sibling tools like outlook_list_messages or outlook_search_messages, which also deal with messages.
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: you need a message ID to retrieve a specific message. It doesn't explicitly state when to use this tool versus alternatives like list or search, nor does it mention any prerequisites (e.g., obtaining the ID from a list or search). The context is clear but lacks explicit guidance on 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It implies the tool creates a draft and does not send it (via 'Drafts folder' and 'Human-in-the-Loop review'), but it does not explicitly state that no email is sent, nor does it mention permissions, side effects, or the response format. It adds some context beyond the name but leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys purpose and usage context in under 20 words. Every word earns its place, with no fluff or redundancy.
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 5 parameters and an output schema, the description does not need to explain return values. It provides the key 'why' (HITL review) and clarifies the tool's role relative to sending. However, it lacks parameter semantics and does not mention prerequisites or error conditions, so it is not fully complete. The output schema and parameter names help, but the description could add more context.
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?
Schema description coverage is 0%, and the description provides no explanation of any parameters (e.g., reply_to_message_id, to_recipients). The agent must rely entirely on the schema, which does not convey the meaning or usage of each field. The description fails to compensate for the lack of parameter info.
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 states a specific action ('Create an email draft') and a specific resource ('Outlook Drafts folder'). It also distinguishes from siblings by noting this is the 'recommended method for Human-in-the-Loop review,' implying it is for draft creation rather than direct sending (e.g., outlook_send_mail).
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 'recommended method for Human-in-the-Loop review' gives clear guidance on when to use this tool (when human review is needed before sending). However, it does not explicitly name alternatives or state when not to use it, so it falls short of a 5.
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 the behavioral burden. It discloses the critical Human-in-the-Loop safety gate and the draft fallback, which is important beyond the schema's default value. It does not mention permissions or failure behavior, but the core side effect is well 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?
Two sentences, front-loaded with the primary action, and every sentence adds meaningful information. No filler or redundancy.
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 output schema covers return values and the input schema covers parameter names/types, but the description lacks parameter semantics and explicit alternative guidance. It is minimally complete for a simple send tool but has clear gaps.
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, but it only explains confirm_send. The meanings and usage of subject, body, to_recipients, and cc_recipients are left entirely to the schema, which is insufficient for a 5-parameter tool.
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 opens with 'Send an email through Outlook,' a specific verb and resource. The conditional 'otherwise creates a draft' clearly distinguishes this tool from the sibling outlook_create_draft.
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?
It provides clear context: confirm_send=True sends, otherwise it creates a draft, which effectively tells the agent when the tool will send versus draft. It does not explicitly name alternatives or state when not to use the tool, but the behavior is clear enough.
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 behavioral burden, and it only states that authentication and connection status are checked. It does not detail side effects, required infrastructure, or what failure states look like, though 'status check' implies a read-only diagnostic action and no data mutation.
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 directly states the tool's purpose without any filler, repetition, or unnecessary detail.
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?
This is a simple zero-parameter status check with an output schema, so the description does not need to explain return values or parameters. It is complete enough for an agent to understand the tool's role, though it could add one line about using it when other Outlook calls fail.
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 schema already provides complete parameter coverage. The description appropriately requires no parameter explanation, matching the baseline for a no-parameter tool.
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 identifies a specific verb-resource pairing: 'check' the 'Microsoft 365 Outlook authentication and connection status.' This distinguishes it from all sibling tools, which perform message, calendar, or folder operations rather than status verification.
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 makes clear that this tool is for verifying authentication and connectivity, which is naturally understood as a diagnostic/pre-flight check among the other Outlook operations. It does not explicitly state when not to use it, but the use case is evident given the zero-parameter, status-oriented design.
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 the full burden. The verb 'List' indicates a read-only operation, and the mention of unread/total counts clarifies what data is returned. It does not explicitly state 'does not modify anything', but no mutation is implied and the behavior is transparent for a listing tool.
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, and every word adds value. It avoids redundancy and is appropriately concise for the tool's simplicity.
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, an output schema that documents return values, and a simple list operation, the description fully covers the necessary context. It states what the tool lists and what the output includes, which is sufficient for an agent to select and invoke it 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 tool has zero parameters, and the schema is fully covered by the empty properties object. The description does not need to compensate for parameter semantics, and the baseline of 4 is appropriate since there is nothing to explain.
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 ('List') with a clear resource ('all mail folders in the Outlook account') and scopes the result ('with unread and total message counts'). It is unambiguous and distinguishes this tool from sibling messaging tools like list_messages or search_messages.
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 enumerating folders and their message counts, which is clear context for when it should be used. It does not explicitly name alternatives or exclusions, but given the simple scope (folders vs messages), the guidance is reasonably clear.
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:

[![mcp-outlook MCP server](https://glama.ai/mcp/servers/Jpatching/mcp-outlook/badges/card.svg)](https://glama.ai/mcp/servers/Jpatching/mcp-outlook)

Score Badge

Copy to your README.md:

[![mcp-outlook MCP server](https://glama.ai/mcp/servers/Jpatching/mcp-outlook/badges/score.svg)](https://glama.ai/mcp/servers/Jpatching/mcp-outlook)

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/Jpatching/mcp-outlook'

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