mcp-server-sharepoint

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.7.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.
Average 4.5/5 across 21 of 21 tools scored. Lowest: 3.9/5.
See the Tool Scores section below for per-tool breakdowns.
- 66 of 67 community issues answered or closed in the last 6 months
- 10 commits in the last 12 weeks
- Last stable release on May 20, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![sharepoint-mcp MCP server](https://glama.ai/mcp/servers/XMV-Solutions-GmbH/sharepoint-mcp/badges/card.svg)](https://glama.ai/mcp/servers/XMV-Solutions-GmbH/sharepoint-mcp)

Score Badge

Copy to your README.md:

[![sharepoint-mcp MCP server](https://glama.ai/mcp/servers/XMV-Solutions-GmbH/sharepoint-mcp/badges/score.svg)](https://glama.ai/mcp/servers/XMV-Solutions-GmbH/sharepoint-mcp)

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