SharePoint MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, but 'Upload_Document' and 'Upload_Document_From_Path' could cause confusion as they both handle document uploads with only a slight difference in source specification. The other tools clearly target different operations like creation, deletion, listing, and updating.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with underscores, such as 'Create_Folder', 'Delete_Document', and 'List_SharePoint_Documents'. This uniformity makes the set predictable and easy to navigate for an agent.
Tool Count5/5
With 9 tools, the server is well-scoped for managing SharePoint documents and folders. It covers essential operations without being overly complex, making it appropriate for typical file management tasks in this domain.
Completeness4/5
The toolset provides strong coverage for document and folder management, including CRUD operations like create, read, update, and delete. A minor gap is the lack of a tool for moving or renaming items, which might require workarounds, but core workflows are well-supported.
Average 2.9/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Delete' implies a destructive, irreversible mutation, but the description doesn't state whether this requires specific permissions, what happens on success/failure, if there's a confirmation step, or any rate limits. For a destructive tool with zero annotation coverage, this is a significant gap in transparency.
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 a single, efficient sentence that states the core purpose without unnecessary words. It is appropriately sized and front-loaded, with every word earning its place. No structural issues or redundancy are present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature, 2 parameters with 0% schema coverage, no annotations, and no output schema, the description is incomplete. It lacks critical context like behavioral traits, parameter details, error handling, and output expectations. For a deletion tool, this minimal description poses risks for correct agent invocation.
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 description coverage is 0%, so the schema provides no parameter descriptions. The description mentions 'document' and 'SharePoint directory', which loosely maps to file_name and folder_name, but adds no details on format (e.g., case sensitivity, path structure), constraints, or examples. With 2 undocumented parameters, the description fails to compensate for the coverage gap.
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 the action ('Delete') and resource ('a document from a SharePoint directory'), making the purpose immediately understandable. It distinguishes from siblings like Delete_Folder by specifying 'document' rather than 'folder', though it doesn't explicitly contrast them. The description is specific but lacks explicit sibling differentiation for a full score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., document must exist), exclusions (e.g., cannot delete system files), or when to choose other tools like Update_Document or Delete_Folder. Without any usage context, the agent must infer when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves content, implying a read-only operation, but doesn't specify details like authentication requirements, rate limits, error handling, or output format (e.g., text, binary). This leaves significant gaps in understanding how the tool behaves beyond its basic purpose.
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 a single, clear sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to scan and understand quickly. Every word earns its place by conveying essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a document retrieval tool with no annotations, 0% schema coverage, and no output schema, the description is incomplete. It lacks details on parameters, behavioral traits (e.g., permissions, errors), and expected output, making it inadequate for the agent to use the tool effectively without additional context or trial-and-error.
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?
The schema description coverage is 0%, meaning parameters are undocumented in the schema. The description adds no information about the parameters (file_name and folder_name), such as their purpose, format (e.g., paths, names), or constraints. It fails to compensate for the lack of schema documentation, leaving parameters ambiguous.
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 the action ('Get content') and resource ('document in SharePoint'), which is specific and unambiguous. However, it doesn't differentiate from potential siblings like 'List_SharePoint_Documents' or 'Update_Document', which might also involve document content in some way, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a document to exist), exclusions (e.g., not for editing), or compare to siblings like 'List_SharePoint_Documents' for browsing or 'Update_Document' for modifications, leaving the agent to infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but only states the basic operation. It doesn't mention whether this is a read-only operation, what permissions are required, how results are returned (pagination, format), rate limits, or error conditions. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
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 a single, clear sentence that efficiently communicates the core functionality without unnecessary words. It's appropriately sized for a simple list operation and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, 0% schema description coverage, and no output schema, the description is insufficiently complete. A list operation typically needs information about result format, pagination, sorting, filtering options, and error handling - none of which are addressed. The description only covers the most basic 'what' without the 'how' or 'what to expect.'
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 for the single parameter 'folder_name', the description adds no semantic information about what this parameter represents, valid formats, examples, or constraints. The schema only provides a title 'Folder Name' with no description, so the tool definition lacks essential parameter documentation.
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 the action ('List all documents') and resource ('in a specified SharePoint folder'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'List_SharePoint_Folders' or 'Get_Document_Content', which would require more specific scope clarification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'List_SharePoint_Folders' for folders or 'Get_Document_Content' for document details. There's no mention of prerequisites, limitations, or appropriate contexts for selecting this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool updates documents but fails to mention critical aspects like required permissions, whether the update overwrites or merges content, error handling, or any rate limits. This leaves significant gaps in understanding the tool's behavior.
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 a single, straightforward sentence with no wasted words. It is appropriately sized and front-loaded, clearly stating the tool's purpose without unnecessary elaboration, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a document update operation, no annotations, no output schema, and 0% schema coverage, the description is inadequate. It lacks details on parameters, behavior, error cases, and output, making it incomplete for effective tool invocation by an AI agent.
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 description coverage is 0%, so the description must compensate for undocumented parameters. It mentions no parameters at all, failing to explain the meaning of 'content', 'file_name', 'folder_name', or 'is_base64'. This leaves all four parameters semantically unclear beyond their titles.
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 the action ('Update') and resource ('an existing document in a SharePoint directory'), making the purpose immediately understandable. However, it doesn't distinguish this tool from its sibling 'Upload_Document', which might also modify documents, leaving room for ambiguity in sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'Upload_Document' or 'Delete_Document'. It lacks context about prerequisites (e.g., document must exist), exclusions, or comparisons to sibling tools, offering minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('Upload a new file') but lacks details on permissions required, file size limits, error handling, or whether the operation is idempotent. For a mutation tool with zero annotation coverage, this leaves critical behavioral traits unspecified, though it doesn't contradict any 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 a single, efficient sentence that front-loads the core action and resource. Every word earns its place without redundancy, making it easy to parse quickly. There's no wasted text or unnecessary elaboration, which is ideal for tool selection.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation operation with 4 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like authentication needs, error cases, or return values, nor does it fully explain parameter usage. For a file upload tool in a SharePoint context, more detail is warranted to ensure correct invocation.
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 description coverage is 0%, so the description must compensate for undocumented parameters. It mentions uploading 'a new file to a SharePoint directory', which implies 'folder_name' and 'file_name', but doesn't explain 'content' (e.g., text or binary data) or 'is_base64' (e.g., encoding format). With 4 parameters and no schema descriptions, the description adds minimal semantic value beyond basic inference.
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 the action ('Upload') and resource ('a new file to a SharePoint directory'), making the purpose immediately understandable. It distinguishes from siblings like 'Create_Folder' or 'Delete_Document' by specifying file upload rather than folder creation or deletion. However, it doesn't explicitly differentiate from 'Upload_Document_From_Path', which handles uploads from a file path instead of content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites like authentication, compare with 'Upload_Document_From_Path' for path-based uploads, or indicate scenarios like handling large files or specific SharePoint permissions. Without such context, users must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the basic operation. It doesn't disclose behavioral traits such as required permissions, file size limits, overwrite behavior, error handling, or response format, leaving significant gaps for a mutation tool.
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 a single, efficient sentence with zero waste, clearly front-loaded with the core action. It's appropriately sized for the tool's scope without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a file upload operation, no annotations, no output schema, and low schema coverage, the description is incomplete. It lacks details on behavior, parameters, and outcomes, making it inadequate for safe and effective use by an AI agent.
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 description coverage is 0%, so the description must compensate but adds no parameter details. It doesn't explain what 'file_path', 'folder_name', or 'new_file_name' mean, their formats, or constraints, failing to address the undocumented parameters.
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 the action ('Upload a file') and target resource ('to SharePoint') with a specific method ('directly from a file path'). It distinguishes from the sibling 'Upload_Document' by specifying the source method, though not explicitly contrasting them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'Upload_Document' or other siblings. The description implies usage for file uploads from local paths but lacks explicit context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a mutation ('Create'), but lacks details on permissions required, error conditions (e.g., duplicate names), or what happens on success (e.g., returns a folder ID). For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
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 a single, efficient sentence that front-loads the core action ('Create a new folder') and adds necessary context ('in the specified directory or root if not specified'). There is zero waste, and every word earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a mutation tool with 2 parameters), no annotations, no output schema, and low schema coverage, the description is incomplete. It lacks information on return values, error handling, prerequisites (e.g., authentication), and detailed parameter usage. For a tool that creates resources, this leaves critical gaps for an AI agent.
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 adds meaning by explaining that 'parent_folder' defaults to root if not specified, which clarifies the optional parameter's behavior. However, it doesn't detail 'folder_name' constraints (e.g., length, invalid characters) or format for 'parent_folder' (e.g., path string). This provides some value but doesn't fully cover the parameters.
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 the verb ('Create') and resource ('new folder'), specifying the action and target. It distinguishes from siblings like Delete_Folder or List_SharePoint_Folders by focusing on creation. However, it doesn't explicitly differentiate from Upload_Document, which might also create items, so it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides basic context by mentioning 'specified directory or root if not specified,' but offers no guidance on when to use this tool versus alternatives like Upload_Document for files or List_SharePoint_Folders for checking existing folders. There are no explicit when/when-not instructions or named alternatives, leaving usage decisions unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the folder must be empty, which is a critical constraint, but fails to address permissions, irreversibility, error handling, or response format. For a destructive operation, this is a significant gap in transparency.
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 a single, efficient sentence with zero waste—it states the action, resource, and key constraint directly. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature, lack of annotations, no output schema, and 0% schema coverage, the description is incomplete. It misses critical details like permissions, error cases, and return values, which are essential for safe and effective use in a SharePoint context.
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, but it adds no parameter details beyond what's implied by the tool name. The single parameter 'folder_path' is undocumented in both schema and description, leaving its format and semantics unclear. Baseline 3 is given as it minimally meets expectations without adding value.
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 the action ('Delete') and resource ('an empty folder from SharePoint'), making the purpose immediately understandable. It distinguishes from siblings like Delete_Document by specifying folder deletion, though it doesn't explicitly contrast with all alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance—it specifies the folder must be empty, but offers no explicit when-to-use rules, prerequisites, or comparisons to alternatives like Delete_Document. This leaves the agent with insufficient context for optimal tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the action ('List folders') and default behavior ('root if not specified'), but fails to describe critical aspects such as pagination, sorting, filtering, error handling, or authentication requirements. For a list operation with no annotation coverage, this leaves significant gaps in understanding how the tool behaves.
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 a single, efficient sentence that front-loads the core action ('List folders') and includes essential details (location and default). There is no wasted verbiage, making it appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (listing folders in a SharePoint context), no annotations, no output schema, and low schema coverage, the description is incomplete. It lacks information on return values (e.g., structure of folder list), error cases, permissions, or integration with sibling tools, leaving the agent with insufficient context for reliable use.
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 adds some meaning by explaining that the parameter specifies a 'SharePoint directory' and defaults to 'root if not specified', which clarifies the optional nature and purpose of 'parent_folder'. However, with 0% schema description coverage and only 1 parameter, this provides basic context but doesn't fully compensate for the lack of schema details (e.g., format of the string).
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 the verb ('List') and resource ('folders in the specified SharePoint directory'), making the purpose understandable. It distinguishes from siblings like List_SharePoint_Documents by specifying folders vs. documents, though it doesn't explicitly mention this distinction. However, it lacks full sibling differentiation (e.g., vs. Get_Document_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 by stating 'root if not specified', suggesting it can be used for both specific directories and the root, but it doesn't provide explicit guidance on when to use this tool over alternatives like List_SharePoint_Documents or other siblings. No when-not-to-use or prerequisite information is included.
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:

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

Score Badge

Copy to your README.md:

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

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/Sofias-ai/mcp-sharepoint'

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