What can you do with this server?

This server enables AI assistants to interact with Microsoft OneNote, providing capabilities to authenticate, manage, search, and create content in notebooks. * Authentication: Initiate Microsoft authentication using the device code flow (no Azure setup required) or save an existing access token. * Notebook Management: List all notebooks and retrieve details for a specific notebook. * Structure Navigation: List sections within a notebook and pages within a section. * Page Content: Retrieve the complete HTML content of a page, including formatting and embedded elements. * Page Creation: Create new pages in a notebook with a title and optional HTML content. * Search: Search for pages across all notebooks using a query string. * Table of Contents: Generate a comprehensive overview (TOC) of all sections and pages in a notebook.

How do I use onenote-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@onenote-mcp list all my notebooks" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

onenote-mcp

by sandraschi

Overview Schema Related Servers Score Discussions

TypeScript

Remote

OneNote MCP Server

📖 Installation Guide — quick start, manual setup, and troubleshooting

A Model Context Protocol (MCP) server implementation that enables AI language models like Claude and other LLMs to interact with Microsoft OneNote.

This project is based on azure-onenote-mcp-server by Zubeid Hendricks, with modifications to simplify authentication and improve usability.

Quick Start

git clone https://github.com/sandraschi/onenote-mcp
cd onenote-mcp
just

This opens an interactive dashboard showing all available commands. Run just bootstrap to install dependencies, then just serve or just dev to start.

Manual Setup

If you don't have just installed:

Related MCP server: OneNote MCP Server

What Does This Do?

This server allows AI assistants to:

Access your OneNote notebooks, sections, and pages
Create new pages in your notebooks
Search through your notes
Read complete note content, including HTML formatting and text
Analyze and summarize your notes directly

All of this happens directly through the AI interface without you having to switch contexts.

Using with AI Assistants

Setup for Cursor

Clone this repository and follow the installation steps below
Install the Python package: uv pip install -e .
Register the server in Cursor:
- Open Cursor preferences (Cmd+, on Mac or Ctrl+, on Windows)
- Go to the "MCP" tab
- Add a new MCP server with these settings:
  - Name: onenote
  - Command: python
  - Args: ["-m", "onenote_mcp.server"]
Here's the complete JSON configuration example:
```
{
  "mcpServers": {
    "onenote": {
      "command": "python",
      "args": ["-m", "onenote_mcp.server"],
      "env": {}
    }
  }
}
```
Restart Cursor
In Cursor, you can now interact with your OneNote data using natural language:

Can you show me my OneNote notebooks?
Create a new page in my first notebook with a summary of this conversation
Find notes related to "project planning" in my OneNote

The first time you ask about OneNote, the AI will guide you through the authentication process.

Setup for Claude Desktop (or other MCP-compatible assistants)

Clone this repository and follow the installation steps below
Install the Python package: uv pip install -e .
In the Claude Desktop settings, add the OneNote MCP server:
- Name: onenote
- Command: python
- Args: ["-m", "onenote_mcp.server"]
JSON configuration example:
```
{
  "mcpServers": {
    "onenote": {
      "command": "python",
      "args": ["-m", "onenote_mcp.server"],
      "env": {}
    }
  }
}
```
You can now ask Claude to interact with your OneNote data

Features

Authentication with Microsoft OneNote using device code flow (no Azure setup needed)
List all notebooks, sections, and pages
Create new pages with HTML content
Read complete page content, including HTML formatting
Extract text content for AI analysis and summaries
Summarize content of all pages in a single operation
Read full content of all pages in a readable format
Search across your notes

Installation

Prerequisites

uv installed (RECOMMENDED)
Python 3.12+

Quick Start

Run immediately via uvx:

uvx onenote-mcp

Claude Desktop Integration

Add to your claude_desktop_config.json:

"mcpServers": {
  "onenote-mcp": {
    "command": "uv",
    "args": ["--directory", "D:/Dev/repos/onenote-mcp", "run", "onenote-mcp"]
  }
}

Prerequisites

Python 3.10 or higher (install from python.org)
pip (Python package installer)
An active Microsoft account with access to OneNote
Git (install from git-scm.com)

Step 1: Clone the Repository

git clone https://github.com/yourusername/onenote-mcp.git
cd onenote-mcp

Step 2: Install Project Dependencies

npm install

This will automatically install the MCP TypeScript SDK from npm (@modelcontextprotocol/sdk).

Step 3: Install the Python Package

uv pip install -e .

Step 4: Start the MCP Server

python -m onenote_mcp.server

This will start the MCP server, and you'll see a message:

Server started successfully.
Use the "authenticate" tool to start the authentication flow,
or use "onenote_save_access_token" if you already have a token.

Step 4: Authenticate Through Your AI Assistant

Once the server is running, you can authenticate directly through your AI assistant:

In Cursor, Anthropic's Claude Desktop, or any MCP-compatible assistant, ask to authenticate with OneNote:
```
Can you authenticate with my OneNote account?
```
The AI will trigger the authentication flow and provide you with:
- A URL (typically microsoft.com/devicelogin)
- A code to enter
Go to the URL, enter the code, and sign in with your Microsoft account
After successful authentication, you can start using OneNote with your AI assistant

Available MCP Tools

Once authenticated, the following tools are available for AI assistants to use:

Tool Name	Description
`authenticate`	Start the Microsoft authentication flow
`onenote_list_notebooks`	Get a list of all your OneNote notebooks
`onenote_get_notebook`	Get details of a specific notebook
`onenote_list_sections`	List all sections in a notebook
`onenote_list_pages`	List all pages in a section
`onenote_get_page`	Get the complete content of a specific page, including HTML formatting
`onenote_create_page`	Create a new page with HTML content
`onenote_search_pages`	Search for pages across your notebooks
`onenote_get_notebookTOC`	Generate a Table of Contents for a notebook (all sections & pages)

Example Interactions

Here are some examples of how you can interact with the OneNote MCP through your AI assistant:

User: Can you show me my OneNote notebooks?
AI: (uses onenote_list_notebooks) I found 3 notebooks: "Work", "Personal", and "Projects"

User: What sections are in my Projects notebook?
AI: (uses onenote_list_sections) Your Projects notebook has the following sections: "Active Projects", "Ideas", and "Completed"

User: Create a new page in Projects with today's date as the title
AI: (uses onenote_create_page) I've created a new page titled "2025-04-12" in your Projects notebook

User: Find all my notes about machine learning
AI: (uses onenote_search_pages) I found 5 pages with content related to machine learning...

User: Can you read and summarize my notes on the "Project Requirements" page?
AI: (uses onenote_get_page) Based on your "Project Requirements" page, here's a summary: The project requires Python 3.8+, integration with AWS services, and completion by Q3. Key deliverables include a web dashboard, API, and documentation...

User: Extract all the action items from my "Team Meeting" notes
AI: (uses onenote_get_page) Here are all the action items from your "Team Meeting" notes:
1. John to complete API documentation by Friday
2. Sarah to schedule design review meeting
3. Team to finalize Q3 roadmap by end of month

User: Summarize content of all my OneNote pages
AI: (runs get-all-page-contents.js) Here's a summary of all your pages:
- Questions: Contains strategic business questions about competitor analysis
- 2025-04-12: Discussion about monetization strategy for bank transfers
- Role Specification: Details about the Chief Payments Officer position
...

User: I want to read through all my OneNote pages so I can ask questions about them
AI: (runs read-all-pages.js) I've retrieved the full content of all your pages in a readable format. Now you can ask me specific questions about any of the content.

User: Generate a table of contents for my Projects notebook
AI: (uses onenote_get_notebookTOC) Here's the TOC for your Projects notebook:

# Projects
> 3 sections, 12 pages

## Active Projects (5 pages)
- **Q1 Planning** *(11/15/2025)*
- **API Design** *(11/20/2025)*
- **Budget Review** *(11/25/2025)*
...

User: Show me a TOC of all my notebooks
AI: (uses onenote_list_notebooks, then onenote_get_notebookTOC for each) Here are all your notebooks with their structure...

Advanced: Direct Script Usage

For testing or development purposes, you can also use the Python module directly:

# Install the package
uv pip install -e .

# Start the MCP server
python -m onenote_mcp.server

# Or run individual functions (for testing)
python -c "from onenote_mcp.server import authenticate_device_code; print('Authenticating...')"

Troubleshooting

Authentication Issues

If authentication fails, make sure you're using a modern browser without tracking prevention
Try clearing browser cookies and cache
If you get "expired_token" errors, restart the authentication process

Server Won't Start

Verify Python is installed (version 3.10+): python --version
Make sure all dependencies are installed: uv pip install -e .
Check that FastMCP is properly installed: python -c "import fastmcp; print(FastMCP 3.1.0__version__)"

AI Can't Connect to the Server

Ensure the MCP server is running (npm start)
Check your AI assistant's settings to make sure it's configured to use MCP
For Cursor, make sure it's the latest version that supports MCP

Security Notes

Authentication tokens are stored locally in .access-token.txt
Tokens grant access to your OneNote data, so keep them secure
Tokens expire after some time, requiring re-authentication
No Azure setup or API keys are required

Credits

This project builds upon the azure-onenote-mcp-server by Zubeid Hendricks, with a focus on simplifying the authentication process and improving the user experience with AI assistants.

🛡️ Industrial Quality Stack

This project adheres to SOTA 14.1 industrial standards for high-fidelity agentic orchestration:

Python (Core): Ruff for linting and formatting. Zero-tolerance for print statements in core handlers (T201).
Webapp (UI): Biome for sub-millisecond linting. Strict noConsoleLog enforcement.
Protocol Compliance: Hardened stdout/stderr isolation to ensure crash-resistant JSON-RPC communication.
Automation: Justfile recipes for all fleet operations (just lint, just fix, just dev).
Security: Automated audits via bandit and safety.

License

This project is licensed under the MIT License - see the LICENSE file for details

Available Tools

10 tools

authenticateA

Start the Microsoft authentication flow using device code.

This tool initiates the OAuth 2.0 device code flow for Microsoft Graph API. The user will be provided with a URL and code to complete authentication in their browser.

Returns: Success message or error details

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.5/5.0

Behavior3/5

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

Describes the OAuth flow, providing URL and code, and mentions return values (success/error). No annotations exist, so description must carry burden. However, it does not disclose side effects (e.g., token storage, session state) which are relevant for agent behavior.

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?

Two paragraphs, front-loaded with purpose. Every sentence adds information. No redundancy.

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?

Tool is simple (0 params, output schema exists). Description covers flow and return values. However, does not mention that this is a prerequisite for other tools, which is important context given sibling list.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters, schema coverage is 100% (empty schema). Baseline 4 as per guidelines. Description adds value by explaining the device code flow, though not needed for parameters.

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?

Description clearly states it starts Microsoft authentication flow using device code for Graph API. Verb 'start' and resource 'authentication flow' are specific. Does not explicitly distinguish from siblings, but siblings are all notebook-related operations, so purpose is distinct.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Description implies usage when authentication is needed (device code flow), but no explicit when-not-to-use or alternatives. Context suggests it's a prerequisite for sibling tools, but not stated.

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

createPageB

Create a new page in a notebook.

ParametersJSON Schema

Name	Required	Description
`title`	Yes	The title of the new page
`content`	No	Optional HTML content for the page
`notebook_id`	Yes	The ID of the notebook to create the page in

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations, the description must disclose behavioral traits. It only states 'create', implying mutation, but fails to mention side effects, required permissions, or error conditions. Minimal transparency.

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?

The description is a single concise sentence with no wasted words. It is front-loaded and clear, earning its place.

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?

Given the tool's simplicity and complete schema plus output schema, the description is minimally adequate. However, it lacks usage context and behavioral details that would benefit an agent.

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 schema already documents all parameters. The description adds no additional meaning beyond the schema, meeting the baseline for high coverage.

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?

The description clearly states the action ('create') and resource ('a new page in a notebook'), distinguishing it from sibling tools that are read-only or list operations. However, it does not explicitly differentiate from alternatives or elaborate on scope.

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?

No guidance is provided on when to use this tool versus alternatives, such as prerequisites (e.g., authentication, existing notebook) or when to avoid using it. The description is purely functional.

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

getNotebookC

Get details of a specific notebook.

ParametersJSON Schema

Name	Required	Description	Default
`notebook_id`	Yes	The ID of the notebook to retrieve

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description carries full burden but fails to disclose behavioral traits such as read-only nature, permissions, or rate limits. The description is too brief to provide meaningful transparency.

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 description is concise with one sentence, but it lacks structure or prioritization of key information. It is appropriately short but could be more informative without being verbose.

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?

Given the simple input (1 param) and presence of an output schema, the description is minimally complete. However, it does not provide any context on the output or typical use cases, leaving room for ambiguity.

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 parameter notebook_id, which already has a clear description. The tool description adds no extra 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?

The description clearly states the verb 'Get' and the resource 'details of a specific notebook', distinguishing it from listing tools like listNotebooks. However, it does not differentiate from similar get tools like getNotebookTOC.

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?

No guidance is provided on when to use this tool versus alternatives. The agent is left to infer that this is for retrieving details of a single notebook, but no context on prerequisites or alternatives is given.

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

getNotebookTOCA

Generate a table of contents for a notebook.

This tool creates a comprehensive overview of all sections and pages in a notebook, useful for navigation and understanding structure.

ParametersJSON Schema

Name	Required	Description	Default
`notebook_id`	Yes	The ID of the notebook

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior4/5

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

No annotations are provided, so the description carries the burden. The description implies a read-only operation (generating an overview) without side effects. However, it does not explicitly state that the tool is non-destructive or read-only, leaving room for interpretation. Still, the intent is clear.

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 description is two sentences and 20 words, concise and front-loaded. Every word adds value, though the second sentence could be slightly tighter. Still, it is efficient and clear.

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?

Given the tool's simplicity (one parameter, output schema exists), the description is adequate. It states the purpose and value. It does not explain the output format, but that is unnecessary due to the presence of an output schema. The description is complete for its complexity.

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% with a single parameter described as "The ID of the notebook." The description adds no additional meaning beyond the schema. Per the rule, baseline 3 is appropriate since the schema already sufficiently documents the parameter.

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 clearly states it generates a table of contents for a notebook, listing sections and pages. This is distinct from sibling tools like listSections or listPages, which provide flat lists. The verb "Generate" and resource "table of contents for a notebook" specify exactly what the tool does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for navigation and understanding structure, but does not explicitly state when to use this tool versus alternatives like listSections or listPages. No exclusionary guidance or prerequisites are provided, leaving the agent to infer context.

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

getPageA

Get the complete content of a specific page.

This tool retrieves the full HTML content of a OneNote page, including all text, formatting, and embedded elements.

ParametersJSON Schema

Name	Required	Description	Default
`page_id`	Yes	The ID of the page to retrieve

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/5.0

Behavior2/5

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

Without annotations, the description should disclose behavioral traits. It only states what is retrieved, not side effects, permissions, or that it's read-only. No mention of potential large responses or rate limits.

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?

Two sentences with no wasted words. First sentence states the purpose, second adds detail. Perfectly front-loaded and concise.

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 simple retrieval tool with a single parameter and an output schema present, the description adequately covers what the tool does. No missing information needed for agent invocation.

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%, so baseline is 3. The description does not add extra meaning for the page_id parameter beyond what the schema already provides.

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 clearly states the tool retrieves the full HTML content of a OneNote page, including text, formatting, and embedded elements. This distinguishes it from sibling tools like listPages (page metadata) and searchPages (search results).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage context is implied but not explicit. The description does not contrast with alternatives (e.g., listPages for metadata) or state when not to use this tool. No exclusions or prerequisites are mentioned.

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

listNotebooksA

Get a list of all your OneNote notebooks.

Returns: Formatted list of notebooks with IDs and display names

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It discloses that it returns a formatted list with IDs and display names, indicating read-only behavior and return format. However, it does not mention authentication requirements or pagination.

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?

The description is extremely concise, front-loaded with the purpose, and includes a brief note on return format. Every sentence adds value with no redundancy.

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 a simple zero-parameter tool with an output schema, the description is reasonably complete, stating what it does and what it returns. However, it could mention authentication or scope ('all your') implying user context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are zero parameters, and the schema coverage is 100% (trivially). The description adds no parameter info, which is appropriate since there are none. Baseline for 0 parameters is 4.

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 clearly states the verb 'Get a list' and resource 'OneNote notebooks', and the tool name listNotebooks distinguishes itself from siblings like listSections (lists sections) and getNotebook (gets a single notebook).

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 does not provide any guidance on when to use this tool versus alternatives like getNotebook or listSections, nor does it mention prerequisites or context.

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

listPagesB

List all pages in a section.

ParametersJSON Schema

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

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations provided, the description solely informs about the action but does not disclose behavioral traits such as read-only nature, authentication needs, pagination, or any side effects.

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 description is extremely concise (5 words) and front-loaded, but could benefit from a brief note on output or usage context without losing conciseness.

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?

Given the tool's simplicity, an output schema exists, so return values are covered. However, the description omits important context like authentication requirements or potential pagination, leaving the agent partially uninformed.

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?

The schema covers 100% of parameter descriptions. The description adds no extra semantic value beyond the schema; it merely restates the purpose without enriching parameter understanding.

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 'List all pages in a section' clearly states the action (list) and resource (pages in a section), distinguishing it from sibling tools like listSections (lists sections) and getPage (gets a single page).

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 provides no guidance on when to use this tool versus alternatives like searchPages or getPage. It lacks explicit context about prerequisites or exclusion cases.

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

listSectionsA

List all sections in a notebook.

ParametersJSON Schema

Name	Required	Description	Default
`notebook_id`	Yes	The ID of the notebook

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.6/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 burden. 'List' implies a read operation, but the description does not explicitly state that it is non-destructive, safe, or requires specific permissions.

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?

The description is a single, front-loaded sentence with no unnecessary words. It efficiently communicates the tool's purpose.

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?

Given the simple one-parameter tool and the existence of an output schema, the description covers the essential purpose. It might lack detail on whether sections are returned flat or hierarchically, but overall sufficient.

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% with one parameter (notebook_id) already described in the schema. The description adds no additional semantics or usage details for the parameter beyond what the schema provides.

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?

The description clearly states 'List all sections in a notebook,' specifying the action and resource. It distinguishes from sibling tools like listNotebooks and listPages, but lacks detail on scope (e.g., recursive sections).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the tool name and description: use when you need sections. However, no explicit guidance on when to use or not use compared to alternatives, nor prerequisites like authentication.

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

saveAccessTokenA

Save an access token for later use.

ParametersJSON Schema

Name	Required	Description	Default
`token`	Yes	The Microsoft Graph access token to save

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It does not disclose how the token is saved (e.g., persistence, lifetime, scope), nor any side effects or permission requirements.

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?

The description is a single, front-loaded sentence with no unnecessary words. Every word serves a purpose.

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?

While the tool has an output schema (not shown), the description omits return value details, error cases, and behavioral context. For a simple save operation, it is minimally adequate but could provide more.

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%, with a clear description for the token parameter. The tool description adds no extra meaning beyond the schema, earning a baseline score of 3.

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 clearly states the tool saves an access token for later use, with a specific verb and resource. It distinguishes itself from sibling tools like authenticate (which obtains tokens) and the notebook/page tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is used after obtaining a token (e.g., via authenticate), but provides no explicit when-to-use or when-not-to-use guidance, nor mentions alternatives.

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

searchPagesB

Search for pages across all notebooks.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Search query string

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, and the description fails to disclose behavioral traits such as read-only nature, search behavior (e.g., case sensitivity, wildcards), or pagination.

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?

The description is a single, clear sentence with no wasted words, perfectly sized for the simple tool.

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?

Given the tool's simplicity (one parameter, output schema exists), the description is minimal but functional. Missing details like search behavior or result format, though output schema covers return structure.

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?

With 100% schema coverage, the description adds no extra meaning beyond the schema; 'Search query string' is already in the schema. Adequate but no added value.

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 explicitly states the action 'Search for pages' and the scope 'across all notebooks', clearly differentiating from sibling tools like listPages and getPage.

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?

No guidance is given on when to use this tool versus siblings like listPages or getPage, nor any context about appropriate use cases.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

10 tool updatesv1.0.0Jul 28, 2026
- First observedauthenticate
- First observedcreatePage
- First observedgetNotebook
- First observedgetNotebookTOC
- First observedgetPage
- First observedlistNotebooks
- First observedlistPages
- First observedlistSections
- First observedsaveAccessToken
- First observedsearchPages

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.0

Disambiguation5/5

Each tool targets a distinct resource or action: authentication, token storage, listing notebooks, getting notebook details, listing sections, listing pages, getting page content, creating pages, searching pages, and generating a table of contents. There is no overlap in functionality.

Naming Consistency4/5

Most tools follow a verb_noun pattern (e.g., listNotebooks, getPage, createPage). However, 'authenticate' is verb-only and 'saveAccessToken' uses a different structure, breaking full consistency.

Tool Count5/5

Ten tools is well-scoped for a OneNote MCP server. It covers essential operations like authentication, listing, reading, creating, and searching without being excessive.

Completeness3/5

The tool surface covers core read operations and page creation, but lacks update and delete for pages and sections, as well as section creation. This leaves gaps for full lifecycle management.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

cortexpad A
com.cortexpad
Google Keep-style notes app with an MCP server for AI agents to read/write notes.
Note Taking Knowledge & Memory
162
hjarni AOAuth
com.hjarni
Markdown-based note-taking with a hosted MCP server. Your notes serve you and your AI.
Note Taking Workplace & Productivity
3
OneSchema MCP Server
co.oneschema
MCP server that lets AI assistants use all OneSchema features exposed via the public API.
Data Platforms App Automation
1
ClawLinkOAuth
dev.claw-link
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
App Automation Workplace & Productivity
24

Related MCP Servers

OneNote MCP Server
Browser Automation Note Taking Web Scraping
hwillGIT
F
license
Not graded
quality
Not graded
maintenance
An MCP server that enables AI assistants to programmatically browse and interact with OneNote notebooks shared via web links through browser automation.
Updated a year ago (2025-03-24 21:29 UTC)
25
4
-
OneNote MCP Server
Note Taking Content Management Systems
danosb
A
license
Not graded
quality
D
maintenance
A Model Context Protocol server that enables AI language models like Claude to interact with Microsoft OneNote, allowing access to notebooks, creating pages, searching notes, and analyzing content directly through the AI interface.
Updated a year ago (2025-04-12 09:27 UTC)
43
119
MIT
OneNote MCP Server
Note Taking Workplace & Productivity
noelroehrig
A
license
Not graded
quality
C
maintenance
A local MCP server that lets AI assistants read and edit OneNote pages on Windows via COM automation, without cloud authentication.
Updated 2 months ago (2026-07-13 12:55 UTC)
1
MIT
onenote_mcp_server
Note Taking Workplace & Productivity
ItsikBin
A
license
A
quality
C
maintenance
MCP server that connects AI tools to Microsoft OneNote for Business via the Microsoft Graph API, enabling listing, creating, and updating notebooks, sections, and pages.
Updated a month ago (2026-08-01 18:03 UTC)
6
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/sandraschi/onenote-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server