Skip to main content
Glama
desek

outlook-local-mcp

system

Read-onlyIdempotent

Perform system diagnostics: check server health, view build identity, or search embedded documentation. Start with 'about' for troubleshooting metadata.

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.
operationYesThe operation to perform. Call with operation="help" for full documentation.
Behavior4/5

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

Annotations already indicate readOnly, idempotent, non-destructive. The description adds context like 'status returns server health... no Graph call' and the structure of operations, enhancing transparency 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?

The description is concise and well-structured: front-loaded with purpose, then parameter explanation, then bulleted list of operations. Every sentence adds necessary information with no 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?

Covers operations, required parameters, and usage hints. Lacks explicit return value descriptions for each operation, but given no output schema, the descriptions (e.g., 'return build identity') are implicit. Adequate for the complexity.

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 value by mapping operations to required parameters and suggesting usage order (e.g., use list_docs to enumerate slugs), which is not evident from the schema alone.

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 'System diagnostics and authentication utilities' and lists specific operations (about, status, help, etc.). It distinguishes itself from sibling tools (account, mail, calendar) by focusing on server-level introspection.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly recommends starting with system.about when troubleshooting and provides sequencing guidance (use search_docs before get_docs). However, it does not explicitly contrast with sibling tools or mention when not to use this tool.

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