Skip to main content
Glama
JonEricDelaCruz

onenote-mcp

by JonEricDelaCruz
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Get page content

getPage
Read-only

Read a OneNote page by title or ID and get its content as readable text, including tables, image captions, and PDF text. Optionally return raw HTML.

Instructions

Read one page. Returns readable text including tables (as Markdown), image captions, and the text of any attached PDFs. Pass format="html" for raw XHTML. If the result mentions an image or attachment whose text is unavailable, say so rather than treating the page as complete.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageYesPage TITLE (e.g. "AI Search") or ID. Titles are matched case-insensitively; if several pages share one you get the list back to choose from. You do NOT need to look up an ID first.
formatNo"text" for readable Markdown-ish text (default), "html" for raw OneNote XHTML.
sectionNoOptional: narrow to one section when several pages share a title.
maxImagesNoHow many images to attach. Defaults to 2, because images are expensive: a screenshot costs roughly 1,300-4,000 tokens, often more than the page text. The result says how many more exist; raise this only when the user needs them.
maxLengthNoTruncate content to this many characters. Defaults to 12000, which covers almost every real page. Raise it only if a page is reported as truncated and you need the rest.
includeIdsNoInclude OneNote element IDs, required for later PATCH operations.
includeImagesNoAttach the page images so you can READ them yourself, which is how text inside a screenshot becomes available at all (Microsoft does not expose its OCR). LEAVE THIS UNSET normally: images cost 1,300-4,000 tokens each, so by default they are only sent when a page has too little text to answer from, and merely announced otherwise. Set true when the user asks to see them, or when the answer is plainly inside a picture. Set false to skip them entirely.
readAttachmentsNoDownload embedded files and include their text. On by default. PDFs with a text layer are read in full; scanned PDFs and other file types are named but not opened. Set false to skip the download and read only the page itself.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv2.1.1
    • addedInput schema / properties / includeImages
      Added value: +{
+  "description": "Attach the page images so you can READ them yourself, which is how text inside a screenshot becomes available at all (Microsoft does not expose its OCR). LEAVE THIS UNSET normally: images cost 1,300-4,000 tokens each, so by default they are only sent when a page has too little text to answer from, and merely announced otherwise. Set true when the user asks to see them, or when the answer is plainly inside a picture. Set false to skip them entirely.",
+  "type": "boolean"
+}
    • addedInput schema / properties / maxImages
      Added value: +{
+  "description": "How many images to attach. Defaults to 2, because images are expensive: a screenshot costs roughly 1,300-4,000 tokens, often more than the page text. The result says how many more exist; raise this only when the user needs them.",
+  "maximum": 10,
+  "minimum": 1,
+  "type": "integer"
+}
    • addedInput schema / properties / page
      Added value: +{
+  "description": "Page TITLE (e.g. \"AI Search\") or ID. Titles are matched case-insensitively; if several pages share one you get the list back to choose from. You do NOT need to look up an ID first.",
+  "minLength": 1,
+  "type": "string"
+}
    • removedInput schema / properties / pageId
      Removed value: -{
-  "description": "Page ID from listPages or searchPages.",
-  "minLength": 1,
-  "type": "string"
-}
    • addedInput schema / properties / readAttachments
      Added value: +{
+  "description": "Download embedded files and include their text. On by default. PDFs with a text layer are read in full; scanned PDFs and other file types are named but not opened. Set false to skip the download and read only the page itself.",
+  "type": "boolean"
+}
    • addedInput schema / properties / section
      Added value: +{
+  "description": "Optional: narrow to one section when several pages share a title.",
+  "minLength": 1,
+  "type": "string"
+}
    • changedInput schema / required
      Previous value: -[
-  "pageId"
-]New value: +[
+  "page"
+]
  2. First observedv2.0.0

TDQS

A4.4/5.0
Behavior5/5

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

The readOnlyHint annotation already signals safety, and the description adds meaningful behavioral context beyond it: the readable-text composition, PDF handling, raw XHTML option, and the explicit instruction to acknowledge missing image/attachment text instead of presenting an incomplete page as complete. This genuinely helps the agent act correctly.

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 sentences, each earning its place: the purpose, the return content, the format switch, and a behavioral caveat. It is front-loaded with the core action and avoids redundant restating of the name or title.

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

Completeness4/5

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

For an 8-parameter tool with no output schema, the description covers the essential return semantics and key behavioral caveats, while the rich input schema fills in parameters like maxImages, maxLength, includeIds, and readAttachments. It is complete enough for correct invocation, though naming sibling alternatives would make selection even safer.

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%, so the baseline is 3; all eight parameters are thoroughly documented in the schema itself. The main description only adds format='html', which is useful but not a significant semantic contribution beyond the schema.

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?

The description states a precise verb and resource: 'Read one page.' It then enumerates what the response contains — readable text, Markdown tables, image captions, and attached PDF text — which clearly differentiates it from list-style siblings like listPages and getOutline. The format option is also explicitly called out.

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?

The description gives clear context: use this when you need the content of a single page, and it explains format variants and how to handle unavailable image/attachment text. It does not explicitly name sibling alternatives or state when not to use it, so it stops short of full when/when-not guidance.

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