Find Microsoft 365 files in SharePoint and OneDrive by query and file type. Retrieve content directly through the provided resource link for any matching file.
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}
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| file_type | No | all | |
| max_results | No |
Changes observed during successful MCP inspections.
v0.1.0Does 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.
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.
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.
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.
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.
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.