Which integrations are available for this server?

Manages notes in Markdown format with support for creating, updating, searching, and organizing notes with tags and timestamps.

How do I use Notes MCP Server?

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., "@Notes MCP Server search notes for 'Python project ideas'" 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.

Notes MCP Server

by sayranovv

Overview Schema Related Servers Score Discussions

Python

Local

📝 Notes MCP Server

A Model Context Protocol (MCP) server for managing notes in Markdown format. Built with Python and the FastMCP SDK.

🌟 Features

Create Notes: Create new Markdown notes with titles, content, and tags
List & Filter: View all notes or filter by specific tags
Search: Full-text search across all notes with context preview
Update: Append content to existing notes with timestamps
Delete: Remove notes when no longer needed
Resources: Access all notes as a single MCP resource
AI Prompts: Built-in prompt for analyzing and summarizing notes

Related MCP server: MCP Note-Taking Server

📦 Installation

Prerequisites

Python 3.10 or higher
uv package manager

Install uv

# MacOS/Linux
curl -LsSf https://astral.sh/uv/install.sh | sh

# Windows
powershell -c "irm https://astral.sh/uv/install.ps1 | iex"

# Or via pip
pip install uv

Install Dependencies

# Using uv (recommended)
uv pip install mcp

# Or using pip
pip install mcp

🚀 Quick Start

1. Save the Server

Save notes_server.py in your desired directory.

2. Run the Server

# Using uv (recommended)
uv run notes_server.py

# Or using python directly
python notes_server.py

3. Configure in Claude Desktop

Add to your claude_desktop_config.json:

MacOS: ~/Library/Application Support/Claude/claude_desktop_config.json Windows: %APPDATA%/Claude/claude_desktop_config.json

{
  "mcpServers": {
    "notes": {
      "command": "uv",
      "args": [
        "--directory",
        "/absolute/path/to/notes-mcp-server",
        "run",
        "notes_server.py"
      ]
    }
  }
}

Alternative with Python:

{
  "mcpServers": {
    "notes": {
      "command": "python",
      "args": ["/absolute/path/to/notes_server.py"]
    }
  }
}

4. Restart Claude Desktop

After adding the configuration, restart Claude Desktop to load the MCP server.

🛠️ Available Tools

`create_note`

Create a new note with title, content, and optional tags.

Parameters:

title (string): Note title
content (string): Note content in Markdown
tags (string, optional): Comma-separated tags

Example:

Create a note titled "Project Ideas" with content "1. Build MCP server\n2. Add search" and tags "work, ideas"

`list_notes`

List all notes with their titles and creation dates.

Parameters:

tag (string, optional): Filter by specific tag

Example:

List all notes
List notes with tag "work"

`read_note`

Read the full content of a specific note.

Parameters:

filename (string): The filename of the note (e.g., 20241106_120000_project_ideas.md)

Example:

Read note "20241106_120000_project_ideas.md"

`search_notes`

Search for notes containing specific text.

Parameters:

query (string): Search query

Example:

Search notes for "Python"

`update_note`

Append content to an existing note with timestamp.

Parameters:

filename (string): The filename of the note
content (string): Content to append

Example:

Update note "20241106_120000_project_ideas.md" with "3. Implement testing"

`delete_note`

Delete a note permanently.

Parameters:

filename (string): The filename of the note

Example:

Delete note "20241106_120000_old_note.md"

📚 Resources

`notes://all`

Access all notes as a combined resource. Useful for context-aware operations.

💡 Prompts

`summarize_notes_prompt`

Generates a prompt for AI to analyze all notes and provide:

Summary of main themes
Recurring ideas or patterns
Important action items
Recommendations for organization

📁 File Structure

Notes are stored in the notes/ directory with the following format:

notes/
├── 20241106_120000_project_ideas.md
├── 20241106_130000_shopping_list.md
└── 20241106_140000_python_notes.md

Note Format

Each note is a Markdown file with metadata:

# Project Ideas

**Created:** 2024-11-06 12:00:00
**Tags:** work, ideas

---

1. Build MCP server
2. Add search functionality
3. Implement testing

🧪 Testing

A test script is included to verify functionality without connecting to an LLM:

python test_notes_server.py

The test script will:

Create sample notes
List and filter notes
Search for content
Update and delete notes
Test all features

🔧 Configuration

Notes Directory

By default, notes are stored in ./notes/. To change the location, modify the NOTES_DIR variable in notes_server.py:

NOTES_DIR = os.path.join(os.path.dirname(__file__), "notes")

Filename Generation

Notes are saved with timestamps and sanitized titles:

Format: YYYYMMDD_HHMMSS_sanitized_title.md
Max title length: 100 characters
Special characters are removed
Spaces converted to underscores

📝 Usage Examples

Create a Note

"Create a note titled 'Meeting Notes' with content 'Discussed Q4 goals' and tags 'work, meetings'"

"Search my notes for anything related to 'Python'"

Review Notes by Category

"List all notes tagged with 'personal'"

Summarize Notes

"Use the summarize_notes_prompt to analyze all my notes"

🤝 Contributing

Contributions are welcome! Feel free to:

Report bugs
Suggest new features
Submit pull requests

📄 License

This project is open source and available under the MIT License.

🔗 Resources

⚠️ Limitations

Text-based notes only (no file attachments)
No note encryption
Single notes directory (no subdirectories)
UTF-8 encoding only

💬 Support

For issues or questions:

Check the test script output for debugging
Review the notes directory permissions
Ensure Python 3.10+ is installed
Verify MCP SDK installation

Made with ❤️ using FastMCP

Available Tools

6 tools

create_noteB

Create a new Markdown note

Args: title: Note title content: Note content tags: Optional comma-separated list of tags

Returns: Confirmation message of note creation

ParametersJSON Schema

Name	Required	Description	Default
`title`	Yes
`content`	Yes
`tags`	No

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool creates a note and returns a confirmation message, but it doesn't cover critical aspects like whether this requires specific permissions, if it's idempotent, what happens on duplicate titles, or any rate limits. For a mutation tool with zero annotation coverage, this is inadequate.

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 highly concise and well-structured. It starts with a clear purpose statement, followed by bullet points for arguments and returns, with no wasted words. Every sentence earns its place by providing essential information in a readable format.

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 that there is an output schema (though not provided here), the description doesn't need to detail return values. However, as a mutation tool with no annotations and incomplete behavioral transparency, it should do more to explain side effects or constraints. The parameter semantics are well-covered, but overall completeness is only adequate.

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?

The description adds meaningful context beyond the input schema, which has 0% description coverage. It explains that 'title' is the note title, 'content' is the note content, and 'tags' is an optional comma-separated list. This clarifies the purpose and format of each parameter, compensating well for the schema's lack of descriptions.

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 tool's purpose: 'Create a new Markdown note.' It specifies the verb ('Create') and resource ('Markdown note'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'update_note' or 'delete_note' beyond the creation aspect, which prevents a perfect score.

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. It doesn't mention prerequisites, such as needing authentication or specific contexts, or when not to use it (e.g., for updating existing notes). With sibling tools like 'update_note' and 'delete_note' available, this lack of differentiation is a significant gap.

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

delete_noteC

Delete a note

Args: filename: Note filename

Returns: Confirmation message of deletion

ParametersJSON Schema

Name	Required	Description	Default
`filename`	Yes

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 provided, the description carries the full burden of behavioral disclosure. It states the tool deletes a note and returns a confirmation, but doesn't mention critical aspects like whether deletion is permanent, requires specific permissions, has side effects on related data, or includes error handling for non-existent files. This is inadequate for a destructive operation.

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 appropriately sized and front-loaded with the main action ('Delete a note'), followed by brief sections for Args and Returns. There's no wasted text, though the structure is minimalistic. Every sentence serves a purpose, making it efficient but not richly informative.

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 complexity (destructive operation with no annotations) and the presence of an output schema (which handles return values), the description is partially complete. It covers the basic action and parameter semantics but lacks behavioral context like safety warnings or usage guidelines. For a deletion tool, this is a minimal viable description with clear gaps.

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?

The description adds meaning beyond the input schema, which has 0% description coverage. It explains that 'filename' refers to a 'Note filename', clarifying the parameter's purpose. However, it doesn't provide format details (e.g., file extension, path structure) or examples, leaving some ambiguity. With one parameter and low schema coverage, this is above baseline but not fully comprehensive.

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

Purpose3/5

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

The description states 'Delete a note' which is a clear verb+resource combination, but it doesn't differentiate from sibling tools like 'update_note' or 'create_note' beyond the obvious action. It's a basic statement of function without specificity about scope or constraints.

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 description doesn't mention prerequisites (e.g., note must exist), exclusions, or relationships to siblings like 'list_notes' for verification. It's a bare statement with no contextual usage information.

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

list_notesC

Get a list of all notes

Args: tag: Optional tag filter

Returns: List of notes with titles and dates

ParametersJSON Schema

Name	Required	Description	Default
`tag`	No

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?

No annotations are provided, so the description carries the full burden. It mentions returning a list of notes with titles and dates, but doesn't disclose behavioral traits such as pagination, sorting, permissions needed, or rate limits. For a list operation without annotations, this is inadequate.

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 appropriately sized and front-loaded with the main purpose, followed by structured sections for args and returns. It avoids unnecessary words, though the structure could be more integrated (e.g., combining description with parameter info).

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 low complexity (one optional parameter) and the presence of an output schema (which handles return values), the description is somewhat complete but lacks context on behavior and usage. It covers basics but misses guidance on when to use versus siblings and operational details.

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?

The description adds meaning beyond the input schema by explaining that 'tag' is an 'Optional tag filter', which clarifies its purpose. With 0% schema description coverage and only one parameter, this compensates well, though it could provide more detail on tag format or examples.

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

Purpose3/5

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

The description states 'Get a list of all notes' which clearly indicates the verb (get/list) and resource (notes), but it doesn't differentiate from sibling tools like 'search_notes'. The purpose is understandable but lacks sibling differentiation, making it vague in context.

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 like 'search_notes'. The description mentions an optional tag filter, but it doesn't explain when this tool is appropriate compared to other note-related tools, leaving usage unclear.

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

read_noteC

Read the contents of a note

Args: filename: Note filename (with .md extension)

Returns: Note content

ParametersJSON Schema

Name	Required	Description	Default
`filename`	Yes

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 provided, the description carries the full burden of behavioral disclosure. It states it's a read operation, which implies safety, but doesn't cover potential errors (e.g., if the file doesn't exist), permissions needed, or any side effects. This is a significant gap for a tool with no annotation coverage.

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 front-loaded with the core purpose, followed by structured sections for Args and Returns. It's efficient with minimal waste, though the formatting could be slightly more polished (e.g., using bullet points). Every sentence adds value, earning a high score.

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 low complexity, one parameter, and the presence of an output schema (which handles return values), the description is minimally adequate. However, it lacks details on error handling, permissions, or differentiation from siblings, leaving gaps that could hinder an agent's correct usage in more complex scenarios.

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 description coverage is 0%, but the description adds the parameter 'filename' and specifies it should include '.md extension'. This provides some semantic context beyond the bare schema. However, it doesn't fully compensate for the lack of schema descriptions, such as format constraints or examples, so it meets the baseline.

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 ('Read') and resource ('contents of a note'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'search_notes' or 'list_notes' which also involve reading notes in different ways, so it doesn't reach the highest score.

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 'search_notes' or 'list_notes'. It doesn't mention prerequisites, such as needing the exact filename, or exclusions, leaving the agent to guess the appropriate context for this specific read operation.

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

search_notesC

Search for text within notes

Args: query: Search query

Returns: List of notes containing the query

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes

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?

No annotations are provided, so the description carries full burden. It states it 'Returns: List of notes containing the query' which implies read-only behavior, but doesn't disclose other traits like whether it's case-sensitive, supports wildcards, has rate limits, requires authentication, or how it handles empty results. For a search tool with zero annotation coverage, this leaves significant behavioral gaps.

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 appropriately sized and structured with clear sections (purpose, Args, Returns). Each sentence earns its place, though the Args and Returns sections are very brief. It's front-loaded with the core purpose. No wasted words, but could be slightly more informative 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 1 parameter, no annotations, and an output schema (which likely describes the return structure), the description is minimally complete. It covers the basic purpose and parameter, but lacks usage guidelines and behavioral details. For a simple search tool, it's adequate but has clear gaps in guiding the agent effectively.

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 0%, so the schema provides no parameter descriptions. The description adds minimal semantics: 'query: Search query' in the Args section, but this is basic and doesn't explain format, constraints, or examples (e.g., is it free text, supports operators?). With 1 parameter and low coverage, it partially compensates but remains vague.

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 tool's purpose: 'Search for text within notes' specifies the verb (search) and resource (notes). It distinguishes from siblings like list_notes (which presumably lists all notes without searching) and read_note (which reads a specific note). However, it doesn't explicitly mention how it differs from siblings beyond the search functionality.

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. With siblings like list_notes and read_note available, there's no indication of when search_notes is preferred (e.g., for finding specific content vs. browsing all notes). No prerequisites, exclusions, or comparison to siblings are mentioned.

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

update_noteC

Update the content of an existing note

Args: filename: Note filename content: New content (will be appended)

Returns: Confirmation message of update

ParametersJSON Schema

Name	Required	Description	Default
`filename`	Yes
`content`	Yes

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?

No annotations are provided, so the description carries the full burden. It states the tool updates content and that content 'will be appended,' which adds behavioral context. However, it lacks details on permissions, error handling (e.g., if note doesn't exist), or rate limits. For a mutation tool with zero annotation coverage, this is a significant gap.

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 appropriately sized and front-loaded with the purpose in the first sentence. The Args and Returns sections are structured but could be more integrated; however, every sentence adds value without waste. It's efficient but not perfectly streamlined.

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 has an output schema (returns confirmation message), the description doesn't need to explain return values. However, as a mutation tool with no annotations, 0% schema coverage, and complexity from sibling tools, it should provide more context on usage and behavior. It's minimally adequate but has clear gaps.

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 0%, so the description must compensate. It adds meaning by explaining 'filename' as the note filename and 'content' as new content that will be appended. This clarifies beyond the schema's basic titles, but doesn't provide format details (e.g., file extensions, content constraints). Baseline is 3 as it partially compensates for the coverage gap.

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 tool's purpose: 'Update the content of an existing note.' It specifies the verb ('update') and resource ('note'), but doesn't explicitly differentiate from siblings like 'create_note' or 'read_note' beyond mentioning 'existing note.' This is clear but lacks sibling differentiation.

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. It doesn't mention prerequisites (e.g., note must exist), exclusions, or comparisons to siblings like 'create_note' for new notes or 'read_note' for viewing. Usage is implied by the action but not explicitly stated.

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.

6 tool updatesv1.0.0Jan 4, 2026
- Changedcreate_note1 field changed
  - addedInput schema / title
```
Added value: +"create_noteArguments"
```
- Changeddelete_note1 field changed
  - addedInput schema / title
```
Added value: +"delete_noteArguments"
```
- Changedlist_notes1 field changed
  - addedInput schema / title
```
Added value: +"list_notesArguments"
```
- Changedread_note1 field changed
  - addedInput schema / title
```
Added value: +"read_noteArguments"
```
- Changedsearch_notes1 field changed
  - addedInput schema / title
```
Added value: +"search_notesArguments"
```
- Changedupdate_note1 field changed
  - addedInput schema / title
```
Added value: +"update_noteArguments"
```
6 tool updatesNov 6, 2025
- First observedcreate_note
- First observeddelete_note
- First observedlist_notes
- First observedread_note
- First observedsearch_notes
- First observedupdate_note

Install Server

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

TDQS

A3.6/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap: create, delete, list, read, search, and update notes. The descriptions reinforce these distinctions, making it easy for an agent to select the correct tool for any note-related operation without confusion.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with snake_case (e.g., create_note, delete_note, list_notes). This uniformity enhances readability and predictability, allowing agents to easily infer functionality from the naming convention.

Tool Count5/5

With 6 tools, the server is well-scoped for managing notes, covering essential CRUD operations and additional utilities like search. Each tool earns its place without being excessive or insufficient for the domain, aligning with typical small to medium-sized tool sets.

Completeness5/5

The tool set provides complete CRUD coverage (create, read, update, delete) along with listing and search capabilities, ensuring no dead ends for note management. There are no obvious gaps, as all core lifecycle operations for a notes domain are adequately covered.

Maintenance

ActivityInactive

ResponsivenessNo issues

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

xNotepad AI
com.xnotepadai
Create, search, and update notes in an xNotepad AI notebook, with semantic search and AI Q&A.
Note Taking AI & Machine Learning Knowledge & Memory
1
KnowtisOAuth
app.knowtis
Create, search and manage Knowtis collaborative notes from AI assistants.
Note Taking Knowledge & Memory
21
aNotepadOAuth
com.anotepad
AI access to your aNotepad online notes: read, search, write, and organize via 22 tools.
Note Taking Cloud Storage Search
2
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

Related MCP Servers

Knowledge Base MCP Server
Knowledge & Memory Note Taking Developer Tools
cwente25
F
license
A
quality
D
maintenance
Enables AI assistants to manage a personal markdown-based knowledge base with natural language interactions. Supports creating, searching, updating, and organizing notes across categories like people, recipes, meetings, and procedures.
Updated 9 months ago (2025-11-28 01:45 UTC)
11
1
-
MCP Note-Taking Server
Note Taking Developer Tools File Systems
StarrStack
A
license
Not graded
quality
D
maintenance
Enables structured note-taking with markdown support, dynamic tagging system, advanced search capabilities, and markdown export functionality through natural language conversations in Claude Desktop.
Updated 10 months ago (2025-11-17 05:04 UTC)
3
GPL 3.0
mor
Note Taking Knowledge & Memory
laat
A
license
Not graded
quality
A
maintenance
Enables AI assistants to search, read, create, update, and remove personal markdown notes stored locally, providing persistent memory across sessions.
Updated 6 days ago (2026-08-31 06:00 UTC)
95
2
MIT
MCP Notes Server
Note Taking File Systems
sixbenzene
A
license
Not graded
quality
B
maintenance
Enables AI agents to manage Markdown notes via the Model Context Protocol, supporting creation, editing, searching, and conflict detection.
Updated 2 months ago (2026-07-06 07:35 UTC)
MIT

Appeared in Searches

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/sayranovv/notes-mcp-server'

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

📝 Notes MCP Server

🌟 Features

📦 Installation

Prerequisites

Install uv

Install Dependencies

🚀 Quick Start

1. Save the Server

2. Run the Server

3. Configure in Claude Desktop

4. Restart Claude Desktop

🛠️ Available Tools

create_note

list_notes

read_note

search_notes

update_note

delete_note

📚 Resources

notes://all

💡 Prompts

summarize_notes_prompt

📁 File Structure

Note Format

🧪 Testing

🔧 Configuration

Notes Directory

Filename Generation

📝 Usage Examples

Create a Note

Find Related Notes

Review Notes by Category

Summarize Notes

🤝 Contributing

📄 License

🔗 Resources

⚠️ Limitations

💬 Support

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Appeared in Searches

Latest Blog Posts

MCP directory API

`create_note`

`list_notes`

`read_note`

`search_notes`

`update_note`

`delete_note`

`notes://all`

`summarize_notes_prompt`