Provides read access to Microsoft Loop workspaces and pages, including listing workspaces and pages, reading page content as Markdown, searching across Loop files, and experimental workspace creation.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@msloop-mcp list my workspaces"
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.
MCP server for Microsoft Loop. No app registration required.
Give any MCP client (Claude, Cursor, Devin, ...) read access to your Microsoft Loop workspaces and pages. It works by reusing your existing Loop web session, the same way msteams-mcp and msoutlook-mcp reuse the Teams and Outlook web sessions: you sign in once in a browser, then tokens are cached and refreshed automatically.
Microsoft does not publish a public API for Loop. This server reuses the Loop web app's own first party client ID, so your access is exactly what your account already has, with no Azure app registration, no admin consent, and no client secrets. Nothing leaves your own machine.
Related MCP server: M365 MCP
Loop is built differently from Teams or Outlook. Pages are not REST resources, they are Fluid Framework documents stored in SharePoint Embedded containers, and there is no public content-write API. So this server is a read and discovery tool, not a read-write one:
Supported: list workspaces, list pages in a workspace, read a page's content as Markdown (or raw HTML), search across your Loop files, and an experimental workspace creation.
Not supported: creating or editing page content, real time collaboration. These need the in browser Fluid runtime and have no HTTP API.
Page content is read by asking SharePoint to render the Fluid document to HTML on demand (the ?format=html export), which is then converted to Markdown. Rich, interactive components (tables, voting, mentions) may render approximately.
The Loop web app (loop.cloud.microsoft) uses MSAL to store OAuth tokens in the browser. This server:
Opens a browser to loop.cloud.microsoft via Playwright.
Extracts the MSAL tokens from local and session storage, using Loop's own first party client ID (a187e399-0c36-4b98-8f04-1edc167a0996). It keeps three: a Substrate token (workspace and page metadata), a SharePoint token (page content), and a Graph token (search).
Caches the access tokens, refresh token, and session state in ~/.msloop-mcp-server/ (AES-256-GCM encrypted).
Refreshes tokens automatically using the refresh token (HTTP, no browser) or a headless browser as fallback.
{
"mcpServers": {
"loop": {
"command": "npx",
"args": ["-y", "msloop-mcp@latest"]
}
}
}Then run loop_login from your MCP client. On first use a browser opens so you can sign in; after that, logins are silent and no browser appears. Do not close the window manually, it closes itself once you are signed in.
Tool | Description |
| Sign in to Loop (silent if possible, browser only when needed) |
| Check authentication status and token validity |
| Clear the saved session and tokens |
Tool | Description |
| List all Loop workspaces you can access, including your personal "My workspace" |
| List the pages in a workspace (pass a workspace id) |
| Read a page's content as Markdown (or |
| Search across your Loop pages and components by keyword (via Microsoft Graph) |
| Experimental. Create a new shared workspace. Content cannot be created via API |
Session files are stored encrypted in ~/.msloop-mcp-server/:
session-state.json: Playwright browser session (cookies + localStorage)
token-cache.json: Extracted and cached tokens
browser-profile/: Persistent browser profile for headless refresh
If your session expires, run loop_login again.
Tokens are refreshed automatically:
HTTP refresh (fast, no browser): uses the cached refresh token with Loop's client ID, one call per resource (Substrate, SharePoint, Graph).
Headless browser refresh: fallback if HTTP refresh fails; opens a headless browser with the saved profile to silently reacquire tokens.
Node.js 20+
A Chromium based browser: Edge or Chrome (detected automatically from system default)
A Microsoft 365 work or school account with access to Microsoft Loop
Variable | Description |
| Enable debug logging to stderr |
| Force a specific browser: |
| Pin a specific Chrome profile dir for cookie import (e.g. |
| Pin a specific Edge profile dir for cookie import (e.g. |
| Skip importing SSO cookies from your real browser (avoids the one time Keychain/keyring prompt). You sign in once manually; the persistent profile then remembers the session |
Uses the same auth as the Loop web client, so your access is limited to what your account can do.
Tokens are encrypted at rest (AES-256-GCM with a machine derived key).
Uses undocumented internal APIs, which Microsoft may change without notice.
The Loop endpoint mapping (Substrate discovery, the SharePoint multipart "GET via POST" convention, and the HTML export route) was informed by exec-astraea/loop-migration and Nico De Cleyre's "Microsoft Loop under the hood".
MIT. See LICENSE.
EXPERIMENTAL: Create a new shared Loop workspace. Workspace creation is only partially documented and the new workspace may need a moment to finish provisioning in the Loop app. Creating page content is not supported.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Display name for the new workspace. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses critical behavioral traits: experimental status, incomplete documentation, asynchronous provisioning delay, and unsupported page creation. This goes beyond a simple 'create' action and sets proper expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, concise and front-loaded with the important 'EXPERIMENTAL' label. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple creation tool with one parameter and no output schema, the description covers experimental nature, provisioning delay, and unsupported features. It is sufficiently complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter 'name' already described in the input schema. The description adds no additional meaning or context beyond the schema's 'Display name for the new workspace.'
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Create a new shared Loop workspace', which is a specific verb+resource combination. It distinguishes from sibling tools like loop_list_workspaces (list) and loop_get_page (page retrieval).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explicitly labels the tool as 'EXPERIMENTAL' and notes that workspace creation is only partially documented, may need provisioning time, and page content creation is not supported. This provides clear context on when and how to use it, though no explicit alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the content of a Loop page as Markdown. Pass the page id from loop_list_pages. Loop pages are rich Fluid documents exported to HTML, so some interactive components may render approximately.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Output format. Default: markdown. | |
| page_id | Yes | The page id to read. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that Loop pages are rich Fluid documents exported to HTML and interactive components may render approximately, informing the agent about potential lossiness. No annotations exist, so the description carries the burden well. Could mention idempotency, but read operation is implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each purposeful: purpose, usage hint, behavioral note. No wasted words. Front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with 2 parameters and no output schema, the description covers purpose, usage source, and a key limitation. Minor gap: no error case info, but overall complete enough given sibling tools and simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already provides full descriptions for both parameters (100% coverage). The description adds no additional meaning beyond what the schema offers. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it reads content of a Loop page as Markdown, with a specific verb and resource. It also references getting the page id from loop_list_pages, distinguishing it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: pass page id from loop_list_pages. Implicitly tells when to use this tool (after listing pages). Lacks explicit when-not or alternative tools, but the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the pages in a Loop workspace. Pass the workspace id from loop_list_workspaces.
| Name | Required | Description | Default |
|---|---|---|---|
| workspace_id | Yes | The workspace id to list pages for. | |
| include_deleted | No | Include deleted pages. Default: false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavior. It only states it lists pages, omitting details about pagination, rate limits, or any destructive potential. The include_deleted parameter hints at a default behavior but is not described in the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences front-load the purpose and provide a practical hint. No fluff, but could be slightly more structured with separate usage guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a list tool with no output schema, the description should explain the return format (e.g., list of page titles/IDs). It lacks details on pagination, error conditions, or the effect of include_deleted. This leaves the agent guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds value by suggesting the workspace_id come from loop_list_workspaces, but does not elaborate on include_deleted beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List the pages in a Loop workspace' with a specific verb and resource. It also provides a hint to use the workspace id from loop_list_workspaces, helping to distinguish from sibling tools like loop_get_page or loop_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by referencing loop_list_workspaces, but does not explicitly state when to use this tool versus alternatives (e.g., loop_search) or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Microsoft Loop workspaces you can access, including your personal "My workspace". Returns each workspace id and title.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the return fields but omits behavioral details like potential network calls, limits, or side effects. Minimal disclosure beyond purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words. Efficiently conveys purpose and output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but description explains the return format (id and title). For a simple list tool, this is sufficient. Missing details on pagination or limits, but complexity is low.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters; description adds value by stating that no input is needed and what is returned (id and title, including My workspace). This compensates for the lack of schema complexity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List'), the resource ('Microsoft Loop workspaces'), the scope ('all you can access, including your personal 'My workspace''), and the output ('workspace id and title'). This distinguishes it from sibling tools like loop_create_workspace.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing workspaces but does not provide explicit when-to-use or when-not-to-use guidance. No alternatives are mentioned, but the context of siblings makes the use case clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sign in to Microsoft Loop. Tries silently first (no browser); opens a browser only when the session has expired. Set force_new: true to force a full re-login.
| Name | Required | Description | Default |
|---|---|---|---|
| force_new | No | Force a full re-login even if a session exists — clears the saved session first. Default: false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses important behaviors: silent browserless attempt first, browser prompt only on expired session, and effect of force_new clearing saved session. Without annotations, this compensates well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences are concise, front-load the action, and contain no fluff. Every phrase adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains the login mechanism and parameter. However, it doesn't state that a successful login establishes a session for other tools, which is implicitly understood.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter force_new has 100% schema coverage; the description adds behavioral context ('clears the saved session first'), enhancing understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool signs in to Microsoft Loop, specifying the silent attempt first and browser fallback on session expiry. This distinguishes it from sibling tools like loop_logout or loop_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use (sign in) and how to force a new session with force_new parameter. While it doesn't explicitly list when not to use, the guidance is clear for a login tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clear the saved Loop session and tokens. You will need to run loop_login again.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It clearly states the destructive action of clearing session and tokens. However, it lacks details on whether the action is irreversible or if authentication is required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words. The information is front-loaded and directly to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description is fully adequate. It explains the tool's action and the necessary follow-up step.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so baseline is 4. Description does not need to add parameter information, and it doesn't.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it clears the saved Loop session and tokens, using specific verbs and resource. It distinguishes from sibling tools like loop_login, which performs the opposite action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies when to use (to log out) and provides a post-usage note about needing to run loop_login again. No explicit when-not or alternatives, but the context is simple enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search across your Loop pages and components by keyword (via Microsoft Graph). Returns matching files with their titles, web links, and last-modified dates.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum results to return. Default: 25. | |
| query | Yes | Keywords to search for. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions that searching is via Microsoft Graph and returns specific fields, but does not disclose behavioral traits such as authentication needs, rate limits, or that it is a read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the verb and resource. Every word adds value, and no unnecessary information is included.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with no output schema, the description adequately explains return fields (titles, web links, last-modified dates). It does not mention pagination or result format, but overall it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters having descriptions. The tool description adds context about return values and the use of Microsoft Graph, but does not significantly extend beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches across Loop pages and components by keyword, using Microsoft Graph. It specifies the resource, action, and return information (titles, web links, last-modified dates), distinguishing it from sibling tools like loop_list_pages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention when not to use it or compare it to similar tools like loop_list_pages or loop_get_page.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the current Loop authentication status and token validity.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavior beyond the basic action. It mentions checking status and token validity but omits details like whether it makes network calls, returns a boolean or structured data, or has rate limits. Adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence of 10 words immediately conveys the purpose with no redundant information. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool, the description is fairly complete, indicating the check of auth status and token validity. However, it lacks detail on the return format or possible output states, which would be helpful for an agent using the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% coverage, so the description has no parameters to explain. The baseline for no parameters is 4, and the description adds context about what the tool does beyond the schema, maintaining this score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Check' and clearly identifies the resource 'Loop authentication status and token validity'. It distinguishes itself from sibling tools like loop_login and loop_logout by focusing on status checking rather than authentication actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., loop_login to initiate auth, loop_logout to end it). It merely states what the tool does without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.2loop_create_workspaceloop_get_pageloop_list_pagesloop_list_workspacesloop_loginloop_logoutloop_searchloop_statusScored across 8 tools
Each tool has a distinct purpose: auth (login, logout, status), resource listing (workspaces, pages), reading and searching page content, and workspace creation. No overlap in functionality.
All tools follow the 'loop_verb_noun' pattern with consistent verbs (create, get, list, login, logout, search, status) and nouns, making naming predictable and clear.
8 tools cover the core operations for Microsoft Loop: authentication, workspace/page listing, page reading, searching, and workspace creation. This is a well-scoped and manageable set.
The set provides read and list operations along with workspace creation, but lacks update/delete for pages and workspaces, and does not support creating or editing page content. Notable gaps exist.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Official Microsoft MCP Server to query Microsoft Entra data using natural language
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
Hosted MCP server with managed OAuth for 15+ toolkits: Google Workspace, Fitbit, Oura, Kalshi, etc.
MCP server for secureFlows: token-free URL builders and integration-linting tools for AI agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/shayanline/msloop-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
