How do I use o365-Admin 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., "@o365-Admin MCP Create a new SharePoint document library called 'Project Files' in the IT site" 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.

o365-Admin MCP

by MagicTurtle-s

Overview Schema Related Servers Score Discussions

TypeScript

Remote

o365-Admin MCP

A skill-based Microsoft 365 admin MCP server organized around APIs rather than applications. Capabilities are lazy-loaded from instruction files rather than exposed as a large tool manifest.

Architecture

This MCP exposes only 4 base tools:

Tool	Purpose
`list_skills`	Returns available skills and resource references
`read_skill`	Loads a skill or resource reference into context
`graph_api_call`	Generic Graph API executor
`powerplatform_api_call`	Generic Power Platform API executor

No domain-specific tools. Claude reads skills/resources to learn what API calls to construct, then executes via the generic tools.

Directory Structure

o365-Admin/
├── src/
│   └── index.ts           # MCP server with 4 base tools
├── skills/
│   ├── graph-api.md       # Core: auth, request patterns, pagination, errors
│   └── powerplatform-api.md  # Core: auth, environments, request patterns
├── resources/
│   ├── graph/
│   │   ├── sites.md       # SharePoint: sites, drives, lists, permissions
│   │   ├── teams.md       # Teams: teams, channels, tabs, apps
│   │   ├── users.md       # Entra: users, groups, directory roles
│   │   └── mail.md        # Exchange: messages, folders, rules, calendars
│   └── powerplatform/
│       ├── flows.md       # Flow definitions, runs, connections
│       └── environments.md # Environment management, DLP policies
├── README.md
├── package.json
└── tsconfig.json

Related MCP server: EntraID MCP Server

Prerequisites

Node.js 18+
Azure AD App Registration with appropriate permissions
Access to Microsoft 365 tenant

Azure AD App Registration

Step 1: Create App Registration

Go to Azure Portal > Azure Active Directory > App registrations
Click "New registration"
Name: o365-Admin-MCP
Supported account types: Single tenant (or multi-tenant if needed)
Click "Register"

Step 2: Create Client Secret

In your app registration, go to "Certificates & secrets"
Click "New client secret"
Add description and expiry
Copy the secret value immediately (shown only once)

Step 3: Add API Permissions

Go to "API permissions" > "Add a permission" > "Microsoft Graph" > "Application permissions"

Add the following permissions based on your needs:

SharePoint/OneDrive:

Sites.ReadWrite.All
Sites.Manage.All

Teams:

Team.Create
TeamSettings.ReadWrite.All
Channel.Create
ChannelSettings.ReadWrite.All
TeamsApp.ReadWrite.All

Users/Directory:

Directory.Read.All
Directory.ReadWrite.All
User.ReadWrite.All
Group.ReadWrite.All
RoleManagement.ReadWrite.Directory

Mail/Calendar:

Mail.ReadWrite
Mail.Send
Calendars.ReadWrite
MailboxSettings.ReadWrite

Click "Grant admin consent for [Your Tenant]" and confirm.

Step 5: Note Your IDs

From the app registration "Overview" page, copy:

Application (client) ID
Directory (tenant) ID

Environment Configuration

Set the following environment variables:

export AZURE_CLIENT_ID="your-client-id"
export AZURE_CLIENT_SECRET="your-client-secret"
export AZURE_TENANT_ID="your-tenant-id"

Or create a .env file (remember to add to .gitignore):

AZURE_CLIENT_ID=your-client-id
AZURE_CLIENT_SECRET=your-client-secret
AZURE_TENANT_ID=your-tenant-id

Installation

# Clone the repository
git clone https://github.com/yourusername/o365-Admin.git
cd o365-Admin

# Install dependencies
npm install

# Build TypeScript
npm run build

# Run the server
npm start

Development

# Run in development mode (no build step)
npm run dev

Usage with Claude

MCP Configuration

Add to your Claude MCP settings:

{
  "mcpServers": {
    "o365-admin": {
      "command": "node",
      "args": ["path/to/o365-Admin/dist/index.js"],
      "env": {
        "AZURE_CLIENT_ID": "your-client-id",
        "AZURE_CLIENT_SECRET": "your-client-secret",
        "AZURE_TENANT_ID": "your-tenant-id"
      }
    }
  }
}

Example Workflow

List available resources:
```
Use list_skills to see what's available
```

Load relevant documentation:

Use read_skill with type="resource" and name="graph/sites"

Execute API calls:

Use graph_api_call with method="GET" and endpoint="/sites/root"

Example Conversation

User: Create a new SharePoint document library called "Project Files" in the IT site

Claude: 
1. [Uses read_skill to load graph/sites resource]
2. [Uses graph_api_call GET /sites/contoso.sharepoint.com:/sites/IT to get site ID]
3. [Uses graph_api_call POST /sites/{site-id}/lists with library config]

Result: Document library "Project Files" created successfully.

Adding New Resources

To extend the MCP with new capabilities:

Create a new .md file in the appropriate directory:
- skills/ for core API patterns
- resources/graph/ for Graph API endpoints
- resources/powerplatform/ for Power Platform endpoints
Follow the existing format:
- Start with "# Title"
- Include "## Required Permissions" section
- Document each endpoint with method, URL, and example body
- Mark incomplete sections with TODO:
The new file will automatically appear in list_skills output

Resource Template

# Resource Name

Brief description of what this resource covers.

## Required Permissions

| Permission | Type | Description |
|------------|------|-------------|
| Permission.Name | Application | What it allows |

## Operation Name

Description of the operation.

\`\`\`
METHOD /endpoint/path
Content-Type: application/json

{
  "property": "value"
}
\`\`\`

Security Considerations

Never commit credentials to version control
Use environment variables or secure secret management
Apply principle of least privilege when assigning permissions
Regularly rotate client secrets
Monitor API usage for anomalies

License

MIT

Available Tools

4 tools

graph_api_callA

Execute a Microsoft Graph API call. Read the graph-api skill and relevant resource documentation first.

ParametersJSON Schema

Name	Required	Description
`body`	No	Request body for POST/PATCH/PUT requests
`method`	Yes	HTTP method
`endpoint`	Yes	API endpoint path after the base URL
`api_version`	No	API version (default: v1.0)

TDQS

A3.5/5.0

Behavior2/5

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

With no annotations, the description bears full responsibility for disclosing behavior, but it reveals nothing about authentication, permissions, side effects, rate limits, or response handling. It only says to read documentation, leaving the caller to infer that behavior varies by endpoint.

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 states the core function first and then gives a useful prerequisite. There is no redundant or filler content.

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 description covers the basic action and points the agent to external docs, while the schema covers all parameters. However, with no output schema and no behavior disclosure, the description leaves response format, authentication, and error behavior unspecified.

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%, so all parameters are already explained in the input schema. The description adds no parameter-level meaning beyond the instruction to consult resource documentation, which meets the baseline but not more.

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: 'Execute a Microsoft Graph API call.' The resource boundary (Microsoft Graph) clearly distinguishes it from sibling powerplatform_api_call, and the verb + resource combination is unambiguous.

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?

No explicit guidance is given about when to choose this tool over powerplatform_api_call or other siblings. 'Read the graph-api skill and relevant resource documentation first' is a prerequisite instruction, not a selection rule, though the Microsoft Graph scope implies the intended context.

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

list_skillsA

Returns available skills and resource references. Skills contain API patterns and best practices. Resources contain endpoint-specific documentation for different Microsoft 365 services.

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?

With no annotations, the description carries the full burden. It accurately conveys that the tool returns available skills and resource references, and it clarifies what those items contain. It does not mention side effects, ordering, caching, or whether the list is exhaustive, but for a simple zero-parameter list operation this is acceptable but not deeply transparent.

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 short sentences, front-loaded with the primary behavior, and each sentence adds useful information: what is returned and what those returned items mean. No filler 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?

For a parameterless list tool, the description gives enough context to understand the output domain: skills are API patterns/best practices and resources are endpoint-specific docs. The absence of an output schema is partially mitigated by this description, though it does not describe response format or pagination.

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 schema coverage is 100%, so there are no parameter semantics to document. The description earns its points by explaining what the returned data represents, which is the main semantic value an agent needs.

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 clear verb ('Returns') and names the resources ('skills and resource references'), with additional explanation of what skills and resources are. It is distinguishable from read_skill by being a list operation, though it does not explicitly contrast itself with 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?

The phrase 'Returns available skills and resource references' implies a discovery/list use, which an agent can infer as a precursor to read_skill, graph_api_call, or powerplatform_api_call. However, the description does not explicitly state when to use this tool versus alternatives or give any exclusions.

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

powerplatform_api_callC

Execute a Power Platform API call. Read the powerplatform-api skill and relevant resource documentation first.

ParametersJSON Schema

Name	Required	Description
`body`	No	Request body for POST/PATCH/PUT requests
`method`	Yes	HTTP method
`endpoint`	Yes	Full API endpoint URL
`environment_id`	No	Target Power Platform environment ID

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations present, the description carries the full burden of behavioral disclosure, but it only says to execute a call and consult documentation first. It does not mention authentication requirements, side effects of mutating methods, error behavior, rate limits, or that the tool is a raw passthrough whose behavior depends entirely on the chosen endpoint.

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 short and front-loaded with the core action, and both sentences serve a purpose. It loses a point because 'relevant resource documentation' is somewhat vague and the overall definition is thin for a tool that delegates to a large API surface.

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?

For a generic API execution tool with no output schema and no annotations, the instruction to read the skill and resource documentation first is a useful mitigation, but the description still lacks direct context about return values, permission expectations, or the range of Power Platform APIs it can reach. It is adequate but leaves meaningful gaps for the agent to discover elsewhere.

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%, so the schema already documents method, endpoint, body, and environment_id. The description adds no parameter-level meaning, but it does not need to; the baseline of 3 is appropriate when the schema carries the parametric load.

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 identifies the action as executing a Power Platform API call, which distinguishes it from the sibling graph_api_call tool by platform. It also directs the agent to first read the powerplatform-api skill, reinforcing what the tool targets. It stops short of a 5 because it does not explicitly contrast itself with graph_api_call or describe its generic low-level passthrough nature.

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 only guidance offered is 'Read the powerplatform-api skill and relevant resource documentation first,' which is a prerequisite instruction rather than a usage-selection rule. It does not say when to use this tool instead of graph_api_call, list_skills, or read_skill, nor does it describe contexts where the tool is appropriate or inappropriate.

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

read_skillA

Loads a skill or resource reference into context. Use this to learn API patterns before making calls.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Skill name (e.g., graph-api) or resource path (e.g., graph/sites)
`type`	Yes	Whether to read a skill or resource reference

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations, the description must carry the behavioral burden. It communicates that the tool loads a reference into context, implying a read-only action, and that it is preparatory rather than an actual API call. However, it does not describe what the agent should expect afterward—e.g., whether documentation is returned, how it is formatted, or whether context is replaced or appended.

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 short sentences convey both function and usage guidance with no filler. The core action is front-loaded, and the use case is stated immediately, making the description easy to process.

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 low-complexity, two-parameter tool with full schema coverage, the description is largely complete. It explains what the tool does, its purpose, and its place in the workflow relative to API calls. It could be improved by explicitly addressing the sibling list_skills or clarifying the absence of side effects, but nothing critical is missing for correct invocation.

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 input schema already documents both parameters with full coverage, including an enum and examples. The description adds no additional parameter-level semantics beyond tying the concepts of 'skill' and 'resource' to the corresponding parameters. Baseline 3 is appropriate because the schema does the heavy lifting.

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 a specific verb ('Loads') and resource ('a skill or resource reference') and adds purpose ('to learn API patterns before making calls'). It does not explicitly differentiate itself from list_skills, but the purpose clause makes the distinction from the *api_call siblings reasonably clear.

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 second sentence gives explicit usage context: use this before making calls to learn API patterns. It does not mention when not to use it or explicitly name alternatives like list_skills, but the timing and purpose are clear enough for an agent to select it over the API-call siblings.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

4 tool updatesv1.0.0Aug 30, 2026
- First observedgraph_api_call
- First observedlist_skills
- First observedpowerplatform_api_call
- First observedread_skill

Install Server

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

TDQS

A3.7/5.0

Disambiguation5/5

Each tool occupies a distinct role: list_skills discovers available references, read_skill loads a chosen reference, and the two call tools are explicitly separated by target API family (Microsoft Graph vs Power Platform). No two tools plausibly do the same thing.

Naming Consistency3/5

The skill tools use a clear verb_noun pattern (list_skills, read_skill), but the execution tools are named as target_noun phrases (graph_api_call, powerplatform_api_call) rather than verb-first equivalents. The mixed convention is still readable, but not consistent across the set.

Tool Count5/5

Four tools is a well-scoped size for this server's intended workflow: discover documentation, load documentation, then execute against one of two API families. Every tool has a clear purpose and none feels redundant.

Completeness5/5

The server covers the full lifecycle implied by its design: list and read the available skills/resources, then make calls to both Microsoft Graph and Power Platform APIs. Since the API-call tools are generic, they can cover any admin operation once the relevant skill is loaded, leaving no obvious dead ends.

Maintenance

ActivityInactive

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 MCP Server for EnterpriseOAuth
io.github.microsoft
Official Microsoft MCP Server to query Microsoft Entra data using natural language
Search Security
252
UnifAPIOAuth
com.unifapi
Hosted MCP server for live public-data APIs and Skills for AI agents.
Open Data Search AI & Machine Learning
2
mcp-serverOAuth
com.niftypm
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project Management Communication File Systems
2
jumpcloud-genaiOAuth
com.jumpcloud
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
Cloud Platforms Security Developer Tools
2

Related MCP Servers

CLI for Microsoft 365 MCP
Code Execution Command Line
pnp
A
license
B
quality
A
maintenance
An MCP server that enables running CLI for Microsoft 365 commands through GitHub Copilot Agent, allowing users to interact with Microsoft 365 services using natural language.
Updated 6 days ago (2026-08-31 17:14 UTC)
4
1,123
128
MIT
EntraID MCP Server
Cloud Platforms Security
hieuttmmo
F
license
Not graded
quality
F
maintenance
A modular server for interacting with Microsoft Graph API that enables management of users, groups, applications, sign-in logs, MFA status, and other Azure AD resources through natural language commands.
Updated a year ago (2025-05-02 08:59 UTC)
41
-
Microsoft MCP
Communication Cloud Platforms App Automation
elyxlz
F
license
C
quality
F
maintenance
A powerful MCP server that enables AI assistants to interact with Microsoft Graph API for managing Outlook emails, Calendar events, OneDrive files, and Contacts through natural language commands.
Updated a year ago (2025-06-23 11:04 UTC)
35
56
-
m365-mcp-server
Workplace & Productivity Cloud Platforms Communication
SwamiRama
A
license
Not graded
quality
A
maintenance
A production-ready MCP server that provides secure, delegated access to Microsoft 365 services including Email, SharePoint, OneDrive, and Calendar. It enables AI models to search messages, browse files, manage calendar events, and parse document contents using OAuth 2.1 authentication.
Updated 2 months ago (2026-07-20 19:37 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/MagicTurtle-s/o365-Admin'

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

o365-Admin MCP

Architecture

Directory Structure

Prerequisites

Azure AD App Registration

Step 1: Create App Registration

Step 2: Create Client Secret

Step 3: Add API Permissions

Step 4: Grant Admin Consent

Step 5: Note Your IDs

Environment Configuration

Installation

Development

Usage with Claude

MCP Configuration

Example Workflow

Example Conversation

Adding New Resources

Resource Template

Security Considerations

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API