What can you do with this server?

This server exposes a governed, delegated-access MCP interface for Microsoft 365/SharePoint content, plus informational tools. * search — search M365/SharePoint/OneDrive files and list items as the signed-in user; results are security-trimmed to what you can access (requires query, optional size 1–25). * about — show the server’s purpose, version, status, and how it runs. * governance_model — explain the governance-first design: delegated auth, least privilege, auditability, sensitivity awareness, and local-only operation. * Note: the README also lists get_list_items, but that tool is not present in the provided server schema.

How do I use m365-governed-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@m365-governed-mcp search my SharePoint files for the Q3 budget report" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

m365-governed-mcp

by gvijaikumar9

Overview Schema Related Servers Score Discussions

JavaScript

Local

m365-governed-mcp

A governance-first Model Context Protocol (MCP) server for Microsoft 365 and SharePoint.

It lets an AI assistant reach enterprise content through a governed adapter instead of a brittle, over-permissioned integration. The core principle: the AI only ever sees what the signed-in person is allowed to see.

Status: v0.4.0. Delegated search and get_list_items tools that read your Microsoft 365 content as the signed-in user, so results are security-trimmed by construction. Sign-in opens your browser automatically (device-code fallback). about and governance_model describe the server.

Why a governed MCP server?

Most "M365 MCP" servers use app-only permissions, so the AI can read anything in the tenant and quietly overshare. This server is built the other way around:

Delegated authentication — it calls Microsoft Graph as the user, so results are security-trimmed by construction.
Least privilege — read-oriented scopes by default; writes are explicit and confirmable.
Auditable — every tool call is logged (who, what, when).
Oversharing- and sensitivity-aware — flags broadly shared or labeled items instead of hiding the risk.
Local by default — runs on the user's machine over stdio; no hosted service, so credentials and data never leave the device.

Related MCP server: Glean Remote MCP Server

Prerequisites

On your machine

Node.js 18+ (provides npx, which runs the server on demand — no clone or build needed).
An MCP client that supports local (stdio) servers — e.g. Claude Code or an IDE MCP client. Note: the current Claude Desktop (Fable) build only accepts remote URL connectors, so it can't host this local server yet; use Claude Code for now.

In your Microsoft 365 tenant — one Azure AD app registration

The tools sign you in and call Microsoft Graph as you, so you need a public-client app registration in your tenant (one-time, ~3 minutes). Do it with the setup script below, or by hand:

Entra admin center → App registrations → New registration. Name it e.g. m365-governed-mcp. Supported account types: Accounts in this organizational directory only. Register.
Copy the Application (client) ID and Directory (tenant) ID from the Overview page.
API permissions → Add a permission → Microsoft Graph → Delegated → add Sites.Read.All and Files.Read.All. Grant admin consent if your tenant requires it.
Authentication → Allow public client flows → Yes. (Enables the device-code fallback.)
Authentication → Add a platform → Mobile and desktop applications → redirect URI http://localhost. (Enables the interactive browser sign-in.) Save.

No client secret or certificate — it's a public client using delegated permissions.

Quick setup script

Instead of the manual steps, run scripts/New-M365GovernedMcpApp.ps1 (needs the Microsoft.Graph PowerShell module; sign in as an admin). It creates the app registration with all the settings above, grants admin consent, and prints your TENANT_ID and CLIENT_ID plus a ready-to-paste config block:

Install-Module Microsoft.Graph -Scope CurrentUser   # if not already installed
./scripts/New-M365GovernedMcpApp.ps1

Install

No install needed — your MCP client runs it on demand with npx. Provide your TENANT_ID and CLIENT_ID in the env block.

Claude Code (recommended)

claude mcp add m365-governed -e TENANT_ID=<your-tenant-id> -e CLIENT_ID=<your-app-client-id> -- npx -y @gvijaikumar9/m365-governed-mcp

Or add it to a project .mcp.json:

{
  "mcpServers": {
    "m365-governed": {
      "command": "npx",
      "args": ["-y", "@gvijaikumar9/m365-governed-mcp"],
      "env": { "TENANT_ID": "<your-tenant-id>", "CLIENT_ID": "<your-app-client-id>" }
    }
  }
}

Claude Desktop

Local (stdio) servers work in Claude Desktop builds that read claude_desktop_config.json. The newest Fable build accepts only remote URL connectors — if you're on that build, use Claude Code instead.

Add to claude_desktop_config.json (Windows: %APPDATA%\Claude\, macOS: ~/Library/Application Support/Claude/):

{
  "mcpServers": {
    "m365-governed": {
      "command": "npx",
      "args": ["-y", "@gvijaikumar9/m365-governed-mcp"],
      "env": {
        "TENANT_ID": "<your-tenant-id>",
        "CLIENT_ID": "<your-app-client-id>"
      }
    }
  }
}

Restart Claude Desktop, then ask it to search your content. On first use it opens your browser to sign in — after that you're signed in for the session. (If a browser can't be opened, it falls back to a device-code link.)

Tools (v0.4.0)

Tool	Description
`search`	Search your M365 files and list items as the signed-in user (security-trimmed). Args: `query` (required), `size` (1-25, default 10).
`get_list_items`	Read items from a named SharePoint list as the signed-in user (security-trimmed). Args: `site` (site URL, required), `list` (display name, required), `top` (1-100, default 20).
`about`	Purpose, version, status, and how the server runs.
`governance_model`	The delegated-auth, least-privilege, audited, sensitivity-aware design.

Roadmap

v0.3 ✅ — interactive browser sign-in (smoother than device code), with device-code fallback.
v0.4 ✅ — get_list_items (read a named SharePoint list) + a one-command app-registration setup script.
Next — persistent token cache; oversharing and sensitivity-label flags on results; a local audit log; more tools (list_sites, get_file, list_files).

License

MIT © Vijay Kumar Gilakattula

Available Tools

3 tools

aboutA

Describe this MCP server: its purpose, version, status, and how it runs.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations, the description bears the full burden. It discloses the kind of information returned (purpose, version, status, how it runs) and implies a read-only, non-destructive operation. While it doesn't detail response formatting, that is not critical for an about 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?

One concise, front-loaded sentence that contains no filler. It efficiently enumerates the aspects of the server that will be described without redundant wording.

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 parameterless introspection tool, the description fully covers what the tool does and what it reports. No output schema exists, but the listed items (purpose, version, status, how it runs) suffice for an agent to understand the expected return. There is no missing context needed to 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, so schema coverage is trivially 100%. The description does not need to explain parameters, and none are present. Baseline of 4 applies for parameter-free tools.

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 ('Describe') and resource ('this MCP server'), and elaborates on the content (purpose, version, status, how it runs). This clearly distinguishes it from sibling tools like 'search' and 'governance_model'.

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 the usage context explicit: it is for describing the server's metadata. It does not explicitly contrast with sibling tools, but the distinct purpose of an 'about' tool makes exclusions unnecessary. Since there are siblings, a more explicit 'use this when...' would have earned a 5, but a 4 is appropriate.

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

governance_modelA

Explain the server's governance-first design: delegated auth, least privilege, auditing, oversharing and sensitivity awareness, and local-only operation.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.7/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full disclosure burden. It does convey that the tool is non-mutating and informational via the verb 'Explain' and tightly constrains the content to five governance aspects. It does not, however, disclose output form, depth, or whether the explanation is static or generated, leaving some behavioral ambiguity for a no-annotation 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?

A single sentence that front-loads the action and resource, then uses a colon to introduce a tight list of the five covered topics. There is no fluff, and every word contributes to scoping the tool's behavior.

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?

For a zero-parameter informational tool with no output schema, the description is nearly complete: it specifies exactly which aspects the explanation should cover, which is enough for an agent to invoke it correctly. The only minor gap is that the response format is not described, but 'Explain' strongly implies prose, so this is a small omission.

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 input schema is empty with additionalProperties set to false, so there are zero parameters to document. Per the baseline for zero-parameter tools, this dimension is satisfied; the description has no parameter burden to carry.

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 uses a specific verb ('Explain') and a precise resource ('the server's governance-first design'), then enumerates five concrete subtopics: delegated auth, least privilege, auditing, oversharing/sensitivity awareness, and local-only operation. This makes the purpose unmistakable even against siblings 'search' and 'about', though it stops short of explicitly contrasting itself with those siblings.

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?

There is no explicit when-to-use versus when-not-to-use guidance or named alternatives. However, the enumerated governance topics make the intended invocation context inferable: an agent can reasonably choose this tool when a user asks about the server's auth, privilege, audit, or privacy design. This is implied usage rather than stated guidance.

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

searchA

Search your Microsoft 365 content (SharePoint/OneDrive files and list items) as the signed-in user. Results are security-trimmed: only items you are authorized to see are returned. Signs you in via device code on first use.

ParametersJSON Schema

Name	Required	Description	Default
`size`	No	Maximum number of results to return (1-25, default 10).
`query`	Yes	The search terms, e.g. 'Q3 governance policy'.

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden. It usefully discloses that results are security-trimmed to the signed-in user and that authentication via device code occurs on first use. It does not mention rate limits or result format, but for a search tool the disclosed behavior is substantial.

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 precise sentences with no filler. The core action and resource scope are front-loaded, followed by security and authentication notes. Every sentence 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?

For a two-parameter search tool with no nested objects and no output schema, the description provides enough context to invoke it correctly: content scope, authorization behavior, and authentication side effect. It does not specify the exact result shape, but that is not required here.

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 100%: both 'query' and 'size' have clear type and description in the schema. The description adds broader context about scope and security but does not add meaning to individual parameters beyond what the schema already provides, so the baseline of 3 applies.

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 names a specific verb ('Search'), a concrete resource ('Microsoft 365 content'), and narrows that to 'SharePoint/OneDrive files and list items.' This clearly distinguishes the operation from the sibling tools 'about' and 'governance_model.'

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 clearly communicates the intended context: searching Microsoft 365 content as the signed-in user. It does not explicitly state when to avoid this tool or name alternatives, but the focus on security-trimmed M365 search makes the usage context obvious.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Disambiguation5/5

The three tools serve clearly separate purposes: search performs content lookup, about provides server metadata, and governance_model explains design philosophy. No overlap exists between them.

Naming Consistency2/5

Naming is inconsistent: 'search' is a terse verb, 'about' is a generic noun, and 'governance_model' is a compound noun with an underscore. No clear pattern or verb_noun convention emerges.

Tool Count4/5

With only three tools, the set is lean but not unreasonably thin for a search-centric server. The 'about' and 'governance_model' tools are meta but serve onboarding and trust purposes, making the count feel purposeful albeit limited.

Completeness2/5

The domain appears to be Microsoft 365 content search, but the surface is severely limited—no ability to retrieve actual file items, list data, or perform any CRUD. Even basic 'get item' or 'list sites' operations are absent, forcing agents to rely solely on vague search results.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

microsoft-365
com.proscendia
Permissioned access to Outlook, OneDrive and Teams via the user's own Microsoft account
Email Cloud Storage Communication
1
Orcha
io.github.westonhancock
Securely search and manage workspace context files for AI agents and teams.
Search File Systems Knowledge & Memory
1
Docusign Navigator COAuth
co.thisdot.docusign-navigator
Secure Docusign Navigator integration for AI assistants to access and analyze agreement data.
Legal & Compliance Documentation Access App Automation
21
cdgcsearchmetadata
io.github.poojaBjAcharya
Provides metadata information to AI agents through the search API.
Search RAG Systems
2

Related MCP Servers

Microsoft Graph MCP Server
Workplace & Productivity Communication Cloud Storage
sapientsai
A
license
Not graded
quality
F
maintenance
Enables AI assistants to interact with Microsoft 365 services (users, mail, calendar, files) via Microsoft Graph API.
Updated 2 months ago (2026-07-01 15:30 UTC)
46
1
MIT
Glean Remote MCP Serverofficial
Search RAG Systems
gleanwork
A
license
Not graded
quality
C
maintenance
Enables AI assistants and developer tools to securely access and interact with an organization's enterprise knowledge, documents, and people through natural language while respecting existing access permissions.
Updated 5 months ago (2026-04-17 16:55 UTC)
164
MIT
Microsoft Graph MCP
Communication Workplace & Productivity
evrimalacan
A
license
Not graded
quality
D
maintenance
Enables AI assistants to interact with Microsoft 365 through the Microsoft Graph API, including searching Teams messages, managing chats, and sending messages.
Updated 8 months ago (2025-12-24 19:29 UTC)
77
MIT
office365-mcp
Email Communication Cloud Storage
LotzerDigital
A
license
Not graded
quality
C
maintenance
Enables multiple users to securely connect their own Microsoft 365 account and use natural language to manage Outlook mail, Teams, and SharePoint/OneDrive files through Microsoft Graph, with support for shared mailboxes and admin governance.
Updated 12 days ago (2026-08-23 02:45 UTC)
MIT

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/gvijaikumar9/m365-governed-mcp'

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

m365-governed-mcp

Why a governed MCP server?

Prerequisites

Quick setup script

Install

Claude Code (recommended)

Claude Desktop

Tools (v0.4.0)

Roadmap

License

Available Tools

TDQS

TDQS

TDQS

TDQS

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Microsoft Graph MCP Server

Glean Remote MCP Serverofficial

Microsoft Graph MCP

office365-mcp

Latest Blog Posts

MCP directory API