Microsoft Sharepoint

Microsoft SharePoint

Agent-callable tools for Microsoft SharePoint Online, over the Microsoft Graph API v1.0 (https://graph.microsoft.com/v1.0/sites/...): find sites and document libraries; browse, search, upload, download, move, copy, and share files and folders; manage SharePoint lists and list items; and author and publish site pages. 32 scripts across sites, drives, files & folders, sharing & permissions, lists, list items, and pages. Read-only navigation tools resolve the ids (siteId, driveId, listId, pageId, column internal names) that the write tools require — a site is addressed by an opaque composite id you get from findSites/getSite, never constructed by hand.

Independent, unofficial connector for Microsoft SharePoint. Not affiliated with, endorsed by, or sponsored by Microsoft SharePoint. "Microsoft SharePoint" is a trademark of its owner, used only to identify the service this connector works with.

When to use this

• An agent needs to find or read SharePoint content — search sites, list a site's document libraries, browse or search files and folders, or read a file's / list-item's / page's details.
• An agent needs to work with files — create folders, upload text or binary files, move / copy / rename, export to PDF or HTML, or share (links and per-person grants) and manage permissions.
• An agent needs to work with lists — list a site's lists, discover a list's columns, create lists, and create / read / update / delete list items.
• An agent needs to author pages — create a draft site page (optionally with text body content) and publish it.

Setup

This is an agentskills.io skill.

If the connector has not been installed as a skill yet, install it first with npx skills add zapier/connectors --skill microsoft-sharepoint (or your harness's own skill-install mechanism), then continue here. Installing the skill copies these files, not dependencies. Before running the CLI, a local MCP server, or zapier-sdk auth commands, run npm install --omit=dev here once. Importing the published package as a dependency in your own project instead? That npm install already resolves everything — see references/use-as-sdk.md.

Want the actual repo source instead — to browse references/, run this connector's tests, or hack on it? See README.md for a scoped git clone.

The connector runs on Node.js 22.18+. Pick the reference that matches how you're running it, and load it before doing anything else:

Scripts

All scripts use the single connection microsoft-sharepoint, except getCopyStatus, which needs no connection (it polls a pre-authenticated monitor URL).

Disambiguation & refusals

Disambiguation before a write. Before writing to something you looked up by name — a site from findSites, a list from listLists, or a list item from findListItems — count the exact case-insensitive name matches:

• Exactly one match — act on it. Don't over-ask; a single unambiguous match is the answer.
• Two or more that tie — stop. List the tied candidates with a distinguishing field (webUrl, id, or lastModifiedDateTime) and ask which one the user means. Don't pick arbitrarily, and don't write to all of them. Site names in particular collide across departments (e.g. two "Marketing" sites).

Unsupported operations — say so and stop; don't fake it with another tool. This catalog deliberately does not:

• Move a file across libraries or sites (no native move). moveItem is same-library only. The only way to relocate across libraries/sites is copyItem → (getCopyStatus) → deleteItem, which is lossy: the copy gets a new id and URL, its sharing links and permissions don't carry over, and a half-failed copy can lose the file. You may perform this relocation when asked to move a file elsewhere, but never present it as a plain "move": warn the user first that it's a copy-then-delete, tell them the file's URL/id changes and sharing links & permissions won't carry over, confirm the copy succeeded via getCopyStatus before deleting the original, and report the new location. Never silently copy-delete and report a completed move.
• Edit an existing page's body, or add non-text web parts (images, embeds, quick-links, multi-column layouts). createPage authors a single text web part on a new page; editing an existing page's content and rich web parts are out of scope. Do not delete the page and recreate it to simulate an edit — that changes the page's id/URL and loses its version history, comments, and permissions. Tell the user in-place body editing isn't supported and stop.
• Enumerate every site in the tenant. There is no "list all sites" — a delegated token can't. Use findSites (keyword) or getSite with a known path.
• Manage content types, site columns, term-store metadata, or triggers (new-file / new-item notifications). These aren't exposed.
• Write person/group or multi-value lookup columns on list items. Those column types are read-only here.

If asked for any of these, tell the user it's unsupported and stop — don't reach for an unrelated tool to approximate it.

Auth

Every shape passes auth as one connection selector, not the secret — a [<resolver>:]<value> string. Every connector accepts zapier:<connection-id> (Zapier-managed auth — routes through Zapier's auth, retries, and governance layer); some also accept one or more direct-token resolvers (naming and count vary per connector) — check this connector's own resolvers rather than assuming. The <resolver>: prefix is optional; a bare value goes to the first resolver that claims it — a UUID-shaped bare value always claims zapier:. Each script declares the connections it needs and the resolvers each accepts. The exact syntax for passing a connection (and how to see this connector's resolver list) differs by shape — see the reference you loaded above.

Checking what's already configured first? Don't dump environment values to do it — env or env | grep <name> prints the value along with the name, leaking a live credential into the transcript if one is set. Check names only (env | cut -d= -f1 | grep -i <name>) or test a known name directly ([ -n "$VAR_NAME" ]).

No connection yet? Pick one — and follow the reference's own flow to obtain it; never just ask the user for a connection id or token as if they already have one memorized:

Output format

Every script returns a { data, meta } envelope:

• data — the script's result (the shape its outputSchema declares; see the reference you loaded above for how to inspect a script's exact schema in your shape).
• meta.outputDataValidation — what validating data did:
  • { skipped: false, droppedPaths: null } — validated, nothing removed.
  • { skipped: false, droppedPaths: [...], instruction } — validated, but those paths were stripped from data: fields the script returned from the API that the outputSchema doesn't declare. If you need them, re-run with output validation skipped.
  • { skipped: true } — validation was bypassed; data is the raw, unchecked script output.

Reading dropped fields / skipOutputDataValidation. To receive the raw, unvalidated result, opt out of output validation (the exact syntax differs by shape — see the reference you loaded above). Input validation is never skipped.

Trimming the result / filterOutputData. To shrink a large result down to the fields you need, pass a jq expression that post-processes data (again, exact syntax per shape). The jq runs against data only, NOT the { data, meta } envelope, so write it rooted at data (run the script's --help — or your shape's equivalent — to see its output schema). The transformed value replaces data, meta is preserved, and the result is NOT re-validated against the output schema.

References

Load the matching reference file before working in that area: