Skip to main content
Glama
bscott

NotePlan MCP Server

by bscott

NotePlan MCP Server

A Message Control Protocol (MCP) server that enables Claude Desktop to interact with NotePlan.co. This server provides seamless integration between Claude and your NotePlan notes, allowing you to query, search, create, and update notes directly from Claude conversations.

Features

  • Read Notes: Get all notes, specific notes by ID, or notes from specific folders

  • Search: Full-text search across all your notes

  • Create Notes: Create new notes with titles, content, and folder organization

  • Daily Notes: Create and manage daily notes with automatic date formatting

  • Update Notes: Modify existing note titles and content

  • Folder Organization: Organize and filter notes by folders

Related MCP server: Notes MCP

Installation

Option 1: Clone from GitHub

git clone https://github.com/bscott/noteplan-mcp.git
cd noteplan-mcp
npm install

Option 2: Install as NPM Package (Coming Soon)

npm install -g noteplan-mcp

Quick Start

  1. Install dependencies:

    npm install
  2. Build the project:

    npm run build
  3. Test the server:

    npm start

    You should see: "NotePlan MCP server running on stdio"

  4. Configure Claude Desktop (see detailed setup below)

Claude Desktop Configuration

To use this MCP server with Claude Desktop, add the following configuration to your Claude Desktop config file:

Step 1: Locate Your Config File

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json Windows: %APPDATA%\Claude\claude_desktop_config.json Linux: ~/.config/Claude/claude_desktop_config.json

Step 2: Add NotePlan MCP Server

Add this configuration to your claude_desktop_config.json:

{
  "mcpServers": {
    "noteplan": {
      "command": "node",
      "args": ["/absolute/path/to/noteplan-mcp/build/index.js"],
      "cwd": "/absolute/path/to/noteplan-mcp"
    }
  }
}

Important: Replace /absolute/path/to/noteplan-mcp with the actual path where you cloned this repository.

Step 3: Restart Claude Desktop

After saving the configuration, restart Claude Desktop completely for the changes to take effect.

Available Tools

Once configured, you can use these tools in Claude conversations:

Tool

Description

Parameters

get_notes

Get all notes from NotePlan

None

get_note_by_id

Get a specific note by ID

id (required)

search_notes

Search notes by query

query (required)

get_notes_by_folder

Get notes from a folder

folder (required)

create_note

Create a new note

title (required), content, folder

create_daily_note

Create a daily note

date (YYYY-MM-DD), content

update_note

Update existing note

id (required), title, content

Example Usage in Claude

Once set up, you can ask Claude things like:

  • "Show me all my notes"

  • "Search for notes containing 'project planning'"

  • "Create a new note titled 'Meeting Notes' in the 'Work' folder"

  • "Get today's daily note"

  • "Update note ID 'note123' with new content"

Claude will automatically use the appropriate NotePlan MCP tools to fulfill these requests.

Development

Development Mode

npm run dev

This builds the TypeScript and starts the server with auto-restart on file changes using nodemon.

Building

npm run build

Compiles TypeScript to JavaScript in the build/ directory.

Testing

npm test

Linting

npm run lint

Project Structure

noteplan-mcp/
├── src/
│   ├── index.ts               # Main MCP server implementation
│   ├── index.js               # HTTP server (alternative)
│   └── services/
│       └── noteService.ts     # Note management logic
├── build/                     # Compiled JavaScript output
│   ├── index.js               # Compiled MCP server
│   └── services/
│       └── noteService.js     # Compiled note service
├── tests/
│   └── index.test.js          # Test files
├── tsconfig.json              # TypeScript configuration
├── package.json
└── README.md

Troubleshooting

Claude Desktop Not Connecting

  1. Check file paths: Ensure the paths in claude_desktop_config.json are absolute and correct

  2. Check Node.js: Make sure Node.js is installed and accessible from your PATH

  3. Check logs: Look for error messages in Claude Desktop's logs:

    • macOS: ~/Library/Logs/Claude/mcp-server-noteplan.log

    • Windows: %LOCALAPPDATA%\Claude\Logs\mcp-server-noteplan.log

Common Error Messages

"Cannot find module '/src/mcp-server.js'"

  • The path in your config is incorrect. Use absolute paths, not relative ones.

"Server disconnected"

  • Check that Node.js is installed and the server can start with npm start

Testing Your Setup

  1. Test the server manually:

    cd /path/to/noteplan-mcp
    npm run build
    npm start
  2. Use the MCP inspector for debugging:

    npm run inspector
  3. Check Claude Desktop logs for connection status

  4. Try a simple command in Claude: "Can you show me my notes?"

Configuration

Custom NotePlan Directory

By default, the server looks for NotePlan files in standard locations. If you use a custom directory, you can modify the noteService.js file to point to your NotePlan data directory.

Environment Variables

Currently, no environment variables are required, but future versions may support:

  • NOTEPLAN_DATA_DIR: Custom NotePlan data directory

  • MCP_LOG_LEVEL: Logging verbosity

Contributing

  1. Fork the repository

  2. Create a feature branch: git checkout -b my-new-feature

  3. Make your changes and add tests

  4. Run the test suite: npm test

  5. Run the linter: npm run lint

  6. Commit your changes: git commit -am 'Add some feature'

  7. Push to the branch: git push origin my-new-feature

  8. Submit a pull request

License

MIT License - see LICENSE file for details.

Support

  • Open an issue on GitHub for bugs or feature requests

  • Check the MCP Documentation for general MCP questions

  • Review Claude Desktop documentation for setup issues

Available Tools

7 tools
create_daily_noteD
ParametersJSON Schema
NameRequiredDescriptionDefault
dateNoThe date for the daily note (YYYY-MM-DD format)
contentNoInitial content for the daily note

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

create_noteD
ParametersJSON Schema
NameRequiredDescriptionDefault
titleYesThe title of the note
contentNoThe content of the note
folderNoThe folder to create the note in

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

get_note_by_idD
ParametersJSON Schema
NameRequiredDescriptionDefault
idYesThe ID of the note to retrieve

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

get_notesD
ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

get_notes_by_folderD
ParametersJSON Schema
NameRequiredDescriptionDefault
folderYesThe folder name to search in

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

search_notesD
ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesThe search query

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

update_noteD
ParametersJSON Schema
NameRequiredDescriptionDefault
idYesThe ID of the note to update
titleNoNew title for the note
contentNoNew content for the note

TDQS

D1/5.0
Behavior1/5

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

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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.

  1. 1 tool updatev1.0.0
    • Changedget_notes1 field changed
      • removedInput schema / additionalProperties
        Removed value: -false
  2. 7 tool updates
    • First observedcreate_daily_note
    • First observedcreate_note
    • First observedget_note_by_id
    • First observedget_notes
    • First observedget_notes_by_folder
    • First observedsearch_notes
    • First observedupdate_note

TDQS

C2.1/5.0
Disambiguation4/5

Most tools have distinct purposes targeting different operations on notes (create, get, search, update). However, 'create_daily_note' and 'create_note' could cause confusion without descriptions to clarify their differences, as they appear to overlap in creating notes.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with snake_case (e.g., create_note, get_notes, update_note). There are no deviations in naming conventions, making the set predictable and readable.

Tool Count5/5

With 7 tools, this server is well-scoped for note management. The count is appropriate, covering core operations without being too sparse or overwhelming, fitting typical MCP server ranges.

Completeness4/5

The tool set provides good coverage for note CRUD operations (create, get, update) and additional utilities like search and folder-based retrieval. A minor gap is the lack of a delete_note tool, which could limit full lifecycle management, but agents can still handle most workflows.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    D
    maintenance
    A Message Control Protocol server that enables Claude Desktop and other applications to interact with Day One journals, allowing automated journal entry creation through a simple API.
    18
    MIT
  • A
    license
    Not graded
    quality
    C
    maintenance
    An MCP server that enables AI assistants like Claude to access and manipulate Apple Notes on macOS, allowing for retrieving, creating, and managing notes through natural language interactions.
    82
    MIT
  • A
    license
    A
    quality
    C
    maintenance
    A Model Context Protocol server that connects Claude Desktop to AI Note task management, enabling task creation, updates and management through natural language conversations.
    5
    52
    MIT
  • A
    license
    Not graded
    quality
    D
    maintenance
    Bidirectional MCP server that connects Claude with an Obsidian vault, enabling note management, full-text search, graph traversal, and daily notes operations.
    4,785
    MIT

Latest Blog Posts

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/bscott/noteplan-mcp'

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