Skip to main content
Glama
desek

outlook-local-mcp

system

Read-onlyIdempotent

Diagnose Outlook MCP server issues: check health, retrieve build metadata, and access embedded docs for troubleshooting.

Instructions

System diagnostics and authentication utilities for the Outlook MCP server. Start with system.about when troubleshooting; it returns build identity and host environment metadata without requiring authentication.

Set the required operation parameter to one of the verbs below. Each line names the verb, what it does, and the parameters that verb requires. Optional parameters are omitted here; call operation="help" for the full parameter reference.

  • help: show detailed documentation for all verbs or a single named verb. No required parameters.

  • about: return build identity and host environment metadata for troubleshooting. No required parameters.

  • status: return server health: version, accounts, uptime, config (no Graph call). No required parameters.

  • list_docs: list embedded documentation: slug, title, summary, tags, size, and doc:// URI. No required parameters.

  • search_docs: search embedded docs by keyword; returns ranked snippets with line numbers. Requires: query.

  • get_docs: fetch a document or section by slug; use search_docs first to identify the slug. Requires: slug.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
slugNoDocument slug (e.g., 'troubleshooting', 'readme', 'quickstart'). Use list_docs to enumerate slugs.
queryNoCase-insensitive keyword or phrase to search across the embedded documentation bundle.
outputNoOutput mode: 'text' (default), 'summary', or 'raw'.
sectionNoOptional H2 heading anchor to extract a single section (e.g., 'token-refresh'). Anchors are lower-cased heading text with spaces replaced by hyphens, unless the heading carries an explicit '{#custom-id}' tag, in which case that id is the anchor (e.g., 'container-no-keychain').
operationYesThe operation to perform. Call with operation="help" for full documentation.
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds valuable behavioral context beyond the annotations: it notes that about works 'without requiring authentication', status performs 'no Graph call', and it clarifies dependencies like 'Requires: query' and 'Requires: slug'. These details disclose operational traits that are not present in the readOnlyHint or idempotentHint 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 efficiently structured: a brief overview sentence, a general instruction about the operation parameter, and a bullet-style list of verbs with their actions and required parameters. Every sentence serves a purpose, and the format is scannable and 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?

Given the tool has six sub-operations and no output schema, the description provides sufficient detail for selection and invocation. It describes the return value of each verb (e.g., about returns 'build identity and host environment metadata', status returns 'version, accounts, uptime, config', search_docs returns 'ranked snippets with line numbers') and notes that help gives the full parameter reference.

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 covers all parameters with detailed descriptions (100% coverage), so the baseline is 3. The description adds semantic value by linking specific parameters to their verbs (e.g., 'search_docs requires query', 'get_docs requires slug') and instructing users to consult help for optional parameters. This mapping is not fully explicit in 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 defines the tool as system diagnostics and authentication utilities, and enumerates six specific verbs with distinct actions (help, about, status, list_docs, search_docs, get_docs). Each verb has a one-line explanation, so the purpose is specific and unambiguous, and it is naturally distinguished from sibling tools like account, calendar, and 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 description gives explicit guidance, such as 'Start with system.about when troubleshooting' and 'use search_docs first to identify the slug' for get_docs. It also tells users to call operation='help' for the full parameter reference. It does not explicitly contrast with sibling tools, but the system-level scope is implied, making the usage context clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

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

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