Skip to main content
Glama
godwin3737

Microsoft 365 File Search MCP Server

by godwin3737
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

MCP Server - Microsoft 365 File Search (SharePoint & OneDrive)

Overview

A Model Context Protocol (MCP) server implementation that provides advanced file search capabilities within Microsoft 365. This server enables efficient file discovery, metadata analysis, and integration with business workflows by making available the content from SharePoint/OneDrive.

https://github.com/user-attachments/assets/bbe63c02-f6d9-4c9b-8f98-36fc22a081cc

Related MCP server: SharePoint MCP Server

Components

Tools

The server offers 2 core tools:

  • search_m365_files
    Perform a file search within the M365 environment.
    Input:

    • query (string): The search term or criteria.
      Returns: Array of file metadata objects. Metadata includes the file content summary, drive ID, and file ID, among other details.

  • get_file_content
    Retrieve content from a specific file.
    Input:

    • driveid (string): The unique identifier of the parent drive.

    • fileid (string): The unique identifier of the file.
      Returns: File content as a binary stream.
      Note: Uses a local cache to speed up repeat access.

Caching

To improve performance and reduce redundant API calls, the server caches downloaded files locally. This is particularly useful when working with large documents or frequently accessed files.

  • Cached files are stored in the ./src/mcp_m365_filesearch/.local/downloads directory (relative to the project root).

  • When a file is requested via get_file_content, the server first checks the cache.

  • If the file is already cached, it is returned directly from disk without a new API call.

This feature ensures faster response times and efficient use of API rate limits.

Usage with Claude Desktop

To integrate the server with Claude Desktop, update your claude_desktop_config.json:

"mcpServers": {
  "M365 File Search (SharePoint/OneDrive)": {
    "command": "uv",
    "args": [
      "--directory",
      "full_path_to_parent_directory",
      "run",
      ".\\src\\mcp_m365_filesearch\\server.py"
    ],
    "env": {
      "CLIENT_ID": "MSGraph Client ID",
      "CLIENT_SECRET": "MS Graph Client Secret",
      "TENANT_ID": "TENANT ID",
      "REGION": "SEARCH REGION"
    }
  }
}

Microsoft Graph App Registration

To use this server, you'll need to register an application in the Azure Portal:

  1. Register a new application.

  2. Note down the Client ID and Tenant ID.

  3. Create a Client Secret under Certificates & Secrets.

  4. Under API permissions, add the following delegated or application permissions:

    • Sites.Read.All

    • Files.Read.All

  5. Click Grant admin consent for these permissions.

Ensure these values are correctly set in your env configuration for the MCP server.

License

This project is licensed under the MIT License.
You are free to use, modify, and distribute it with proper attribution.

Available Tools

2 tools
get_file_contentC

Get content of Microsoft 365 file by drive id and file id.

ParametersJSON Schema
NameRequiredDescriptionDefault
fileidYes
driveidYes

TDQS

C2.9/5.0
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, but it merely says 'Get content' without explaining the response format (binary, JSON, plain text), size limits, permission requirements, or error behavior. It implicitly indicates a read operation but leaves the agent without key behavioral context needed to handle the result.

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, front-loaded sentence that names the action and the two identifiers with no filler or redundant wording. It is concise, and every word contributes to the agent's understanding of the tool's purpose and parameters.

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?

Because there is no output schema and no annotations, the description should clarify what 'content' means and how it is returned, but it does not. The tool itself is simple, but the missing return-value semantics and potential limitations make the definition incomplete for an agent to anticipate the response correctly.

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 explicitly mentions 'drive id and file id,' which links both parameters to their roles in identifying the target file, adding a little meaning beyond the bare schema. However, with 0% schema description coverage, the description only minimally compensates and provides no format constraints, examples, or additional semantic detail.

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 'Get' and the resource 'content of Microsoft 365 file,' making the core operation unambiguous. It also identifies the file by drive id and file id, which is specific. However, it does not explicitly distinguish itself from the sibling tool search_m365_files, leaving the differentiation to inference from the verb and the sibling's name.

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 gives no guidance on when to use this tool versus search_m365_files. There are no explicit alternatives, exclusions, or workflow hints. The only implied usage cue is the read-focused verb 'Get' versus the 'search' in the sibling name, which is not sufficient for clear routing.

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

search_m365_filesC
Search Microsoft 365 files by query and file type. If you need content of a file, you can make use of resource microsoft365://{driveid}/{fileid}
ParametersJSON Schema
NameRequiredDescriptionDefault
queryYes
file_typeNoall
max_resultsNo

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are present, so the description carries the full behavioral disclosure burden. It fails to mention whether the operation is read-only, whether authentication or specific permissions are required, how results are returned (metadata only vs. full text snippets), pagination, or rate limits. The resource URI hint is useful but minimal.

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?

Two concise sentences with the core purpose front-loaded. The second sentence is somewhat cryptic due to the unusual microsoft365://{driveid}/{fileid} syntax, but overall the description is compact and non-redundant.

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?

For a search tool with no output schema and no annotations, the description leaves out important execution context: result format, result count behavior, whether search is global or restricted to a drive, and authentication expectations. It is enough to understand intent, but not enough to call reliably without asking for clarification.

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. It does re-express "query" and "file type" as search dimensions, but adds no real semantics beyond the parameter names. The max_results parameter is entirely unaddressed, and no constraints or format details are given for any parameter.

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 first sentence clearly states the action (search), the resource (Microsoft 365 files), and the key filters (query, file type). However, it does not explicitly name the sibling tool get_file_content, relying on an indirect resource URI to distinguish content retrieval from search.

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 provides a partial usage signal by telling the agent that file content should be obtained via microsoft365://{driveid}/{fileid}, which implicitly routes toward the sibling. It does not state when to use this tool versus get_file_content explicitly, nor does it describe exclusions or scope limits.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updatesv0.1.0
    • First observedget_file_content
    • First observedsearch_m365_files
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.4/5.0

Scored across 2 tools

Disambiguation5/5

search_m365_files locates files via query and type, while get_file_content retrieves a specific file's content using drive and file IDs. One is discovery and the other is retrieval, so there is no overlap.

Naming Consistency5/5

Both tool names follow a consistent verb_noun snake_case pattern: search + m365_files and get + file_content. This makes their purposes predictable and consistent.

Tool Count4/5

Two tools is minimal, but it fits the server's search-focused purpose: discover files and fetch their content. It is slightly below the typical well-scoped range, but each tool earns its place.

Completeness4/5

The core workflow is covered: search returns resource identifiers that get_file_content can consume. There is no browse/list/metadata-only operation, but this is a minor gap for a search-oriented server.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches