Microsoft 365 Visio / diagram publishing

MCP Server

• Package: @softeria/ms-365-mcp-server (MIT)
• Invocation — deliberately not --read-only, because publishing requires a write:

`` npx -y @softeria/ms-365-mcp-server --enabled-tools 'upload-file-content|drive-item|folder-files' ``

• Requires: an Entra ID app registration with delegated Files.ReadWrite scope.

Version 2.0.0 replaced a package that did not exist. This skill previously invoked
npx -y @anthropic-ai/microsoft-graph-mcp (404 on npm) and documented two graph_*
tool names that exist in no server. The tool names below came from the live server.

The filter is mandatory

Unfiltered, the server exposes 188 tools at ~225,355 tokens — 45× the 5,000-token ceiling. Keep the filter as narrow as the task allows.

This invocation can write — treat it accordingly

--read-only is omitted here on purpose, which makes this the one M365 surface that changes remote state. Under Principle III a write to a system of record is gated: confirm the target path and filename with the operator before uploading, and never overwrite an existing item without saying so first. Use msgraph-files for anything that only needs reading.

Verified tools

There are **no graph_* tools, and there is no Visio rendering or conversion tool**. This surface moves files; it does not open or edit Visio documents.

Workflow: publish a generated diagram

1. verify-login, and login if needed — surface the device code, never fabricate a session
2. list-folder-files on the destination folder — confirm it exists and note existing names
3. get-drive-item on the intended filename — is this an overwrite? If so, say so and get

confirmation before proceeding

1. upload-file-content with the bytes
2. Report the resulting item id and path. Do not claim success without the server's response.

Produce the .vsdx itself with document-generation or a diagram skill; this skill only publishes what already exists on disk.

Reading results honestly

• An upload confirms transfer, not correctness. That the bytes landed says nothing about

whether the diagram is accurate.

• A failed upload can leave a partial item depending on size and session; re-check with

get-drive-item rather than assuming a clean failure.

• There is no rename or delete here — the filter excludes them deliberately. Fixing a bad

filename is an operator action in the web UI.

Not verified

Tool names and manifest cost are measured; no upload has been performed. That needs an M365 tenant with write scope, which this environment does not have. The write path is correct-by-construction and unproven.

Integration with Other Skills

Environment Variables

• MS365MCPCLIENT_ID — Entra ID app registration (client) ID
• MS365MCPTENANT_ID — tenant ID, or common