| name | msgraph-visio |
| description | Upload and retrieve Visio (.vsdx) and other diagram files in OneDrive/SharePoint via the Microsoft 365 MCP server. Use when publishing a generated topology diagram to OneDrive, or fetching an existing .vsdx for reference |
| version | 2.0.0 |
| license | Apache-2.0 |
| tags | ["microsoft365","visio","onedrive","diagrams","upload"] |
Microsoft 365 Visio / diagram publishing
MCP Server
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
| Tool | What it does |
|---|
upload-file-content | write file bytes to a drive path — the write |
get-drive-item | metadata for one item, to check whether you are about to overwrite |
list-folder-files | folder contents, to confirm the destination exists |
login / verify-login | device-code sign-in and session state |
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
verify-login, and login if needed — surface the device code, never fabricate a sessionlist-folder-files on the destination folder — confirm it exists and note existing namesget-drive-item on the intended filename — is this an overwrite? If so, say so and get
confirmation before proceedingupload-file-content with the bytes- 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
| Skill | How They Work Together |
|---|
msgraph-files | Read-only inspection — prefer it whenever you are not writing |
document-generation, drawio-diagram, uml-diagram | Produce the file this publishes |
gait-session-tracking | Record every upload: path, filename, item id |
Environment Variables
MS365_MCP_CLIENT_ID — Entra ID app registration (client) IDMS365_MCP_TENANT_ID — tenant ID, or common
