onenote-mcp

onenote_list_pages

List all pages in a OneNote section with numbered titles plus created and modified dates, so you can review every page's details at a glance.

Instructions

List all pages in a OneNote section.

Return Format

Markdown string: "📄 Pages in section:" with numbered pages, created and modified dates.

Examples

onenote_list_pages(section_id="0-SEC123...")

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "section_id": "<section_id>"
    },
    "name": "onenote_list_pages"
  }
}

Input Schema

Name	Required	Description	Default
`section_id`	Yes	The ID of the section

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.0.4Sep 29, 2026

TDQS

B3.2/5.0

Behavior3/5

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

No annotations are provided, so the description carries full behavioral burden. It does describe the return shape (numbered pages with created/modified dates), which is useful, but says nothing about pagination limits, behavior on an invalid or empty section, or whether this is a pure read. Some value added, key traits undisclosed.

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?

The purpose sentence is front-loaded and terse, and the example is compact. The Return Format block is somewhat redundant given an output schema exists, but it is short and the overall structure is easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the return-format section is largely redundant, and the description omits what matters for a listing tool: result limits, pagination, and ordering. It is adequate to call the tool correctly but leaves meaningful operational questions unanswered.

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 100% for the single section_id parameter, so the schema already does the documenting; baseline 3 applies. The example value '0-SEC123...' adds a mild hint about ID format, but no new semantic meaning beyond the schema.

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?

States a specific verb and resource with scope: 'List all pages in a OneNote section.' An agent can tell this lists pages rather than sections or notebooks. However, it never distinguishes itself from siblings like onenote_search_pages or onenote_get_page, which overlap on the same resource.

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 when-to-use guidance, no prerequisites (e.g. must the section be indexed or authenticated first?), and names no alternatives. The presence of onenote_search_pages as a sibling makes the missing routing guidance a real gap, since an agent must guess between listing and searching.

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