Related Pages

Related topics: Authentication, Authorization, and Security Controls, Tool Catalog, Presets, Playbooks, and Agent Skills, Deployment, Infrastructure, and Day-2 Operations

Project Overview and Internal Architecture

ms-365-admin-mcp-server is a Model Context Protocol (MCP) server that exposes hundreds of Microsoft Graph administrative endpoints to LLM clients as callable tools. It targets tenants who need their AI agents to perform tenant-scoped administration — security triage, identity management, Intune operations, Conditional Access tuning, eDiscovery, and incident response — without giving the agent a raw, unconstrained Graph token. The project is published under MIT by okapi-ca and currently ships roughly a dozen tagged releases (v0.6.x through v0.14.0 at the time of writing). Source: package.json.

The server's design philosophy is "many tools, narrow blast radius." Every write endpoint carries an explicit riskLevel annotation, the registration pipeline caps exposure to a configurable maximum, and the transport layer supports both stdio (local agents) and HTTP with OAuth2 (shared/remote agents). Optional LLM-agent skills under agent-skills/ wrap the tool surface with a dry-run → confirm → audit safety pattern. Source: agent-skills/README.md.

High-Level Architecture

The runtime is a Node.js/TypeScript application. A commander-driven CLI in src/cli.ts parses flags, instantiates the MCP Server, loads the generated endpoint catalog, and selects a transport. The tool surface is generated at build time from Microsoft Graph metadata and emitted as endpoints.json plus a typed wrapper under src/generated/. Source: src/cli.ts, src/generated/endpoint-types.ts.

flowchart LR
  A[LLM Client<br/>stdio or HTTPS] --> B[Transport Layer<br/>src/index.ts]
  B --> C[MCP Server<br/>src/server.ts]
  C --> D[Tool Registration<br/>src/graph-tools.ts]
  D --> E[Generated Catalog<br/>src/generated/* + endpoints.json]
  D --> F[Risk Gating<br/>src/risk-level.ts]
  D --> G[Category Filter<br/>src/tool-categories.ts]
  C --> H[Auth Layer]
  H --> H1[OAuth Proxy<br/>src/oauth-proxy.ts]
  H --> H2[Service Token<br/>src/token-validator.ts]
  H --> H3[User Token<br/>src/user-token-validator.ts]
  C --> I[Graph Client<br/>app-only or OBO]
  I --> J[(Microsoft Graph)]
  K[ms-365-admin-mcp-auth<br/>src/auth-bootstrap.ts] --> A

Two token modes are supported. In OBO (On-Behalf-Of) mode, a human user authenticates with the MCP server and the server exchanges their token for a Graph token, honoring the user's own permissions. In app-only mode, certain endpoints — those requiring permissions with no delegated equivalent, such as BitlockerKey.Read.All or Exchange.ManageAsApp — are forced onto a pre-provisioned client-credentials token. Source: src/graph-tools.ts.

Tool Registration and Risk Model

Every entry in the generated catalog is treated as a potential tool. Registration iterates the catalog and applies four independent gates in order: read-only filter, category/preset filter (security, audit, health, reports, all), --max-risk-level cap, and — in HTTP mode — per-caller Entra App Role membership. Source: src/graph-tools.ts, src/cli.ts.

The risk model is a four-level ranked scale: low < medium < high < critical. The pure module src/risk-level.ts defines the ordering and an "effective level" computation that fails safe — a write endpoint missing an explicit annotation is treated as critical, never silently downgraded. The CLI exposes --max-risk-level so operators can deploy the same binary in progressively more permissive configurations. Source: src/risk-level.ts.

When the HTTP transport is active, write-tier exposure is further filtered by three additive Entra App Roles: Tools.Write.LowMedium (grants low+medium), Tools.Write.High, and Tools.Write.Critical. This addresses community request #104 ("per-caller write gating via Entra App Roles"), allowing a single deployment to serve both read-only analysts and senior responders with different blast radii. Source: src/risk-level.ts, v0.6.3 release notes.

Authentication, Authorization, and Cloud Support

The server supports two HTTP authentication paths. Service-to-service clients (other agents, CI runners) present an Entra-issued client-credentials JWT; src/token-validator.ts validates the signature against the tenant's JWKS, checks aud/iss/exp, and matches the appid claim against the --allowed-clients allow-list. Human-user MCP clients (Claude Desktop/Code/Web) go through an embedded OAuth2 proxy in src/oauth-proxy.ts that implements Dynamic Client Registration (/register), authorization code + PKCE (/authorize, /token), and the RFC 8628 device-code grant (/devicecode) for headless environments. Source: src/oauth-proxy.ts, src/token-validator.ts.

User-issued access tokens are validated by src/user-token-validator.ts, which delegates the claims check to authorizeUserClaimsExplain in src/user-token-authorization.ts. The validator distinguishes invalid_token (RFC 6750 §3.1 rejection) from insufficient_scope and surfaces the assigned roles array used by the risk-tier filter above. To keep logs safe, UPN-like claims are hashed with a 16-char SHA-256 prefix when --redact-logs is enabled. Source: src/user-token-validator.ts, src/user-token-authorization.ts.

A separate ms-365-admin-mcp-auth CLI binary pre-seeds an mcp-remote token cache via the device-code flow so desktop clients skip the browser round-trip on first connect. Both binaries target the global and China (21Vianet) clouds, selected with --cloud global|china, with endpoints resolved by src/cloud-config.ts. Source: src/auth-bootstrap.ts, src/cloud-config.ts.

Common Failure Modes

Several known sharp edges are worth highlighting for operators. The OAuth-proxy app registration being both the OAuth client and the protected resource (api://{clientId}/access_as_user) causes Entra to reject refresh_token grants for the self-reference — tracked in issue #126 and mitigated by splitting the client and resource app registrations. The APP_ONLY_PERMISSIONS set in src/graph-tools.ts must be kept in sync with the deployed app registration's application-role consent; missing roles cause silent tool skips. Finally, the risk-level gate fails *closed* on missing annotations: a newly added write endpoint without a riskLevel field will be treated as critical and will not appear in any deployment that does not explicitly opt in to critical. Source: src/graph-tools.ts.

See Also

• Risk Model and Tool Classification
• OAuth Proxy and Authentication Setup
• Agent Skills for LLM Clients
• CHANGELOG

Related Pages

Related topics: Project Overview and Internal Architecture, Deployment, Infrastructure, and Day-2 Operations

Authentication, Authorization, and Security Controls

Overview

ms-365-admin-mcp-server exposes 515+ Microsoft 365 admin tools through the Model Context Protocol. Because the surface includes destructive operations (disable user, revoke session, wipe device, confirm compromised), the server layers defense-in-depth controls referenced throughout the codebase by SEC-F/SEC-G identifiers:

1. Risk-level gating at tool registration time using a four-tier ranked model (src/risk-level.ts).
2. Per-caller Entra App Role checks that map user role assignments to write-tier risk levels (added in v0.6.3, PR #104).
3. OAuth 2.0 proxy supporting authorization_code+PKCE, refresh_token, and device_code with confidential-client authentication only (src/oauth-proxy.ts).
4. RFC 6750 Bearer-token validation with correct invalid_token (401) vs insufficient_scope (403) status mapping (src/http-server.ts).
5. Optional device-code bootstrap CLI that pre-seeds the mcp-remote token cache for headless clients (src/auth-bootstrap.ts).

sequenceDiagram
    participant C as MCP Client
    participant P as OAuth Proxy
    participant E as Entra ID
    participant M as MCP Server (/mcp)
    participant G as Microsoft Graph
    C->>P: POST /register (DCR)
    P-->>C: client_id + client_secret
    C->>P: GET /authorize?code_challenge=S256
    P->>E: browser redirect
    E-->>P: authorization code
    C->>P: POST /token (code + secret)
    P->>E: upstream exchange
    E-->>P: access_token (scp)
    P-->>C: access_token
    C->>M: GET /mcp Authorization: Bearer
    M->>M: validate JWT (aud, iss, scp, roles)
    M->>G: forward Graph request
    G-->>M: response
    M-->>C: tool result

Risk-Level Gating and App Role Authorization

Every tool is annotated with a riskLevel from the ranked enum low < medium < high < critical. The CLI flag --max-risk-level caps which tools the registration pipeline exposes; tools above the cap are silently skipped. A GET endpoint without an explicit annotation defaults to low; a write endpoint without an annotation defaults to critical (fail-safe so a future endpoint cannot leak under a medium cap) — see the comment block at src/risk-level.ts.

On top of the static cap, per-caller write gating via Entra App Roles maps the caller's role assignments to write tiers. Three additive App Roles (no implicit hierarchy) drive the filter:

• Tools.Write.LowMedium → grants low + medium
• Tools.Write.High → grants high
• Tools.Write.Critical → grants critical

If the caller identity is unavailable (e.g. stdio transport), the function returns undefined and the system falls back to the legacy --allow-writes / --max-risk-level controls without an extra per-caller filter. An authenticated caller with no Tools.Write.* assignment gets an empty role set, which effectively downgrades them to read-only.

Tool descriptions emitted by src/graph-tools.ts embed the effective risk level, plus readOnlyHint, destructiveHint, and openWorldHint MCP annotations so LLM clients can render UI affordances accordingly. Category filters (--enabled-tools, --preset) are evaluated against the patterns defined in src/tool-categories.ts (security, audit, identity, compliance, intune, governance, response, etc.).

OAuth Proxy and Token Validation

When --oauth-mode is enabled, src/oauth-proxy.ts exposes:

• GET /.well-known/oauth-authorization-server — discovery with an advertised device_authorization_endpoint for headless clients.
• GET /.well-known/oauth-protected-resource — RFC 8707 resource metadata.
• POST /register — Dynamic Client Registration returning a client_id and a hashed client_secret (SEC-F04b: confidential clients only).
• POST /devicecode — RFC 8628 device authorization, requiring client authentication identical to /token so a stolen device_code cannot burn the upstream rate budget.
• POST /token — supports authorization_code, refresh_token, and urn:ietf:params:oauth:grant-type:device_code grants.

The /mcp endpoint is guarded by createMcpAuthMiddleware in src/http-server.ts, which pins the RFC 6750 §3.1 mapping. invalid_token failures return 401 so clients refresh; insufficient_scope returns 403 so clients stop — getting this wrong causes infinite reconnect loops on token expiry (see the comment block in src/user-token-authorization.ts). The middleware also emits a WWW-Authenticate: Bearer resource_metadata="..." challenge header so clients can discover the authorization server.

JWT validation in src/user-token-validator.ts uses jwks-rsa with a 24h in-library cache and a SEC-F08 stale-key fallback for longer outages. UPN values are redacted in logs via formatUpnForLog (a 16-char sha256: prefix) when redaction is enabled, so PII does not leak into log forwarders.

Community note: Issue #126 highlights that when the OAuth-proxy app registration is *both* the OAuth client and the protected resource (api://{clientId}/access_as_user), Entra rejects refresh_token grants. The recommended remediation is to split the registration into a dedicated client app and a separate resource app so SEC-F03 scp enforcement works correctly.

Device Code Bootstrap and CLI Surface

The standalone ms-365-admin-mcp-auth binary (src/auth-bootstrap.ts) implements RFC 8628 device flow for headless environments. It prints the user_code and verification_uri, polls /token honoring slow_down (interval += 5s) plus expired_token / access_denied errors, then writes clientInfo.json and tokens.json into $MCP_REMOTE_CONFIG_DIR/mcp-remote-<ver> with 0700 / 0600 modes. The cache is consumed by mcp-remote so Claude Desktop/Code skip the browser ceremony on subsequent runs.

Operator-facing CLI controls in src/cli.ts include:

• --max-risk-level <low|medium|high|critical> — caps the registration pipeline.
• --allow-writes — opt-in for any write tool.
• --enabled-tools <regex> and --preset <security,audit,health,reports,all> — category filters.
• --allowed-clients <ids> — restricts service-to-service tokens to a known set of Entra app IDs in HTTP mode.
• --cloud <global|china> — selects the 21Vianet endpoint variant.
• --transport <stdio|http> — switches between local IPC and the OAuth-protected HTTP listener.

Upstream errors are normalized by summarizeUpstreamError in src/upstream-error.ts (SEC-F07): only the OAuth-standard error, error_description, and error_codes fields are emitted, with descriptions clipped to 200 characters, preventing correlation IDs or trace fragments from being written to operator logs.

On the LLM side, the agent-skills/ms365-admin-mcp skill (added in v0.6.3) wraps the server's tools in a structured dry-run → confirm → audit safety pattern, routing requests by use case so the model focuses on the right subset of the 515 tools.

See Also

• Architecture Overview — server, transport, and registration pipeline.
• Configuration Reference — full CLI flag matrix and environment variables.
• OAuth Deployment Guide — App Role setup, audience split, and Azure Container Apps deployment.
• Risk Model — detailed rubric for classifying write tools.
• Agent Skills — LLM-side dry-run/confirm/audit wrappers.

Related Pages

Related topics: Project Overview and Internal Architecture, Authentication, Authorization, and Security Controls

Tool Catalog, Presets, Playbooks, and Agent Skills

The ms-365-admin-mcp-server exposes a generated catalog of ~515 Microsoft Graph tools to Model Context Protocol (MCP) clients. The catalog is curated by three layered systems: a generated endpoint registry, a regex/category preset filter, and a risk-level + Entra App Role authorization gate. On top of this, an "agent skills" layer packages the catalog for LLM-driven operating procedures. Together they let operators start narrow (a single preset, a low risk cap) and expand deliberately as trust in the calling agent grows.

The Endpoint Registry (Tool Catalog)

Each tool in the catalog is generated from Microsoft Graph metadata. The canonical data structures live in src/generated/endpoint-types.ts and consist of:

Source: src/generated/endpoint-types.ts:3-29

A thin wrapper normalizes these records at registration time: it strips $/_ from parameter names and injects any missing path parameters detected in :placeholder segments so the MCP-facing alias always has a matching input. Source: src/generated/hack.ts:7-39

The full registry is loaded at startup from src/endpoints.json (referenced in src/graph-tools.ts:84-86 and src/index.ts:21-26), and each record may carry an explicit riskLevel annotation and the Graph application permissions it requires.

Categories, Presets, and CLI Filters

The catalog is grouped into named categories defined in src/tool-categories.ts. Each entry pairs a regex against tool aliases with a human description. Categories include security, audit, health, reports, identity, compliance, exchange, intune, governance, response, ediscovery, cloudpc, callrecords, print, infoprotection, sharepointadmin, retention, and files. Source: src/tool-categories.ts:12-181

Presets are named bundles of those regex patterns. The CLI exposes them via --preset <names> (comma-separated) and lists them with --list-presets. Built-ins include security, audit, health, reports, and all. Internally, presets are combined with getCombinedPresetPattern, which OR-merges the underlying category patterns into a single regex. Source: src/cli.ts:26-27 and src/tool-categories.ts

For ad-hoc scoping, --enabled-tools <pattern> accepts any regex (e.g. security|audit) and is applied in addition to presets. Source: src/cli.ts:24-25

For full introspection, --list-tools dumps every tool that would register under the current flags as JSON (name, method, path, riskLevel, permissions). Source: src/index.ts:24-46

Risk Levels and the Registration Pipeline

Each tool carries an explicit riskLevel in low | medium | high | critical (SEC-G01). The model is rank-ordered and used by isToolAllowed(configuredRiskLevel, method, maxRiskLevel) to gate registration. Source: src/risk-level.ts:9-15 and src/risk-level.ts:55-58

The effective level falls back safely when an annotation is missing:

• A configured riskLevel is honored.
• An unannotated GET defaults to low.
• An unannotated write defaults to critical (fail-safe so a future endpoint cannot be silently leaked under a medium cap).

Source: src/risk-level.ts:38-44

On top of the risk cap, the registration pipeline in src/graph-tools.ts applies, in order:

1. Read-only / write toggle — writes require --allow-writes; reads are always allowed. Source: src/cli.ts:18-21
2. Risk-level cap — --max-risk-level <low|medium|high|critical> (implies --allow-writes). Default is "no cap" once writes are enabled. Source: src/cli.ts:22-23
3. Per-caller App Role filter (SEC-F08) — when caller identity is available, three additive Entra App Roles (Tools.Write.LowMedium, Tools.Write.High, Tools.Write.Critical) restrict which write tiers a caller can invoke; undefined (stdio transport) falls back to the legacy flags. Source: src/risk-level.ts:64-83
4. Regex filter — --enabled-tools or --preset pattern is matched against the tool alias. Source: src/graph-tools.ts

The final summary line logged at the end of registration reports registered, skipped (read-only/filter), skipped (risk-level cap: <level>), optional skipped (role tiers: ...) counts, and any failed registrations. Source: src/graph-tools.ts

Agent Skills: The LLM Operating Layer

agent-skills/ wraps the catalog with prompt-level scaffolding for LLM agents. Skills enforce a "dry-run → confirm → audit" safety pattern and route requests by use case so the model focuses on the right subset of tools instead of the full ~515-tool surface. Source: agent-skills/README.md:3-7

The shipped ms365-admin-mcp/ reference skill targets tenant-scoped administration: security triage, identity, Intune, Conditional Access, eDiscovery, hunting, and governance. It complements — not replaces — docs/USE_CASES.md, docs/playbooks/, and docs/RISK_MODEL.md by indexing those documents for lazy-loading by the agent runtime. Source: agent-skills/README.md:11-18

Installation is a directory copy into .claude/skills/ (or ~/.claude/skills/); the skill auto-loads when its description field matches the conversation. The SKILL.md frontmatter format is portable to most modern agent runtimes. Source: agent-skills/README.md:23-39

Contributing guidelines require keeping SKILL.md under ~200 lines, splitting domain content into references/<topic>.md files (lazy-loaded), anonymizing all examples (e.g. @contoso.com), and confirming every referenced tool exists in src/endpoints.json. Source: agent-skills/README.md:41-48

See Also

• Risk Model and Write Gating — companion rubric for write-tool classification.
• Use Cases — canonical list of 15 admin scenarios with sample prompts.
• Playbooks — end-to-end incident response procedures.
• Releases — version history including v0.6.3 (initial agent-skill release) and subsequent iterations.

Related Pages

Related topics: Project Overview and Internal Architecture, Authentication, Authorization, and Security Controls

Deployment, Infrastructure, and Day-2 Operations

The ms-365-admin-mcp-server exposes Microsoft 365 administrative operations (security, identity, Intune, governance, eDiscovery, Exchange, etc.) to LLM clients through the Model Context Protocol. This page documents the deployment-relevant configuration surface (CLI flags, transports, cloud selection, OAuth proxy), the runtime stack, and the day-2 controls (risk gating, tool filtering, agent skill packaging) that operators use to keep the server safe, focused, and tenant-appropriate.

Configuration Surface

The server is configured through CLI flags parsed by Commander. Source: src/cli.ts:1-50. The flags relevant to deployment include:

Operator helpers include --list-tools, --list-presets, --list-permissions, and --list-risk-levels, which print discovery data and exit without starting the server — useful for IaC validation and change-control reviews.

Transport Modes and Runtime

Two transports are supported:

• stdio (default) — process-attached, used by Claude Desktop, Cline, and similar clients. Tokens are obtained via MSAL; per-caller identity is unavailable, so role-based write gating falls back to CLI flags only. Source: src/cli.ts:10-30.
• http — an Express 5 server binding to --host:--port. This mode can validate inbound bearer tokens (OBO or service-to-service), enforce --allowed-clients, and optionally front the connection with the OAuth proxy.

The runtime stack depends on express@^5.2.1, express-rate-limit@^8.3.2, jsonwebtoken@^9.0.3, jwks-rsa@^4.0.1, @azure/msal-node@^5.1.4, winston@^3.17.0, and zod@^4.3.6. Optional dependencies (@azure/data-tables, @azure/keyvault-secrets, @azure/identity) load only when their feature is configured, so absence does not break install. Node.js ≥ 20.18.0 is enforced via engines. Source: package.json:30-100.

Build is tsup; tests run via vitest; the full verify pipeline is generate → lint → format → build → test. Source: package.json:10-25.

Cloud Configuration

src/cloud-config.ts resolves a CloudType ('global' or 'china') to a triple of endpoints (authority, Graph base URL, portal). The default is 'global'. Operators in sovereign clouds can run with --cloud china, which switches the authority to login.chinacloudapi.cn and the Graph base to microsoftgraph.chinacloudapi.cn. Invalid values fail fast through parseCloudType, which is preferable to silently routing to the wrong tenant. Source: src/cloud-config.ts:1-100.

OAuth Proxy for Human Users

When --oauth-mode is set, the server exposes a small OAuth 2.0 authorization server in front of the MCP endpoint. Source: src/oauth-proxy.ts:1-50:

• /.well-known/oauth-authorization-server advertises authorization_code, refresh_token, and device_code grants with PKCE (S256).
• /.well-known/oauth-protected-resource advertises the MCP resource and bearer-method support.
• /register performs Dynamic Client Registration, returning a client_id and secret hash for confidential clients.
• /authorize, /token, and /devicecode complete the flow.

The proxy accepts only confidential clients (client_secret_post / client_secret_basic) and emits only the RFC 6749 §5.2 standard error fields (error, error_description, error_codes) via summarizeUpstreamError, keeping correlation IDs and trace fragments out of logs. Source: src/upstream-error.ts:1-30.

Operators should note issue #126: the OAuth-proxy app registration currently acts as both the OAuth client and the protected resource (api://{clientId}/access_as_user), which causes Entra to reject refresh-token grants (AADSTS error). Production deployments should split into two app registrations to re-enable scp enforcement. The v0.6.3 release also added per-caller write gating via Entra App Roles (release notes), and later releases up to v0.14.0 continued to harden the auth and dependency surface.

Day-2 Controls: Risk Gating and Filtering

src/risk-level.ts defines a four-tier risk model (low / medium / high / critical). Tools without an explicit annotation default to low for GETs and critical for writes — a fail-safe so future endpoints cannot silently leak under a medium cap. The --max-risk-level CLI flag caps the level the registration pipeline exposes. Source: src/risk-level.ts:1-60.

In HTTP mode, per-caller write gating maps Entra App Role assignments to risk tiers. Source: src/risk-level.ts:60-100:

• Tools.Write.LowMedium → grants low + medium
• Tools.Write.High → grants high
• Tools.Write.Critical → grants critical

If the caller identity is unavailable (stdio transport), the role filter is skipped and only CLI flags apply. Tool visibility can also be narrowed with --enabled-tools <regex> or --preset security,audit,health,reports,all, where categories are defined in src/tool-categories.ts (security, audit, health, reports, identity, compliance, exchange, intune, governance, response, ediscovery, cloudpc, callrecords, print, …). Source: src/tool-categories.ts:1-80.

Agent Skills Deployment

The agent-skills/ directory ships drop-in skills for LLM clients (notably Claude Code). Installation is a file copy into .claude/skills/ (project or ~/.claude/skills/); the skill auto-loads when the conversation matches its frontmatter description. The skill wraps the server's tools with a dry-run → confirm → audit safety pattern and indexes the canonical docs (docs/USE_CASES.md, docs/RISK_MODEL.md, docs/playbooks/) without duplicating them. Source: agent-skills/README.md:1-60.

See Also

• Risk classification rubric: see docs/RISK_MODEL.md
• Use-case catalog: see docs/USE_CASES.md
• Per-platform setup: see docs/SETUP_MACOS_EN.md, docs/SETUP_WINDOWS_EN.md
• Troubleshooting: see docs/TROUBLESHOOTING.md
• Issue #126 — split OAuth client from resource app to re-enable scp enforcement: <https://github.com/okapi-ca/ms-365-admin-mcp-server/issues/126>

Doramagic Pitfall Log

Found 8 structured pitfall item(s), including 0 high/blocking item(s). Top priority: Configuration risk - Configuration risk requires verification.

1. Configuration risk: Configuration risk requires verification

• Severity: medium
• Finding: Project evidence flags a configuration risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: capability.host_targets | https://github.com/okapi-ca/ms-365-admin-mcp-server

2. Capability evidence risk: Capability evidence risk requires verification

• Severity: medium
• Finding: README/documentation is current enough for a first validation pass.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: capability.assumptions | https://github.com/okapi-ca/ms-365-admin-mcp-server

3. Maintenance risk: Maintenance risk requires verification

• Severity: medium
• Finding: Project evidence flags a maintenance risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: evidence.maintainer_signals | https://github.com/okapi-ca/ms-365-admin-mcp-server

4. Security or permission risk: Security or permission risk requires verification

• Severity: medium
• Finding: no_demo
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: downstream_validation.risk_items | https://github.com/okapi-ca/ms-365-admin-mcp-server

5. Security or permission risk: Security or permission risk requires verification

• Severity: medium
• Finding: no_demo
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: risks.scoring_risks | https://github.com/okapi-ca/ms-365-admin-mcp-server

6. Security or permission risk: Security or permission risk requires verification

• Severity: medium
• Finding: Project evidence flags a security or permission risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/okapi-ca/ms-365-admin-mcp-server/issues/126

7. Maintenance risk: Maintenance risk requires verification

• Severity: low
• Finding: issue_or_pr_quality=unknown。
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: evidence.maintainer_signals | https://github.com/okapi-ca/ms-365-admin-mcp-server

8. Maintenance risk: Maintenance risk requires verification

• Severity: low
• Finding: release_recency=unknown。
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: evidence.maintainer_signals | https://github.com/okapi-ca/ms-365-admin-mcp-server

Community Discussion Evidence

Doramagic exposes project-level community discussion separately from official documentation. Review these links before using ms-365-admin-mcp-server with real data or production workflows.

• Separate OAuth client app from resource app to re-enable SEC-F03 scp enf - github / github_issue
• v0.14.0 - github / github_release
• v0.13.0 - github / github_release
• v0.11.0 - github / github_release
• v0.10.0 - github / github_release
• v0.9.0 - github / github_release
• v0.8.0 - github / github_release
• v0.7.0 - github / github_release
• v0.6.3 - github / github_release
• v0.6.2 - github / github_release
• v0.6.1 - github / github_release
• Configuration risk requires verification - GitHub / issue