Microsoft 365 MCP Server

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

With annotations declaring readOnlyHint=true and destructiveHint=false, the safety profile is covered. However, the description adds no behavioral context regarding the OData query capabilities (filter, expand, select), pagination behavior (top/skip/fetchAllPages), or what occurs if the notebookId is invalid. Fails to disclose that this supports complex querying despite having 12 parameters.

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?

Extremely concise at 9 words. Front-loaded with the core action. No redundancy. However, for a tool with 12 parameters supporting complex OData operations, this brevity may be insufficient rather than optimally concise—it leaves significant gaps that force the agent to infer behavior from parameter names alone.

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?

Given high schema richness (100% coverage, 12 params) and annotations covering safety hints, the description provides the minimum viable context: what object is returned and the required parent resource (notebook). However, it omits guidance on the query pattern (OData), pagination strategy, and relationships between parameters like top/skip vs fetchAllPages.

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?

Input schema has 100% description coverage (top, skip, search, filter, etc. all documented), establishing baseline 3. The description mentions none of these parameters specifically and doesn't add semantic meaning beyond what the schema provides (e.g., doesn't explain that 'search' queries section names or that 'expand' retrieves related entities).

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?

Clearly states the action (Retrieve) and resource (onenoteSection objects) with scope (from the specified notebook). Uses API terminology 'onenoteSection' which distinguishes it from sibling tools like list-onenote-notebooks (notebooks vs sections) and list-onenote-section-pages (pages vs sections), though it doesn't explicitly name those alternatives.

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?

Provides no guidance on when to use this tool versus alternatives (e.g., when to use standard query parameters vs simply fetching all), nor does it mention prerequisites like needing a valid notebookId from list-onenote-notebooks. Single sentence offers no contextual hints.

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