Allows reading, listing, creating, and editing Microsoft Loop pages via the Loop web app.
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., "@loop-mcp list my top-level Loop pages"
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 that lets Claude read and write Microsoft Loop pages — on your own Loop login, from your own machine.
Tool | Action |
| Read a page (by URL) as Markdown |
| List the top-level pages of a workspace |
| Create a page from Markdown |
| Append to / replace a page |
MCP stands for Model Context Protocol. Think of it as a plug-in that gives Claude the ability to talk to a specific tool — in this case, Microsoft Loop. You install it once; after that, it works in every conversation.
Related MCP server: DrissionPage MCP Browser Automation
Microsoft Loop has no API for creating or editing pages (confirmed by Microsoft, 2026). Reading via the Graph API exists but requires an Azure app registration + admin consent + SharePoint Embedded guest registration — a governance bottleneck. So this MCP drives the Loop web app itself in a dedicated Chrome window that you sign into:
Read — opens the page, extracts the rendered content, converts to Markdown.
Write — pastes Markdown; Loop converts it into native blocks (headings, lists, tables, checklists…).
Everything runs as you: the tool can only see and touch what your own Loop account can. No shared secrets, no elevated permissions, nothing leaves your machine.
Trade-offs to know: the dedicated browser window must be open and signed in while you use the tools, and Microsoft's security policy will typically ask you to sign in again each day (same as the regular Loop website).
git clone https://github.com/2mattias/loop-mcp.git && cd loop-mcp && ./install.shThe installer checks prerequisites (installs python3.12/pipx via Homebrew
if missing), installs the package, downloads the browser, registers the MCP
with Claude Code, and opens the sign-in window.
The only manual step: sign into Loop in the window that opens (password + token PIN). Let Chrome save your password and answer Yes to "Stay signed in?" — future days become autofill + PIN.
Then restart Claude Code and try: "read this Loop page: <paste a Loop URL>".
Keep the "Chrome for Testing" window open (signed into Loop) whenever you use the Loop tools. If you closed it, reopen with:
<path-to-repo>/scripts/launch-chrome-debug.shIf a Loop tool suddenly fails with a sign-in page, that's Microsoft's daily re-authentication — sign in again in that window and retry.
SKILL.md contains the full operating manual: tool reference, Markdown
formatting rules for Loop (what renders well, what to avoid), safety rules for
creating/editing pages, and an ordered troubleshooting matrix for connection
problems. Install it as a Claude Code skill to get /loop-page:
mkdir -p ~/.claude/skills/loop-page
cp SKILL.md ~/.claude/skills/loop-page/SKILL.mdVariable | What it is |
|
|
| Ports scanned in |
| Default workspace for create/list (optional — copy your workspace URL from the browser). |
| Alternative mode: dedicated Playwright profile instead of CDP attach. |
|
|
| Profile mode: |
The launcher script honors LOOP_CDP_PORT (default 9222) and
LOOP_CHROME_DEBUG_DIR (default ~/.loop-mcp/chrome-debug).
loop-mcp read "<page_url>"
loop-mcp list --workspace-url "<workspace_url>"
loop-mcp create "Page title" --stdin < content.md
loop-mcp edit "<page_url>" --mode append --stdin < addendum.mdclaude mcp add loop --env LOOP_CDP_URL=auto \
-- ~/.local/pipx/venvs/loop-mcp/bin/python -m loop_mcp.mcpOr in a project's .mcp.json:
{
"mcpServers": {
"loop": {
"type": "stdio",
"command": "/Users/<you>/.local/pipx/venvs/loop-mcp/bin/python",
"args": ["-m", "loop_mcp.mcp"],
"env": { "LOOP_CDP_URL": "auto" }
}
}
}Symptom | Fix |
"Could not attach to Chrome" | Run |
Tool returns the Loop marketing page / "Sign in" | Daily re-auth — sign in again in the debug window |
"Browser context management is not supported" | You pointed it at your everyday Chrome — use the launcher script instead |
Tools missing in Claude |
|
The full ordered troubleshooting matrix (for you or your AI) is in SKILL.md.
claude mcp remove loop
pipx uninstall loop-mcp
rm -rf ~/.loop-mcp ~/.claude/skills/loop-pagemacOS (Linux best-effort), Claude Code
Python 3.12 + pipx (auto-installed via Homebrew if missing)
A Microsoft 365 account with Loop access
All selectors and flows validated live against the Loop web app (2026-07-21): read, list, create (end-to-end), and the paste-to-blocks conversion. Selectors are role/name-based (accessibility tree) — the most stable option — but a Loop UI redesign can still break them; fixes land in this repo.
MIT
Create a new Microsoft Loop page and fill it with Markdown. Drives the authenticated Loop session; Markdown is auto-normalized for Loop's paste-to-blocks conversion. Requires an active session.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Page title. | |
| markdown | Yes | Page body in Markdown. | |
| workspace_url | No | Target workspace URL. Defaults to LOOP_DEFAULT_WORKSPACE_URL. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses that the tool 'drives the authenticated Loop session' (indicating stateful action), mentions markdown auto-normalization, and requires an active session. This provides valuable behavioral context beyond the schema.
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 three concise sentences, each earning its place: purpose, behavioral mechanism, and prerequisite. It is front-loaded with the core action and avoids redundancy.
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 create tool with 3 parameters and no output schema, the description is quite complete. It covers the operation, explains normalization, and notes the session requirement. It might optionally mention error cases, but overall it provides sufficient context for an agent to use it correctly.
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%, so baseline is 3. The description adds meaning to the 'markdown' parameter by explaining that it is auto-normalized for Loop's paste-to-blocks conversion, and also clarifies the 'title' parameter by saying the page is filled with Markdown. This enriches the parameter semantics 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 action ('Create a new Microsoft Loop page') and the resource ('Loop page'), and specifies that it fills the page with Markdown. This distinguishes it from siblings like loop_get_page/loop_list_pages/loop_edit_page by explicitly focusing on creation.
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 gives clear context for when to use it (creating a new page) and mentions the prerequisite of an active session. It does not explicitly name alternatives or exclusions, but the resource and action are specific enough to imply appropriate usage contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Edit an existing Microsoft Loop page: append Markdown to the end or replace the body. Requires an active authenticated session.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | append (default) or replace the body. | |
| markdown | Yes | Markdown to append or write. | |
| page_url | Yes | URL of the Loop page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosure. It explicitly mentions the 'append' and 'replace' behaviors (including the destructive nature of replace) and notes the requirement for an authenticated session. This goes beyond a generic statement, though it could further mention outcome or error behavior.
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 two concise sentences that front-load the core purpose and then add one necessary constraint (authentication). Every phrase adds value, with no redundancy or filler.
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 edit tool with three parameters fully described in the schema, the description covers the essential context: what it does, the modes, and the auth requirement. It does not mention return values or error handling, but given the schema's completeness, this remains a well-rounded description.
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 provides full descriptions for all three parameters with 100% coverage. The tool description essentially restates the mode semantics ('append' or 'replace the body') without adding new meaning beyond what the schema already conveys. Hence, the baseline of 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 the tool edits an existing Microsoft Loop page and specifies the two modes (append Markdown or replace the body). It distinguishes itself from sibling tools like get/list/create by explicitly targeting existing pages for modification.
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 conveys when to use the tool (to modify an existing Loop page) and implicitly discourages using it for creation or retrieval. However, it does not explicitly mention alternatives or state when not to use it, which would make the guidance even stronger.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a Microsoft Loop page as Markdown. Opens the page in the user's authenticated Loop session and extracts the rendered content. Provide the page URL.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL of the Loop page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It states the tool reads and extracts rendered content, implying a non-destructive operation, and mentions the authenticated session. It does not cover error behavior or side effects, but for a read tool this is adequately transparent.
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 two sentences, front-loaded with the core action, and contains no superfluous information. Every word earns its place, making it highly concise and well-structured.
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?
The description covers the action, output format, authentication prerequisite, and required input. For a simple read tool with no output schema, this is sufficient. It lacks explicit mention of read-only semantics or error scenarios, but these are minor gaps given the 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 description coverage is 100% for the url parameter. The description merely says 'Provide the page URL', which adds no new meaning beyond the schema. Baseline of 3 applies because the schema already documents the parameter fully.
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 ('Read a Microsoft Loop page as Markdown'), specifies the resource (Microsoft Loop page), and differentiates from siblings by the read operation versus list/create/edit. This makes the tool's purpose unambiguous.
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 clear context: it operates on a specific page via URL and uses the user's authenticated session. While it does not explicitly name alternatives, the verb and resource strongly imply when to use it. Exclusion of alternatives is not explicit, so a small deduction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Best-effort list of Loop pages visible in a workspace (scrapes the workspace navigation). Returns title + URL. May miss pages not rendered in the current view.
| Name | Required | Description | Default |
|---|---|---|---|
| workspace_url | No | Workspace URL. Defaults to LOOP_DEFAULT_WORKSPACE_URL. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the best-effort nature, that it scrapes workspace navigation, and may miss pages not rendered. It also specifies the return fields (title + URL), which adds useful behavioral context.
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, front-loaded with the core purpose ('Best-effort list...'), followed by essential caveats and output format. No wasted words.
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 one-parameter tool with no output schema, the description adequately explains what is returned and the main limitation. It could mention potential performance or auth requirements, but given its simplicity, it is largely 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 coverage is 100% with the workspace_url parameter already described, including a default. The description does not add parameter-specific details beyond the overall tool behavior, so it meets the baseline but does not exceed it.
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 lists Loop pages visible in a workspace, using the verb 'list' and specifying the resource and scope. It distinguishes from siblings (get, create, edit) which perform different operations.
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 use for enumerating pages but does not explicitly mention when to prefer this over siblings or when not to use it. It provides a caveat about missing pages but no direct alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool maps to a distinct operation: read, list, create, and edit. There is no overlap in purpose, and the descriptions make the boundaries clear (e.g., get_page returns content while list_pages returns titles/URLs).
All tools follow the `loop_` prefix with a consistent `verb_noun` pattern: get_page, list_pages, create_page, edit_page. The naming is uniform and predictable.
With 4 tools, the server is well-scoped for basic Loop page management. The count is within the ideal range and each tool serves a clear, non-redundant purpose.
The server covers the main page lifecycle: list, read, create, and update. A delete operation is missing, but this is a minor gap that can be worked around, and the core workflows are well supported.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP-native open-source Notion alternative: read & write pages, databases and kanban boards.
Converts any URL to clean, LLM-ready Markdown using real Chrome browsers
Interact with your HackMD notes and teams seamlessly. Manage your notes, view reading history, and…
Web search, URL content extraction to Markdown, site mapping, and recursive web crawler.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/2mattias/loop-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
