How do I use mcp-server-sharepoint?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-server-sharepoint Update the quality manual in SharePoint with revised section 5" 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-sharepoint

by XMV-Solutions-GmbH

Overview Schema Related Servers Score Discussions

Python

Remote

mcp-server-sharepoint

PyPI version Python versions Downloads Licence Coverage Contributions welcome

In one sentence: an MCP server that lets AI coding agents like Claude Code edit files in your SharePoint document libraries the same way a careful human would — with proper checkout, comments, version history, and lock conflicts — instead of overwriting things and breaking your audit trail.

What is this for?

You have important documents in SharePoint — ISO 27001 controls, contract templates, ISMS records, runbooks, a quality manual. They have version history, audit trails, retention policies, and someone above you cares that they stay compliant.

You'd love to let AI agents help you draft and update these documents — they're great at it. But every other "AI + SharePoint" tool you've tried makes the audit log say "a robot named rclone updated this file at 03:42 with no comment" — which means your auditor has questions.

mcp-server-sharepoint makes the audit log say what actually happened: "David Koller updated this file at 14:32. Comment: ‘Tightened control wording for A.5.1 per CISO review.’ Version: 3.5 → 3.6 (minor)." Because the AI agent uses the same Microsoft-blessed checkout/checkin model a human Office user would.

Concretely, the agent gets these tools:

Tool	What the agent does	What ends up in SharePoint
`sp_search_query`, `sp_drive_folder_list`, `sp_drive_file_read`	finds and reads files	nothing changes
`sp_drive_file_checkout`	acquires a checkout lock + downloads	"checked out by you" appears for everyone else
`sp_drive_file_checkin`	uploads + checks in with a comment	a real new version with a real comment in the audit log
`sp_drive_file_checkout_discard`	discards a checkout	lock released, no version created
`sp_drive_checkout_list`	shows what's currently checked out by this agent	nothing changes

Every action is attributed to the human who signed in once via Microsoft's standard Device Code login. No service-account "robot" identity. No silent overwrites. No broken locks. Lock conflicts are reported as conflicts. ETag checks catch concurrent edits before they clobber.

Related MCP server: m365-mcp-server

Installation

pip install mcp-server-sharepoint
# or, with uv (recommended):
uv tool install mcp-server-sharepoint
# or, on the fly without installing globally:
uvx mcp-server-sharepoint --help

Requires Python 3.11+. Works on Linux, macOS, Windows.

Quickstart

uvx mcp-server-sharepoint login

Output looks like:

Sign in to mcp-server-sharepoint via the Device Code flow:
Open the URL in a browser and type the code.

     URL:   https://login.microsoft.com/device
     Code:  D2LKUY4AV

Waiting for sign-in...

Open the URL in any browser, type the code, sign in with your M365 account. Your refresh token is cached locally — see Token storage. The MCP server itself never blocks for human interaction afterwards.

2. Wire it into Claude Code

In your project's .mcp.json:

{
  "mcpServers": {
    "sharepoint": {
      "command": "uvx",
      "args": ["mcp-server-sharepoint"]
    }
  }
}

Restart Claude Code. The agent now has sp_search_query, sp_drive_folder_list, sp_drive_file_read, sp_drive_checkout_list available — read-only by default.

3. Enable writes (when you're ready)

{
  "mcpServers": {
    "sharepoint": {
      "command": "uvx",
      "args": ["mcp-server-sharepoint"],
      "env": { "SP_ALLOW_WRITES": "true" }
    }
  }
}

Now sp_drive_file_checkout, sp_drive_file_checkin, sp_drive_file_checkout_discard are also available.

3a. Restrict the tool surface (optional)

If your project only needs a subset of SharePoint — say, document files but not SharePoint Lists — set SP_TOOL_GROUPS to register only the relevant tool groups. Reduces LLM tool-selection error by hiding tools the agent never needs.

{
  "mcpServers": {
    "sharepoint": {
      "command": "uvx",
      "args": ["mcp-server-sharepoint"],
      "env": {
        "SP_TOOL_GROUPS": "drive,search,site",
        "SP_ALLOW_WRITES": "true"
      }
    }
  }
}

Six groups available: auth, site, drive, list, share, search. Default (unset) registers all of them. auth is always included regardless — every other call needs it. Unknown group names cause a loud non-zero startup exit so typos surface immediately.

SP_TOOL_GROUPS is orthogonal to SP_ALLOW_WRITES — group selection picks which categories register; the writes flag decides whether the mutating tools within each category register.

4. Try it

You:    Find our latest ISO 27001 control A.5.1 policy in SharePoint.
Agent:  [calls sp_search_query → finds it]
        Found "iso27001-A.5.1.md" at https://contoso.sharepoint.com/...

You:    Read it, suggest two improvements based on the new revision of the standard.
Agent:  [calls sp_drive_file_read → reads file → suggests in chat]

You:    Apply them and save with a comment summarising the changes.
Agent:  [calls sp_drive_file_checkout → modifies → sp_drive_file_checkin with comment]
        Saved version 1.4. Comment recorded: "Tightened wording per ISO 27001:2022 to match new control objective; added cross-reference to A.5.2."

Each tool call gets a permission prompt in Claude Code (you can mark trusted ones as "always allow" per session). Read tools are flagged read-only; write tools are flagged destructive — you see the difference.

What it can do, in detail

Read tools (always available)

Tool	Purpose
`sp_search_query(query, site?, folder?, file_type?, modified_after?)`	KQL-style search across SharePoint sites the user has access to. Returns hits with name, path, web URL, last-modified date, author.
`sp_drive_folder_list(url)`	List a SharePoint folder's children (files + sub-folders) with size, type, last-modified. URL is the human-readable web URL.
`sp_drive_file_read(url)`	Download a file's content to a local temp file with the original extension preserved. Read-only — does NOT acquire a checkout.
`sp_drive_checkout_list(verify=False)`	Show what files this agent currently has checked out, when, and where the local working copies are. With `verify=True`, additionally queries SharePoint to confirm the server-side lock state — adds `server_locked` (`true`/`false`/`null`) and `lock_holder` (display name) to each entry. Costs one Graph call per registry entry.
`sp_site_list(query?)`	Discover SharePoint sites the user can see. `query` is a free-text site-name search; omit to list all. Useful as the agent's starting point when no site URL is known yet.
`sp_site_followed_list()`	List sites the user has Followed in SharePoint — a curated "my SharePoint" entry point. Not available in service-principal mode (no signed-in user).
`sp_site_drive_list(site_url)`	List the document libraries (drives) on a site — default Shared Documents plus Site Assets, Style Library, and any custom libraries. Most read/write tools accept URLs into any library transparently; `sp_site_drive_list` is the discovery step when the agent doesn't yet know which libraries exist.
`sp_site_trash_list(site_url)`	List items in the SharePoint site's recycle bin (id, name, size, deleted_date_time, deleted_from_location, deleted_by). Read-only. Uses Graph beta endpoint — see note below.
`sp_list_list(site_url)`	List all SharePoint Lists on a site (id, name, display_name, web_url, description, template).
`sp_list_column_list(list_url)`	Schema of a SharePoint List — column definitions (name, type, required, hidden, etc.). `list_url` shape: `https://<host>/sites/<name>/Lists/<list-name>`.
`sp_list_item_list(list_url, filter?, top?)`	List items in a SharePoint List with full fields expansion. `filter` is an optional OData expression like `"fields/Status eq 'Open'"`.
`sp_list_item_get(list_url, item_id)`	Fetch a single SharePoint List item with all expanded fields.
`sp_share_permission_list(url)`	List who has access to a SharePoint file, folder, or site. Pass a site URL for site-level permissions or any item URL for that item's permissions. Returns each permission with id, roles (`read`/`write`/`owner`), grantee (`{type, display_name, email, link_type, link_scope, link_web_url}`), and `inherited` flag. Read-only.
`sp_share_link_list(url)`	List existing sharing links on a SharePoint file or folder — id, web_url (the share URL), type, scope, roles. Read-only. Use `sp_share_link_create` / `sp_share_link_revoke` for the write side.
`sp_site_page_list(site_url)`	List all modern SharePoint Pages (Site Pages) on a site — id, name, title, web_url, description, page_layout, last_modified.
`sp_site_page_read(page_url)`	Fetch a single SharePoint Page including its canvasLayout (sections, columns, web parts) as raw JSON. `page_url` shape: `https://<host>/sites/<name>/SitePages/<page>.aspx`.
`sp_drive_change_track(scope_url, since?)`	Microsoft Graph delta query — returns items in the site's default drive that changed since the optional cursor. First call (no cursor) returns the full item set + an initial cursor. Subsequent calls with the cursor return only created/modified/deleted items since. Cursor is opaque — store it (typically in the agent's conversation memory) and pass it back. Stale cursor surfaces as 410 Gone; drop it and re-sync from scratch.

Non-default libraries

URLs into non-default document libraries (Site Assets, Style Library, custom libraries) work transparently across sp_drive_folder_list, sp_drive_file_read, sp_drive_file_checkout, sp_drive_file_checkin, sp_drive_file_upload, etc. The resolver tries the default Shared Documents drive first; on a 404, it lists the site's drives, matches the URL's first path segment to a library name, and retries against that library. One extra Graph round-trip per first-look-up at a non-default library — acceptable cost for the convenience.

Write tools (opt-in via `SP_ALLOW_WRITES=true`)

Tool	Purpose
`sp_drive_file_checkout(url)`	Acquire a server-side checkout lock + download the current content to a working-directory path. Other users see "checked out by you" until you save or release. Fails with a clear error if someone else already holds the lock.
`sp_drive_file_checkin(url, comment, version="minor"\|"major")`	Upload your changes + check the file back in with an audit comment + new version. `comment` is required and must be non-empty — describes what changed for the audit log. ETag round-trip catches "someone else changed the file underneath us" and refuses to clobber.
`sp_drive_file_checkout_discard(url)`	Discard a pending checkout: drop the lock server-side and delete the local working copy. Use when you decide not to keep your edits.
`sp_drive_file_checkout_bulk(urls)`	Bulk variant of `sp_drive_file_checkout` — acquires checkouts on multiple files in parallel (up to 4 concurrent Graph calls per Microsoft throttling guidance). Returns one result per URL: `{path, status: "ok"\|"error", local_path?, error?}`. Per-file failures don't abort the batch. Honors `Retry-After` on 429/503.
`sp_drive_file_checkin_bulk(operations)`	Bulk variant of `sp_drive_file_checkin` — each op `{url, comment, version?}`. Same parallel/error-isolation semantics as `sp_drive_file_checkout_bulk`. ETag round-trip applies per file.
`sp_list_item_create(list_url, fields)`	Create a new item in a SharePoint List. `fields` is a dict of column-name -> value pairs (use `sp_list_column_list` to inspect schema).
`sp_list_item_update(list_url, item_id, fields)`	Patch fields on an existing List item. Only keys present in `fields` are changed.
`sp_list_item_delete(list_url, item_id)`	Delete a List item — sends to recycle bin (recoverable for ~93 days).
`sp_share_link_create(url, type="view", scope="organization", expires?, password?)`	Create a sharing link. Conservative defaults: `type="view"`, `scope="organization"`. The agent must explicitly pass `scope="anonymous"` to make a public link — that's the most common ISMS-audit finding, so we don't make it the default. `type="edit"` grants WRITE to anyone with the URL within scope.
`sp_share_link_revoke(url, link_id)`	Revoke (delete) a sharing-link permission. After this call the share URL stops working. `link_id` comes from `sp_share_link_create` or `sp_share_link_list`.

Recycle bin: list-only, beta endpoint

sp_site_trash_list calls Microsoft Graph's /beta endpoint. The site-level recycle-bin listing has not yet been promoted to v1.0; the beta endpoint is stable enough that SharePoint's own web UI / admin center rely on it, but the schema can change. We pin to the documented shape and will migrate to v1.0 when it lands.

Restore is not implemented. Microsoft Graph doesn't currently expose a /restore action for site-recycle-bin items (only on SharePoint Embedded fileStorageContainer recycle bins). Use the SharePoint web UI to restore individual items; we'll add a restore tool once Microsoft surfaces the action or we add a SharePoint REST API fallback.

Large files

sp_drive_file_checkin uses Microsoft Graph's resumable upload session for files larger than 100 MB (configurable via SP_CHUNKED_UPLOAD_THRESHOLD_MB). Files at-or-below the threshold use a single-shot PUT /content for a faster path. Microsoft caps single-shot at 250 MB; the resumable path supports up to 250 GB. Chunks are 5 MiB and retry on transient 5xx / connection errors with exponential backoff.

Authentication

OAuth 2.0 Device Code flow against Microsoft Identity (default). You sign in once; the refresh token is cached locally and silently renewed (~60–90 days until full re-login).
Bring-your-own-app or use ours. XMV publishes a multi-tenant Entra app registration that's baked in as the default — same pattern as Azure CLI / GitHub CLI. Tenants with strict app-allowlisting can override via SP_CLIENT_ID and SP_TENANT_ID env vars.
Token storage is auto-detected at first use: OS keyring (macOS Keychain / Windows Credential Locker / Linux Secret Service) when available, mode-0600 plain JSON file as fallback (same convention as gh auth, aws configure). Optional encryption with SP_TOKEN_PASSPHRASE for paranoid setups or CI.
Multi-customer / multi-tenant: separate SP_PROFILE per tenant, each with its own token cache.

Work or school accounts only. This server requires a Microsoft 365 work or school account (Azure AD identity). Personal Microsoft accounts (outlook.com / hotmail.com / live.com / msn.com) cannot use it — SharePoint is a business-only product, Microsoft does not expose it to consumer identities at all. Even if a personal account were allowed past the consent screen, every /sites/... call would return 404. The XMV-hosted app registration's signInAudience is therefore deliberately scoped to AzureADMultipleOrgs, which makes Microsoft block the consumer-account login attempt up-front with a clear error message rather than letting users discover the limitation post-sign-in. The sister projects mcp-server-outlook and mcp-server-microsoft-tasks DO support personal accounts because Outlook.com mail / calendar and Microsoft To Do exist on the consumer side.

The agent can drive sign-in directly via two MCP tools — no terminal shell-out required:

Agent calls sp_auth_status first. If status == "signed_in", just proceed; the user is already authenticated.
Otherwise calls sp_auth_begin, which returns immediately with a user_code and verification_url. The agent surfaces these to the user and polls sp_auth_status until status flips to signed_in (or to a terminal expired / failed).

The user-facing chat output should look like:

CCQ8U66HZ

https://login.microsoft.com/devicelogin

Code first in its own code block (so long-press copy yields just the code, no labels), URL second on its own line as a plain auto-link (so it's tappable on mobile). The user copies the code, taps the link, pastes into the page that opens — minimum app-switching. The MCP tool's description tells the agent this; agents that follow it produce a clean mobile UX.

Limitation: pending sessions live in the MCP server process. If the server restarts mid-flow (Claude Code session ends, container redeployed) before the user enters the code, the session is lost — the agent must call sp_auth_begin again. Persisting the asyncio polling task across restarts is non-trivial and deferred; if you hit this, file an issue.

Manual fallback: CLI

For terminal use or scripting, the original CLI subcommands still work:

uvx mcp-server-sharepoint login --profile <name>
uvx mcp-server-sharepoint logout --profile <name>

Both write to the same token cache sp_auth_begin does — you can sign in via CLI once, then the MCP server uses the cached token without ever hitting sp_auth_begin.

Service-principal mode (unattended automation)

For CI / scheduled jobs where no human is in the loop, run with SP_AUTH_MODE=service-principal (or just set SP_CLIENT_SECRET — auto-detected). Required env vars: SP_CLIENT_ID, SP_CLIENT_SECRET, SP_TENANT_ID. The app registration must have Application Microsoft Graph permissions (Files.ReadWrite.All, Sites.ReadWrite.All) with admin consent recorded.

Tradeoff: every action is attributed to the application principal in SharePoint's audit log, NOT a real user. The compliance-friendly default stays delegated user auth — only switch when no human is in the loop.

Security model

Three layers of "don't accidentally damage anything":

Your MCP client (Claude Code) prompts before each tool call by default. Read tools are flagged read-only; write tools are flagged destructive — you see the difference at the prompt.
Read-only by default at our server. Without SP_ALLOW_WRITES=true, the write tools aren't even registered. The agent literally can't see them.
sp_drive_file_checkin requires a non-empty audit comment. The agent has to articulate intent, and that lands in the SharePoint audit log.

The threat model is "your local OS account is trusted" — same as ~/.ssh/id_rsa, gh tokens, aws config. The tool isn't designed to defend against host compromise; it's designed to keep audit trails honest under normal use.

Roadmap

Version	Status	Theme	Highlights
v0.1	✅ released 2026-05-07	Audit-preserving doc edits	The seven `sp_*` tools above, three-layer test harness, Trusted-Publisher PyPI release pipeline, branch-protected `main`.
v0.2	✅ released 2026-05-07	Write-side polish	`sp_drive_file_upload` (upload new file), `sp_drive_file_history` + `sp_drive_file_version_get` (version-history access), `sp_drive_file_checkout_bulk` + `sp_drive_file_checkin_bulk` (bulk operations with concurrency cap), `sp_drive_checkout_list(verify=True)` server-side reconciliation, resumable uploads for files >100 MB (auto-switch), service-principal auth for unattended automation.
v0.3	✅ released 2026-05-07	Broader SharePoint surface	Site discovery (`sp_site_list` / `sp_subsites` / `sp_site_followed_list`), multi-library support + `sp_site_drive_list`, SharePoint Lists CRUD, recycle-bin listing (`sp_site_trash_list`), permissions inspection (`sp_share_permission_list`), sharing-link create/list/revoke (`sp_file_share_*`), modern Pages read/update (`sp_site_page_list` / `sp_site_page_read` / `sp_page_update`), Graph delta-query change tracking (`sp_drive_change_track`).
v0.4	🤔 maybe	Admin functions	Site / library / permission administration, IF customer demand emerges.
v1.0	🎯 stability lock-in	"API stable, production-tested"	After v0.x has been used in real customer environments for ~3–6 months without breaking changes. Not "more features" — a commitment that what you depend on today still works tomorrow.

The full ticket-by-ticket plan lives at the issues page.

Multi-profile pattern

For consultancy workflows with multiple SharePoint tenants, give each its own profile so the token caches don't collide:

{
  "mcpServers": {
    "sharepoint-acme": {
      "command": "uvx",
      "args": ["mcp-server-sharepoint"],
      "env": { "SP_PROFILE": "acme" }
    },
    "sharepoint-globex": {
      "command": "uvx",
      "args": ["mcp-server-sharepoint"],
      "env": { "SP_PROFILE": "globex" }
    }
  }
}

Sign each one in separately:

uvx mcp-server-sharepoint login --profile acme
uvx mcp-server-sharepoint login --profile globex

Tools appear in Claude as mcp__sharepoint-acme__sp_search_query etc. Cross-tenant accidents don't happen because the tokens are namespaced.

BYO Entra app registration

Tenants with strict app-allowlisting can override the bundled multi-tenant default:

{
  "mcpServers": {
    "sharepoint": {
      "command": "uvx",
      "args": ["mcp-server-sharepoint"],
      "env": {
        "SP_TENANT_ID": "<your-tenant-guid>",
        "SP_CLIENT_ID": "<your-app-registration-guid>"
      }
    }
  }
}

The app registration must be: multi-tenant or single-tenant, public client (no secret), Device Code flow allowed, with delegated permissions Files.ReadWrite.All, Sites.ReadWrite.All, User.Read, offline_access.

Token storage

Three backends, auto-detected at first use:

Tier	Backend	When	Setup
1	OS keyring	macOS Keychain / Windows Credential Locker / Linux with Secret Service	none
2	Plain file `~/.cache/sharepoint-mcp/<profile>/token.json` mode 0600	Headless Linux default	none
3	Encrypted file (Fernet, Scrypt KDF)	When `SP_TOKEN_PASSPHRASE` is set	env var

Force a specific backend with SP_TOKEN_STORE=keyring|file|encrypted-file. See the spike doc for the rationale — short version: same security model as gh auth, aws configure, npm login.

Troubleshooting

"No usable credentials"

The cached token expired (refresh tokens last ~60–90 days) or never existed. Run:

uvx mcp-server-sharepoint login --profile <name>

"Cannot checkout: file is already checked out by another user"

Someone else (or a previous instance of your own agent) has the file locked. Wait, or in the SharePoint web UI go to the library → file → "Discard check-out".

"File changed under us between sp_drive_file_checkout and sp_drive_file_checkin"

Your agent had the file open, but someone else edited it before your save. Recover with:

sp_drive_file_checkout_discard(url)        # drop your stale working copy + lock
sp_drive_file_checkout(url)           # acquire fresh lock + content
# re-apply edits to the new content
sp_drive_file_checkin(url, comment="…", version="minor")

Linux: keyring fails / "Secret Service unavailable"

The plain-file backend kicks in automatically — no action needed. If you'd rather have encryption at rest:

export SP_TOKEN_PASSPHRASE='<some-strong-passphrase>'
uvx mcp-server-sharepoint login --profile <name>

Recovery after a crash

uvx mcp-server-sharepoint     # restart the server

In the agent, ask sp_drive_checkout_list — you'll see anything that was checked out before the crash. For each, either resume work (working file is still on disk; sp_drive_file_checkin works as normal) or drop it (sp_drive_file_checkout_discard).

The registry survives crashes; nothing is lost.

Development

git clone https://github.com/XMV-Solutions-GmbH/sharepoint-mcp.git
cd sharepoint-mcp
uv sync --extra dev

# Unit + integration (no real SharePoint), with coverage reporting
./tests/run_tests.sh

# Harness (real SharePoint sandbox; requires harness-profile login)
./tests/run_tests.sh harness

Renewing the harness token

The CI harness job authenticates via a refresh token stored as the GitHub repo secret SHAREPOINT_HARNESS_TOKEN_JSON. Microsoft Identity rotates refresh tokens roughly every 60-90 days, so this is a recurring monthly maintenance chore for the maintainer.

A one-command script handles the whole flow — Device Code login, /me smoke test, base64-encoding the cached token, gh secret set against the repo:

./scripts/renew-harness-token.sh

Walks through the Microsoft Device Code prompt, then uploads the new token to GitHub. After it finishes, CI's next harness run picks up the fresh token automatically. No other manual steps.

Document	What's in it
`docs/app-concept.md`	Vision, MVP scope, MCP tool surface, auth, conflict model
`docs/testconcept.md`	Three-layer test strategy (unit / integration / harness)
`docs/RELEASING.md`	How releases happen
`ENGINEERING_PRINCIPLES.md`	Project-agnostic engineering baseline
`CLAUDE.md`	Project-specific overrides
`docs/spikes/`	Design-decision history (httpx vs SDK, token storage, etc.)

Contributing

Contributions are welcome. Please read CONTRIBUTING.md and the Code of Conduct first.

Bug reports and feature requests go to GitHub Issues.

Licence

Dual-licensed under either of:

Apache License, Version 2.0 (LICENSE-APACHE or http://www.apache.org/licenses/LICENSE-2.0)
MIT licence (LICENSE-MIT or http://opensource.org/licenses/MIT)

at your option.

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in this project by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.

Contact

Organisation: XMV Solutions GmbH
Email: oss@xmv.de
Website: https://xmv.de/en/oss/
GitHub: @XMV-Solutions-GmbH

Available Tools

21 tools

sp_auth_beginA

Initiate Microsoft Identity Device Code login for profile (default 'default'). Non-blocking: returns within ~1s with user_code + verification_url. A background task continues to poll Microsoft Identity and writes the token on success — the agent should poll sp_auth_status until status is 'signed_in', or until the user completes / cancels the flow.

Idempotency: if a pending session already exists for this profile, the existing session is returned unchanged unless force=True (which cancels and restarts).

AGENT_INSTRUCTIONS: Present the verification code to the user inside a fenced code block (so it can be copied with one click) and present the verification URL as a plain markdown link on its own line. Do not paraphrase, do not embed the code inside prose, do not wrap the URL in bold. Example:

Code:
```
ABCD-1234
```

Sign-in URL: https://login.microsoftonline.com/...

Rationale: in a chat UI, a code inside a fenced block gets a one-click copy button; a bare URL becomes clickable; bold-wrapped links and inline codes do not.

ParametersJSON Schema

Name	Required	Description	Default
`force`	No
`profile`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate readOnlyHint=false and openWorldHint=true, but the description adds critical behavior: non-blocking, background polling, idempotency for existing sessions, and force parameter effect. No contradiction with annotations; the description enriches understanding beyond structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is thorough but slightly verbose. However, it is well-structured: first paragraph covers core behavior, second covers idempotency, third gives agent formatting instructions. Every sentence adds value. Minor room for tightening.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of an auth flow with background polling and idempotency, the description covers all necessary aspects: initiation, non-blocking, polling guidance, idempotency, force restart, and agent instructions. Output schema exists, so return values are specified elsewhere. The description is complete for correct tool usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 2 parameters with 0% description coverage. The description fully explains profile (default 'default') and force (cancels and restarts pending session). It adds meaning that the schema alone lacks, such as default values and behavioral effects.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it initiates a Microsoft Identity Device Code login for a profile. It specifies non-blocking behavior, returns user_code and verification_url, and contrasts with sp_auth_status for polling. The verb 'Initiate' and resource 'Microsoft Identity Device Code login' are specific and distinct 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.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says when to use this tool (to begin login) and when to use sp_auth_status (poll for status). It covers idempotency: existing pending session is returned unless force=True, which cancels and restarts. It also instructs the agent to present the code in a fenced block and URL as a plain link.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

sp_auth_statusA

Read-onlyIdempotent

Return the current sign-in state for profile (default 'default'). Three states the agent can act on directly:

'signed_in' — valid token on disk (regardless of how it got there: CLI login, prior tool-flow, or just refreshed silently). signed_in_user_upn populated. The agent can proceed.
'pending' — Device Code flow in progress. user_code, verification_url, time_remaining_s populated.
'none' — no token, no flow. Agent should call sp_auth_begin.

Recently-terminal sessions (expired / failed / cancelled) surface their error via the error field instead of falling back to 'none' — so the agent can render a specific failure message.

AGENT_INSTRUCTIONS: When status='pending', present the verification code to the user inside a fenced code block (so it can be copied with one click) and present the verification URL as a plain markdown link on its own line. Do not paraphrase, do not embed the code inside prose, do not wrap the URL in bold. Same format as sp_auth_begin.

ParametersJSON Schema

Name	Required	Description	Default
`profile`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and idempotentHint. The description adds context about terminal states (expired/failed/cancelled) surfacing errors via the `error` field, which is beyond annotation information. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the main purpose, then details states and agent instructions. It is slightly verbose but well-structured and each sentence serves a purpose. Could be trimmed slightly without losing value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema (implied), the description adequately covers the return states and their implications for agent action. It provides sufficient context for a tool with one optional parameter.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It explains the 'profile' parameter and its default value, but does not provide allowed values or further syntax details. This adds some meaning but leaves gaps.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that it returns the current sign-in state for a profile, with specific states explained. It distinguishes itself from sibling tool sp_auth_begin by indicating when to use that tool instead.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit instructions for each state, including agent instructions for presenting the pending verification code. It references sp_auth_begin for the 'none' state, but does not elaborate on other alternatives or when not to use this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

sp_drive_change_trackA

Read-only

Return items in a SharePoint site's default drive that changed since the optional since cursor — Microsoft Graph delta query. First call (since=None) returns the full item set + an initial cursor. Subsequent calls with the cursor return only created/modified/deleted items since that cursor. Result: {items: [...], cursor: str}. The cursor is opaque — store it (the agent typically puts it in conversation memory or a scratchpad) and pass it back as since. A stale cursor surfaces as a 410 Gone error; drop it and call again with since=None for a full re-sync. Read-only.

ParametersJSON Schema

Name	Required	Description	Default
`since`	No
`scope_url`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnlyHint annotation, it explains cursor behavior, opaque nature, staleness error, and read-only guarantee. Full transparency without contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with purpose and uses three sentences covering all key aspects efficiently. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema presence, the description explains the return structure for both call types. Covers error handling and data flow adequately.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The `since` parameter is thoroughly explained (optional, default None, cursor semantics). The `scope_url` parameter is implied but not explicitly defined, leaving a minor gap given 0% schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns items changed in a SharePoint site's default drive using a delta query cursor. It distinguishes itself from siblings by its unique delta/change-tracking function.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit guidance: first call with since=None, subsequent calls with cursor, and handling of stale cursor (410 Gone → full re-sync). No ambiguity about when to use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

sp_drive_checkout_listA

Read-onlyIdempotent

List the files this MCP profile currently has checked out (acquired via sp_drive_file_checkout). Returns each entry's original path, when checkout happened, and the local working-copy path. Read-only. With verify=True, additionally queries SharePoint to confirm the server-side lock state (server_locked + lock_holder fields); costs one Graph call per registry entry. Default verify=False is sub-second, registry-only — sp_drive_file_checkin's ETag round-trip catches divergence at write time.

ParametersJSON Schema

Name	Required	Description	Default
`verify`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds behavioral details: the default operation is sub-second registry-only, verify=True incurs Graph calls and adds server_locked/lock_holder fields, and that check-in handles divergence at write time. It fully discloses the behavior beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise (3-4 sentences), front-loaded with the core purpose, and each sentence adds value without redundancy. It balances completeness with brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (1 optional param, no required params) and presence of an output schema, the description covers all necessary aspects: what it does, return values, performance trade-offs, and relationship to other tools (sp_drive_file_checkout, sp_drive_file_checkin). It is fully complete for an AI agent to use correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has one optional boolean parameter 'verify' with default false and no description. The tool description fully explains its effect (triggers server-side lock check, adds fields, costs a Graph call), performance implications, and tie-in with check-in. This adds significant meaning beyond the schema schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'List the files this MCP profile currently has checked out' (verb+resource), mentions the origin (via sp_drive_file_checkout), and distinguishes from siblings by focusing on checked-out files. It also defines what is returned (original path, checkout time, local working-copy path).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance: default verify=False is fast (registry-only), while verify=True queries SharePoint at a cost. It explains when to use each mode and references sp_drive_file_checkin's ETag mechanism, implying when not to use verify. This is clear, though it does not explicitly list alternative tools for other scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

sp_drive_file_historyA

Read-onlyIdempotent

List a SharePoint file's version history. Returns up to limit versions newest-first, each with id (use with sp_drive_file_version_get), last_modified, last_modified_by (display name or email), and size. Read-only. NOTE: per-version comments aren't currently exposed via Microsoft Graph v1.0 — they land in SharePoint's web UI version history but not in this response shape.

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes
`limit`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses read-only nature, field details, ordering, and the limitation about per-version comments. Adds significant value beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Concise, front-loaded with purpose, then provides essential details without fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers all necessary aspects for a simple read-only list tool, including response shape and limitations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Explains 'limit' parameter and default, and mentions 'url' implicitly. With 0% schema description coverage, provides useful context but could clarify URL format.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states 'List a SharePoint file's version history' with specific verb and resource. Distinguishes from sibling tools like sp_drive_file_version_get.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies usage with sp_drive_file_version_get, providing context for chaining. Does not explicitly state when not to use, but gives enough guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

sp_drive_file_readA

Read-onlyIdempotent

Download a SharePoint file's content to a local temp file. Returns the absolute path of the temp file with the original extension preserved. Read-only — does NOT acquire a checkout/lock; use sp_drive_file_checkout for that. url is the file's human-readable web URL (e.g. from sp_search_query hits). The LLM consumes the file via filesystem tools (Read, Bash) — no base64 round-trip.

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses no checkout/lock, local temp file with path returned, and no base64 round-trip. Adds significant context beyond annotations which already indicate read-only.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, no unnecessary words, all content earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given one parameter, rich annotations, and output schema, description covers purpose, usage, behavior, and output format completely.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Adds meaning to the 'url' parameter by describing it as human-readable web URL from search query, compensating for 0% schema description coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states downloading a SharePoint file to a local temp file, preserves extension, and distinguishes from checkout tool. Verb and resource are specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says read-only and to use sp_drive_file_checkout for checkout. Specifies URL format from sp_search_query and how LLM consumes the file.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

sp_drive_file_version_getA

Read-onlyIdempotent

Download a specific historical version of a SharePoint file to a local temp file. Returns the absolute path. Use sp_drive_file_history first to find the version_id you want. Read-only — does NOT acquire a checkout, does NOT modify SharePoint state.

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes
`version_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide readOnlyHint and idempotentHint, but the description adds important behavioral context: 'does NOT acquire a checkout, does NOT modify SharePoint state' and mentions saving to a local temp file. No contradictions with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Very concise: two sentences, no fluff, front-loaded with the primary action. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple 2-parameter read-only tool with an output schema, the description provides enough context: return value (absolute path), prerequisite step, and read-only guarantee. Minor omission: no error handling or format details, but acceptable given simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description should explain parameters. It only indirectly clarifies version_id by referencing sp_drive_file_history, but does not explain 'url' (expected format or scope) or provide any syntax details. This is insufficient.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the verb 'Download', the resource 'historical version of a SharePoint file', and the outcome 'Returns the absolute path'. It also implicitly distinguishes from sibling tools like sp_drive_file_history (which finds version_id) and sp_drive_file_read (reads current version).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly instructs to 'Use sp_drive_file_history first to find the version_id you want', providing a clear prerequisite. Also states the read-only nature, setting expectations for when to use this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

sp_drive_folder_listA

Read-onlyIdempotent

List the immediate children of a SharePoint or OneDrive folder. url is the folder's human-readable web URL (e.g. from a previous sp_search_query hit's web_url, or the SharePoint web UI). Returns each child with name, type ('folder' or 'file'), size, last-modified date, and webUrl. Read-only — does not modify SharePoint state.

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes
`limit`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description explicitly states 'Read-only — does not modify SharePoint state,' which aligns with the readOnlyHint and idempotentHint annotations. It also details the returned fields (name, type, size, last-modified, webUrl) and specifies 'immediate children' (not recursive), providing behavioral depth beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, no wasted words. It front-loads the purpose, then explains parameter usage and return details efficiently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given two parameters, zero schema coverage, and an existing output schema, the description covers the key aspects: purpose, input format, behavior (read-only, immediate children), and output fields. The omission of `limit` is a minor gap, but overall satisfactorily complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The `url` parameter is well-described with guidance on provenance and format, but the `limit` parameter (with default 100) is not mentioned. With zero schema description coverage, the description partially compensates but leaves the agent to infer limit's purpose.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'List the immediate children of a SharePoint or OneDrive folder,' using a specific verb (list) and resource (immediate children of a folder). This distinguishes it from sibling tools that operate on different resources or perform different actions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains what the `url` parameter expects (human-readable web URL from previous search or UI) and that it returns immediate children only. While it doesn't explicitly state when not to use this tool or compare to alternatives, the context is clear enough for most agents.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

sp_list_column_listA

Read-onlyIdempotent

Return the column definitions (schema) of a SharePoint List. Each column: id, display_name, name (internal), description, required, hidden, read_only, indexed, type (text/choice/number/boolean/datetime/person/lookup/calculated/hyperlink/currency). list_url shape: https:///sites//Lists/. Read-only.

ParametersJSON Schema

Name	Required	Description	Default
`list_url`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide readOnlyHint, idempotentHint. Description adds 'Read-only' and output field details, but no additional behavioral traits beyond what annotations convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with purpose. No extraneous information. Efficient and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With output schema present, description does not need to explain return values. It covers input pattern and output fields. Could mention authentication context, but not critical. Generally complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so description must compensate. It gives the URL pattern but does not fully describe the parameter's meaning or constraints beyond the name. The parameter name is self-explanatory, but more detail could help.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it returns column definitions/schema of a SharePoint List. Lists specific fields and provides URL pattern, distinguishing it from siblings like sp_list_list and sp_list_item_list.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear context for when to use (to get schema) but does not explicitly mention when not to use or compare with alternatives. However, purpose is self-explanatory.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

sp_list_item_getA

Read-onlyIdempotent

Fetch a single SharePoint List item by id with all expanded fields. Returns id, created_date_time, last_modified_date_time, created_by, last_modified_by, web_url, fields (dict). list_url shape: https:///sites//Lists/. Read-only.

ParametersJSON Schema

Name	Required	Description	Default
`item_id`	Yes
`list_url`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds value beyond annotations by listing exact return fields and specifying the list_url format; consistent with readOnlyHint and idempotentHint.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no unnecessary words; front-loaded with action and return info, then URL format and read-only note.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read tool with output schema, description covers all needed: action, return fields, URL format, and safety hint.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Explains list_url format, which is helpful, but item_id only implied in text; schema has no descriptions, so description partially compensates.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states 'Fetch a single SharePoint List item by id', which is specific and directly distinguishes it from sibling 'sp_list_item_list' which lists items.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implicitly conveys usage for retrieving one item by ID, but does not explicitly contrast with alternatives or provide when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

sp_list_item_listA

Read-onlyIdempotent

List items in a SharePoint List with their full fields expanded. filter is an optional OData $filter expression (e.g. "fields/Status eq 'Open'"). top caps results (default 100, max 5000 per Graph). list_url shape: https:///sites//Lists/. Read-only.

ParametersJSON Schema

Name	Required	Description	Default
`top`	No
`filter`	No
`list_url`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds that items are returned with 'full fields expanded' and notes the top limit (max 5000), providing some behavioral context beyond annotations but not elaborating on response structure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The three-sentence description is front-loaded with the main purpose, then provides parameter guidance and a read-only note. Every sentence adds value with no redundancy or fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (3 parameters, existing output schema), the description adequately covers parameters and behavior. It could mention authentication expectations or error scenarios, but the essential information for agent invocation is present.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description compensates fully: it explains filter as an optional OData expression with example, top as capping results (default 100, max 5000), and list_url shape. Each parameter's meaning is clarified.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'List items in a SharePoint List with their full fields expanded,' specifying the resource and action. It does not explicitly differentiate from sibling tools like sp_list_item_get or sp_list_list, but the purpose is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides parameter usage details (OData filter syntax, top cap, list_url shape) and marks the tool as read-only, but does not explicitly state when to use this tool versus alternatives or when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

sp_list_listA

Read-onlyIdempotent

List all SharePoint Lists on a site (Issue Trackers, Tasks, Custom Lists, etc.). Returns each list's id, name, display_name, web_url, description, created_date_time, last_modified_date_time, and template (e.g. 'genericList', 'documentLibrary', 'tasks'). Read-only.

ParametersJSON Schema

Name	Required	Description	Default
`site_url`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide readOnlyHint=true and idempotentHint=true; the description adds explicit 'Read-only' and details on return fields, which is consistent and adds value.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with purpose and return information, no unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With low complexity (one param, read-only) and an output schema present, the description fully covers the return fields and purpose, making it complete for tool selection and invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The only parameter (site_url) has no description in the schema (0% coverage), and the tool description only implies its role via 'on a site'. No format or examples provided, so partial compensation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'List all SharePoint Lists on a site' and specifies the return fields (id, name, display_name, etc.). It distinguishes from sibling tools like sp_list_column_list or sp_list_item_list by focusing on the list-level overview.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for enumerating lists on a site, but does not explicitly state when not to use or suggest alternatives among siblings (e.g., sp_list_column_list for columns).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

sp_search_queryA

Read-onlyIdempotent

Search SharePoint document libraries the signed-in user has access to. Returns matching files with name, path, webUrl, last-modified date, and author. Read-only. Filter args: site (URL), folder (path), file_type (extension like 'docx'), modified_after (ISO date). SCOPE: currently driveItem-only (files in document libraries). Searching List items or sites by content is not yet supported — use sp_list_item_list with an OData filter for List-item lookup, sp_site_list for site discovery.

ParametersJSON Schema

Name	Required	Description	Default
`site`	No
`limit`	No
`query`	Yes
`folder`	No
`file_type`	No
`modified_after`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.8/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and idempotentHint. The description adds return fields and scope limitations (driveItem-only), which is valuable context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences plus a scope note. Front-loaded with main purpose. Every sentence adds value with no waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given moderate complexity (6 params) and presence of output schema, the description covers scope, filters, limitations, and alternatives thoroughly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 0% description coverage, but the description explains each filter parameter: site (URL), folder (path), file_type (extension), modified_after (ISO date), and mentions limit default. This fully compensates for the schema gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it searches SharePoint document libraries for files and returns metadata. It distinguishes from siblings by specifying scope (driveItem-only) and mentioning alternatives for lists and sites.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly tells when to use (searching files in doc libraries) and when not to use (lists/sites), with clear alternatives: sp_list_item_list and sp_site_list.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

sp_share_link_listA

Read-onlyIdempotent

List existing sharing links on a SharePoint file or folder. Each entry: id (use with sp_share_link_revoke), web_url (the share URL), type (view/edit/embed/blocksDownload), scope (organization/anonymous/users), roles, expiration, has_password. Read-only — does not create or revoke. Use sp_share_link_create to make a new link, sp_share_link_revoke to remove one. SCOPE: only sharing-link permissions. For ALL access grants (direct user/group assignments, inherited site permissions, plus sharing links) use sp_share_permission_list instead.

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.7/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and idempotentHint=true. The description reinforces read-only behavior ('Does not create or revoke') and adds scope context (only sharing-link permissions). No contradictions. Additional information about what the tool does not do adds transparency beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three concise sentences. First sentence states purpose and fields. Second sentence clarifies read-only nature. Third sentence provides usage alternatives. No redundant words; every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (1 parameter, list operation, read-only) and the presence of an output schema (not shown but implied), the description fully covers purpose, behavior, parameter meaning, and usage guidance. No gaps for effective invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% (parameter description empty). The description explains the 'url' parameter as the SharePoint file or folder URL, adding critical meaning. While it doesn't specify format or validation rules, it provides enough context for agent to understand the parameter's purpose.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists existing sharing links on a SharePoint file or folder, enumerates the fields of each entry, and differentiates from siblings by naming specific alternatives (sp_share_link_create, sp_share_link_revoke, sp_share_permission_list).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit when-to-use (list sharing links) and when-not-to-use (for creation, revocation, or broader permission listing) with direct references to sibling tools. Also clarifies scope limitation to sharing links only.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

sp_share_permission_listA

Read-onlyIdempotent

List who has access to a SharePoint file, folder, or site. Pass a site URL for site-level permissions or any item URL (file or folder) for that item's permissions. Returns each permission entry with id, roles (read/write/owner), grantee ({type, display_name, email, link_type, link_scope}), and inherited flag. Read-only — does not modify any permission state. Use this to answer 'who can see/edit this?' before suggesting changes or sharing links. SCOPE: all permission grants — direct user/group assignments, inherited site permissions, AND sharing links. To list only sharing links (and get their id for sp_share_link_revoke), use sp_share_link_list instead.

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description reinforces the read-only nature indicated by annotations, and adds detail on the scope of permissions included (direct assignments, inherited, sharing links). No contradictions with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, front-loaded with the purpose, and every sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the single parameter, existing output schema, and clear scope explanation, the description is complete. It covers usage, return fields, and scope, leaving no ambiguity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description fully compensates by explaining how to use the url parameter: pass a site URL for site-level permissions or any item URL for item-level permissions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists permissions for SharePoint files, folders, or sites, and specifies the returned fields. It explicitly distinguishes from the sibling tool sp_share_link_list, which lists only sharing links.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use this tool ('before suggesting changes or sharing links') and when to use an alternative (use sp_share_link_list for sharing links only).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

sp_site_drive_listA

Read-onlyIdempotent

List all document libraries (drives) on a SharePoint site — default Shared Documents plus Site Assets, Style Library, and any custom libraries. site_url is the site's web URL. Returns each drive's id, name, web_url, description, drive_type, and quota. Most sp_drive_* tools accept URLs into any library transparently — sp_site_drive_list is the discovery step when the agent doesn't know which libraries exist yet.

ParametersJSON Schema

Name	Required	Description	Default
`site_url`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide readOnlyHint=true and idempotentHint=true. The description adds valuable behavior: it lists returned fields (id, name, web_url, description, drive_type, quota) and notes interoperability with other sp_drive_* tools.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no wasted words. The first sentence states purpose, the second explains the parameter and return in a logical, front-loaded way.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple listing operation and presence of output schema, the description covers purpose, parameter, return, and usage scenario with sibling tools. No obvious gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 1 parameter with 0% coverage. The description explains 'site_url is the site's web URL', adding meaning beyond the schema's type and required fields.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'List' and resource 'document libraries (drives)'. It specifies the site's web URL as input and lists the return fields. It distinguishes this tool as the discovery step when library URLs are unknown.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states this is the discovery step when the agent doesn't know which libraries exist, implying when to use. It does not explicitly state when not to use, but the context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

sp_site_followed_listA

Read-onlyIdempotent

List sites the signed-in user has marked as Followed in SharePoint. Useful 'my SharePoint' entry point for an agent starting from the user's curated list rather than guessing site URLs. Not available in service-principal auth mode (no signed-in user) — falls back to a clear error there. Read-only.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds important auth limitation (not available in service-principal mode) and confirms read-only nature beyond what annotations provide. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three concise sentences, front-loaded with the main action. Every sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a parameterless list tool with output schema, the description covers purpose, usage context, auth limitation, and safety, making it complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters, so description does not need to add parameter details. Baseline 4 applies; the description implicitly covers the user context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states 'List sites the signed-in user has marked as Followed' with specific verb and resource. It distinguishes from guessing site URLs and positions itself as a curated entry point, differentiating from siblings like sp_site_list or sp_search_query.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says it's useful as a 'my SharePoint' entry point and notes unavailability in service-principal auth mode. While it does not name alternative tools directly, the context is clear about when to use this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

sp_site_listA

Read-onlyIdempotent

Discover SharePoint sites the signed-in user has access to. query is a free-text site-name search (e.g. 'finance'); omit / leave empty to list all visible sites. Returns each site's id, name, web_url, description, last_modified. Read-only. Use as the entry point when the agent doesn't yet know which site URL to drill into.

ParametersJSON Schema

Name	Required	Description	Default
`query`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds 'Read-only' and lists return fields, which is consistent but does not significantly add beyond the annotations. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with three sentences, each providing essential information. Front-loaded with purpose, then parameter details, then usage positioning. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is complete for a discovery tool with one optional parameter. It explains what the tool does, how to use the parameter, what it returns, and its role among siblings. Output schema exists, so return values need not be detailed beyond listing fields.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the description fully explains the query parameter: free-text search with example, and default behavior when omitted. This adds significant meaning beyond the schema's basic type definition.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool discovers SharePoint sites the user has access to, with a specific verb 'Discover' and resource 'SharePoint sites'. It distinguishes from sibling tools by positioning itself as the entry point when the agent doesn't know the site URL.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear usage context: use when the agent doesn't know the site URL. It explains how to use the query parameter for search or leave empty to list all. While it doesn't explicitly state when not to use, 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.

sp_site_page_listA

Read-onlyIdempotent

List all modern SharePoint Pages (Site Pages) on a site. Returns each page's id, name (filename), title, web_url, description, page_layout, thumbnail_web_url, last_modified, last_modified_by. Read-only.

ParametersJSON Schema

Name	Required	Description	Default
`site_url`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide readOnlyHint=true. The description adds 'Read-only' and lists specific return fields, providing additional context beyond annotations. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with purpose and return fields. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple list tool with readOnly and idempotent annotations and an output schema, the description is sufficient. It covers purpose, return fields, and safety. Could mention that it returns all pages without pagination.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description does not explain the site_url parameter beyond its schema title. However, the context 'on a site' indicates the parameter's purpose. With 0% schema description coverage, the description provides minimal additional meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'List' and the resource 'modern SharePoint Pages (Site Pages)'. It distinguishes from sibling tools like sp_site_page_read which reads a single page.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly indicates this tool is for listing pages, but does not explicitly state when to use alternatives like sp_site_page_read. However, the context of listing vs. single read is implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

sp_site_page_readA

Read-onlyIdempotent

Fetch a single SharePoint Page including its canvasLayout (sections, columns, web parts) as JSON. page_url shape: https:///sites//SitePages/.aspx. Read-only.

ParametersJSON Schema

Name	Required	Description	Default
`page_url`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint, idempotentHint, and openWorldHint false. The description adds that the operation is read-only and returns JSON with canvasLayout, providing useful context beyond annotations. However, it does not disclose error handling or rate limits, which is acceptable given the low complexity.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with two sentences. The first sentence defines the core functionality, and the second adds a critical usage hint (URL format). No unnecessary words or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has only one parameter, annotations covering safety, and an output schema (implied by 'as JSON'), the description is largely complete. It could be slightly improved by mentioning what happens on error or specifying that the return includes web parts, but overall it sufficiently covers the tool's purpose.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter page_url has 0% schema description coverage, so the description fully compensates by providing a concrete URL shape: 'https://<host>/sites/<name>/SitePages/<page>.aspx'. This adds significant meaning beyond the schema's simple string type.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool fetches a single SharePoint Page including canvasLayout as JSON. It specifies the verb 'Fetch' and the resource 'a single SharePoint Page', and distinguishes from sibling tools like sp_site_page_list by focusing on a single page with detailed content.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for retrieving a single page's content by providing a URL format, but does not explicitly state when to use this tool versus alternatives like sp_site_page_list or sp_search_query. No guidance on exclusion criteria or prerequisites is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

sp_site_trash_listA

Read-onlyIdempotent

List items in the SharePoint site's recycle bin. Returns each item's id, name, size, deleted_date_time, deleted_from_location (original folder), and deleted_by (display name). Read-only. NOTE: Microsoft Graph does not expose a restore action at site scope; items currently have to be restored via the SharePoint web UI. This tool uses Graph's /beta endpoint — the site-level recycle-bin API has not yet been promoted to v1.0. Schema may shift; we'll migrate when v1.0 lands.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`site_url`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark it as read-only and idempotent. The description adds behavioral detail: it's read-only, cannot restore items, uses the /beta endpoint, and warns about schema instability. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise (4 sentences) and front-loaded: purpose first, then return fields, then behavioral notes. Every sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

All relevant aspects are covered: purpose, return fields, read-only nature, restore limitation, beta API usage, and schema migration note. Output schema exists, so return field details are optional but still provided. The description is complete for this tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% (no parameter info in description). The description does not explain the 'site_url' or 'limit' parameters beyond what the schema provides. For a 2-parameter tool, more guidance (e.g., site URL format, limit default behavior) would help.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('List items'), the resource ('SharePoint site's recycle bin'), and the scope. It distinguishes from sibling list tools by focusing on trash/recycle bin.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides clear usage context (reading recycle bin items) and notes important limitations (no restore via Graph, beta endpoint). It lacks explicit when-not-to-use or alternative tools, but the limitation notes serve as indirect guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

21 tool updatesv0.7.0Jul 6, 2026
- First observedsp_auth_begin
- First observedsp_auth_status
- First observedsp_drive_change_track
- First observedsp_drive_checkout_list
- First observedsp_drive_file_history
- First observedsp_drive_file_read
- First observedsp_drive_file_version_get
- First observedsp_drive_folder_list
- First observedsp_list_column_list
- First observedsp_list_item_get
- First observedsp_list_item_list
- First observedsp_list_list
- First observedsp_search_query
- First observedsp_share_link_list
- First observedsp_share_permission_list
- First observedsp_site_drive_list
- First observedsp_site_followed_list
- First observedsp_site_list
- First observedsp_site_page_list
- First observedsp_site_page_read
- First observedsp_site_trash_list

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.3/5.0

Disambiguation5/5

All 21 tools have clearly distinct purposes, covering authentication, drives, lists, sites, search, sharing, permissions, pages, and trash. Even related tools like sp_drive_file_read, sp_drive_file_checkout, sp_drive_file_history, and sp_drive_file_version_get are differentiated by their specific actions.

Naming Consistency5/5

All tools follow a consistent sp_{resource}_{action} pattern in snake_case (e.g., sp_auth_begin, sp_drive_folder_list, sp_site_trash_list). The naming is predictable and easily understood.

Tool Count5/5

With 21 tools, the set is well-scoped for the SharePoint domain. It covers authentication, multiple resource types (files, lists, sites, pages), and additional utilities like search, sharing, and permissions without being overwhelming or too sparse.

Completeness2/5

The tool surface is heavily read-only. Missing write operations include creating/updating/deleting files (e.g., sp_drive_file_checkin), list items, sites, sharing links, and pages. While the descriptions hint at some missing tools (e.g., sp_share_link_create), they are not implemented, leaving significant gaps for agent workflows.

Maintenance

ActivityMaintained

ResponsivenessUnresponsive

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Artificial Wit AIOAuth
com.artificialwit
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
ERP Systems CRM Knowledge & Memory
2
anotherai
dev.anotherai
MCP server for building and testing AI agents with multi-model experimentation and insights.
Agent Orchestration Autonomous Agents Testing & QA Tools
2
ClawLinkOAuth
dev.claw-link
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
App Automation Workplace & Productivity
24
BoxOAuth
com.box.mcp
The Box MCP server is a secure gateway that connects external AI agents to enterprise content stored in Box, enabling agent-based document access, advanced search, and multi-file analysis while preserving Box security policies. It provides capabilities including keyword search, Box AI-powered Q&A across files, metadata extraction, file management, and authentication, all validated against Box's granular permission controls. The server integrates with major AI platforms like Anthropic Claude, Microsoft Copilot Studio, and Mistral Le Chat, and is available both as a Box-hosted remote server and a self-hosted open-source Python project.
Cloud Storage File Systems Search
2

Related MCP Servers

SharePoint MCP Server
File Systems Content Management Systems
Sofias-ai
A
license
B
quality
Not graded
maintenance
A lightweight MCP server that enables integration with Microsoft SharePoint, allowing clients to interact with documents and folders through the Model Context Protocol.
Updated 10 months ago (2025-11-15 10:37 UTC)
9
65
-
m365-mcp-server
Workplace & Productivity Cloud Platforms Communication
SwamiRama
A
license
Not graded
quality
A
maintenance
A production-ready MCP server that provides secure, delegated access to Microsoft 365 services including Email, SharePoint, OneDrive, and Calendar. It enables AI models to search messages, browse files, manage calendar events, and parse document contents using OAuth 2.1 authentication.
Updated 2 months ago (2026-07-20 19:37 UTC)
MIT
sharepoint-mcp
Cloud Storage Search Content Management Systems
ravikant1918
A
license
A
quality
F
maintenance
A production-grade Model Context Protocol (MCP) server for Microsoft SharePoint that connects AI agents to read files, manage folders, and reason over organizational knowledge.
Updated 6 months ago (2026-03-15 11:30 UTC)
14
12
MIT
sharepoint-mcp
Content Management Systems File Systems Search
DEmodoriGatsuO
F
license
Not graded
quality
D
maintenance
A Model Context Protocol server that connects AI assistants to SharePoint via Microsoft Graph API, enabling natural language queries for documents, lists, and site management.
Updated 5 months ago (2026-04-14 01:28 UTC)
82
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/XMV-Solutions-GmbH/sharepoint-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

mcp-server-sharepoint

What is this for?

Installation

Quickstart

1. Sign in once (out of band)

2. Wire it into Claude Code

3. Enable writes (when you're ready)

3a. Restrict the tool surface (optional)

4. Try it

What it can do, in detail

Read tools (always available)

Non-default libraries

Write tools (opt-in via SP_ALLOW_WRITES=true)

Recycle bin: list-only, beta endpoint

Large files

Authentication

Login from an MCP client (recommended for AI-mediated workflows)

Manual fallback: CLI

Service-principal mode (unattended automation)

Security model

Roadmap

Multi-profile pattern

BYO Entra app registration

Token storage

Troubleshooting

"No usable credentials"

"Cannot checkout: file is already checked out by another user"

"File changed under us between sp_drive_file_checkout and sp_drive_file_checkin"

Linux: keyring fails / "Secret Service unavailable"

Recovery after a crash

Development

Renewing the harness token

Contributing

Licence

Contact

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

Write tools (opt-in via `SP_ALLOW_WRITES=true`)