Skip to main content
Glama
Sign In
sam2kb

m365-mcp

by sam2kb
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

m365_files_create_folder

Create a single OneDrive folder at the root or under an existing parent path; use it when the parent already exists, not for nested paths or file uploads.

Instructions

Create one folder in your OneDrive root or an existing parentPath. This does not upload files or create missing parent folders. Returns the new folder's ID, name and web URL. Check m365_files_list before retrying a creation whose outcome is uncertain.

Input Schema

NameRequiredDescriptionDefault
nameYesName of the single folder to create, not a nested path
parentPathNoExisting root-relative parent path, e.g. Documents/Work; defaults to root

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.2.1
    • changedInput schema / properties / name / description
      Previous value: -"Folder name"New value: +"Name of the single folder to create, not a nested path"
    • changedInput schema / properties / parentPath / description
      Previous value: -"Parent folder path (default: root)"New value: +"Existing root-relative parent path, e.g. Documents/Work; defaults to root"
  2. First observedv1.0.7

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnly=false, idempotent=false, destructive=false and openWorld=true, so the safety profile is covered. The description adds genuinely non-redundant context: no recursive parent creation, the returned fields (ID, name, web URL), and a recovery path for ambiguous outcomes — which matters precisely because idempotentHint=false.

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?

Four short sentences, each carrying distinct information: capability, exclusions, return shape, retry advice. Capability and scope are front-loaded with zero filler.

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 two-parameter, non-destructive creation tool with no output schema, the description covers capability, negative scope, return values, and failure-recovery behavior. Nothing an agent needs in order to call it or handle its result is missing.

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 100% and both parameters already document that name is a single folder (not a nested path) and that parentPath is a root-relative existing path defaulting to root. The description restates this constraint but adds no syntax, validation, or format detail beyond the schema, so the baseline 3 applies.

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?

Specific verb (create) plus resource (one folder) plus scope (OneDrive root or an existing parentPath). It immediately separates itself from the file siblings (m365_files_list, m365_files_read, m365_files_info, m365_files_search) which do not create anything.

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 states what it does NOT do — no file uploads, no creation of missing parent folders — and names m365_files_list as the check before retrying an uncertain creation. That is real routing guidance, though it stops short of covering other edge cases (e.g. duplicate-name handling).

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

Deploy Server

Other Tools