How do I use notes-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., "@notes-mcp list my recent notes" 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

by gabed5303-ops

Overview Schema Related Servers Score Discussions

Python

Local

notes-mcp

A personal knowledge/notes MCP server in Python. It gives Claude (Desktop, Code, or any MCP-compatible client) a set of tools to create, search, edit, and manage a collection of notes stored in a local SQLite database.

Built with the official MCP Python SDK (FastMCP), fully typed, with structured input/output schemas on every tool and a two-layer test suite.

Python 3.12+ MCP SDK 1.28 Tests: 38 passing License: MIT

Live demo: all six tools called over stdio by a real MCP client

Real output of examples/demo.py — a genuine MCP client session against the server over stdio, the same path Claude Desktop uses. Reproduce it with uv run python examples/demo.py.

What is MCP?

The Model Context Protocol is an open standard (originally by Anthropic) that lets AI applications talk to external systems in a uniform way. Instead of every AI app writing custom integrations for every data source, MCP defines one protocol:

A host (Claude Desktop, Claude Code, an IDE…) runs one or more clients.
Each client holds a 1:1 connection to a server — a small program that exposes capabilities.
Servers expose three primitive types: tools (actions the model can invoke), resources (data the host can read), and prompts (reusable templates).

The wire format is JSON-RPC 2.0. For local servers like this one, the transport is stdio: the host launches the server as a subprocess, writes requests to its stdin, and reads responses from its stdout. That's why an MCP stdio server must never print() — stdout belongs to the protocol; diagnostics go to stderr.

A minimal MCP server needs exactly three things:

A server instance with a name (identifies it during the initialization handshake).
Registered capabilities — here, six tools, each with a JSON Schema for its inputs and outputs.
A transport loop — the SDK's mcp.run(transport="stdio") handles the handshake, request dispatch, validation, and serialization.

This project exposes tools only, which is the right primitive for note CRUD: the model decides when to call them, and each call is validated against a schema.

Related MCP server: Local Knowledge Desk

Tools

Tool	What it does	Key inputs → output
`add_note`	Create a note	`title`, `body`, `tags?` → full `Note`
`get_note`	Fetch one note in full	`note_id` or `title` → full `Note`
`search_notes`	Keyword and/or tag search	`query?`, `tag?`, `limit?` → `SearchResult` (summaries)
`update_note`	Edit any subset of fields	`note_id`, `title?`, `body?`, `tags?` → updated `Note`
`delete_note`	Permanently remove a note	`note_id` → `DeleteResult`
`list_recent_notes`	Newest-updated notes first	`limit?` → `RecentNotes` (summaries)

Every tool declares a full input schema (generated from type hints + pydantic.Field constraints, e.g. limit is 1–100) and an output schema (generated from the Pydantic return models in models.py). Tools carry honest MCP annotations: readOnlyHint on get/search/list, destructiveHint on delete_note and update_note (an overwrite destroys prior content — the MCP spec reserves destructiveHint: false for purely additive updates), and openWorldHint: false everywhere since nothing leaves the local database. Hosts can use these to gate confirmation UX.

Failure cases (missing note, no search criteria, invalid arguments) come back as proper MCP tool errors with readable messages, so the model can recover — e.g. by searching before retrying a get_note.

Architecture

Architecture: MCP host talks JSON-RPC over stdio to the layered server, which persists to SQLite

db.py is pure Python + SQLite — it has no idea MCP exists. Normalized schema (notes, tags, note_tags) with ON DELETE CASCADE and orphan-tag pruning. Testable with plain pytest.
tools.py is the protocol surface: thin wrappers that translate between MCP tool calls and the data layer, and own all the schema/description metadata the model sees.
server.py wires them together and picks the database location.

Quickstart

Requires Python ≥ 3.12 and uv.

git clone <this repo> && cd notes-mcp
uv sync          # install dependencies into .venv
uv run pytest    # 38 tests: data layer + full MCP integration
uv run notes-mcp # runs the server on stdio (Ctrl-C to exit)

Connect to Claude Desktop

Add to claude_desktop_config.json (Settings → Developer → Edit Config):

{
  "mcpServers": {
    "notes": {
      "command": "uv",
      "args": ["run", "--directory", "/ABSOLUTE/PATH/TO/notes-mcp", "notes-mcp"]
    }
  }
}

Restart Claude Desktop; the six tools appear under the notes server. Try: “Add a note titled ‘Reading list’ with the books I mention, tagged reading.”

Connect to Claude Code

claude mcp add notes -- uv run --directory /ABSOLUTE/PATH/TO/notes-mcp notes-mcp

Inspect interactively

The MCP Inspector gives you a debugging UI over any server:

npx @modelcontextprotocol/inspector uv run --directory /ABSOLUTE/PATH/TO/notes-mcp notes-mcp

Data storage

Notes live in a single SQLite file, ~/.notes-mcp/notes.db by default. Override with the NOTES_MCP_DB environment variable — in claude_desktop_config.json, add an env key inside the server entry, next to command and args:

{
  "mcpServers": {
    "notes": {
      "command": "uv",
      "args": ["run", "--directory", "/ABSOLUTE/PATH/TO/notes-mcp", "notes-mcp"],
      "env": { "NOTES_MCP_DB": "/path/to/work-notes.db" }
    }
  }
}

For Claude Code, pass it with -e:

claude mcp add notes -e NOTES_MCP_DB=/path/to/work-notes.db -- \
  uv run --directory /ABSOLUTE/PATH/TO/notes-mcp notes-mcp

The default is an absolute path on purpose: MCP hosts launch servers with an arbitrary working directory, so a relative path would silently create a new database per launch location.

Testing

Two layers, mirroring the architecture:

tests/test_db.py — unit tests for the storage layer: CRUD, tag dedup/pruning, Unicode case-insensitivity, literal wildcard handling, duplicate-title resolution, persistence across connections.
tests/test_tools.py — integration tests that connect a real MCP client session to the server over the SDK's in-memory transport and exercise every tool through the full protocol stack: handshake, discovery, schema validation, structured output, and error paths.
tests/test_server.py — database-path resolution (NOTES_MCP_DB override, home expansion, absolute default).

Test suite: 38 tests across data layer, server wiring, and MCP protocol integration

uv run pytest

Project structure

notes-mcp/
├── pyproject.toml          # uv project; console script: notes-mcp
├── README.md
├── DEVLOG.md               # build log: decisions and why
├── src/notes_mcp/
│   ├── server.py           # entry point + FastMCP wiring
│   ├── tools.py            # the 6 MCP tool definitions
│   ├── models.py           # Pydantic output models (→ output schemas)
│   └── db.py               # SQLite data layer (MCP-free)
├── tests/
│   ├── test_db.py          # data-layer unit tests
│   ├── test_tools.py       # end-to-end MCP integration tests
│   └── test_server.py      # DB-path resolution tests
├── examples/demo.py        # runnable stdio demo (source of the image above)
└── docs/                   # README images

Design decisions (short version — full rationale in DEVLOG.md)

Official mcp SDK, FastMCP API — schemas derive from type hints, so the code and the contract can't drift apart.
Normalized tag schema instead of a JSON column — real tag queries, dedup, and orphan cleanup in SQL. Each tag stores a display name plus a casefold()ed name_key, so one equality rule governs dedup and lookup.
Literal substring search with Unicode-correct case folding — SQLite's built-in NOCASE/LIKE only fold ASCII, so search uses a registered casefold SQL function; no wildcard syntax surprises for the model. FTS5 is the documented upgrade path.
Microsecond UTC timestamps — recency ordering must distinguish writes within the same second (a bug the test suite caught).

Roadmap

Full-text search via SQLite FTS5 (ranked results, prefix queries)
MCP resources exposing notes as notes://{id} for direct context inclusion
Note export (Markdown folder sync)

Available Tools

6 tools

add_noteA

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

Returns the stored note, including its assigned ID — reference that ID in later get/update/delete calls.

ParametersJSON Schema

Name	Required	Description
`body`	Yes	Body text of the note (plain text or Markdown).
`tags`	No	Optional tags to categorize the note, e.g. ['ideas', 'physics'].
`title`	Yes	Title for the new note.

Output Schema

ParametersJSON Schema

Name	Required	Description
`id`	Yes	Unique numeric ID of the note.
`body`	Yes	Full body text of the note.
`tags`	Yes	Tags attached to the note.
`title`	Yes	Title of the note.
`created_at`	Yes	Creation time (ISO 8601, UTC).
`updated_at`	Yes	Last modification time (ISO 8601, UTC).

TDQS

A4.3/5.0

Behavior4/5

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

Annotations correctly indicate non-read-only and non-destructive behavior. The description adds value by explaining the return behavior (stored note with assigned ID), which aids the agent.

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 two sentences, front-loaded with the core action, and contains no unnecessary words. Every sentence provides essential information.

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?

Given the presence of an output schema and comprehensive parameter descriptions, the description is complete. It explains the purpose, return value, and hint for future usage, fulfilling all requirements for a creation tool.

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% and already describes all parameters clearly. The description adds no additional semantic meaning for parameters beyond what the schema provides, so baseline 3 is appropriate.

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 'Create a new note with a title, body, and optional tags.' It uses a specific verb ('Create') and resource ('note'), and distinguishes itself from sibling tools like delete, update, and list.

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

Usage Guidelines4/5

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

The description advises referencing the returned ID for later get/update/delete calls, setting clear usage context. It implies when to use the tool (to create a note) but does not explicitly mention when to avoid it.

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

delete_noteA

Destructive

Permanently delete a note by ID. This cannot be undone.

Returns a confirmation with the deleted note's title.

ParametersJSON Schema

Name	Required	Description	Default
`note_id`	Yes	ID of the note to delete.

Output Schema

ParametersJSON Schema

Name	Required	Description
`id`	Yes	ID of the deleted note.
`title`	Yes	Title of the deleted note.
`deleted`	Yes	True if the note was removed.

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already provide destructiveHint=true and readOnlyHint=false. The description adds 'This cannot be undone' and 'Returns a confirmation with the deleted note's title', providing behavioral context beyond annotations.

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 consists of two short, front-loaded sentences. The first states the primary action, the second adds critical side effect and return info. No unnecessary words.

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?

Given the tool's simplicity (one required parameter), the presence of annotations, and the mention of return confirmation, the description fully covers necessary context for an agent to use it correctly.

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% with the parameter 'note_id' described as 'ID of the note to delete.' The description merely says 'by ID', adding no additional semantics beyond the schema.

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

Purpose5/5

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

The description states 'Permanently delete a note by ID', clearly indicating the verb (delete), resource (note), and method (by ID). It distinguishes from sibling tools like add, get, list, search, and update.

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 deletion but does not explicitly state when to use this tool vs alternatives, nor when not to use it. It mentions irreversibility but lacks direct comparison to siblings.

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

get_noteA

Read-only

Retrieve a single note by its ID or exact title.

    Provide note_id OR title (note_id wins if both are given). Returns the
    full note including its body. Use search_notes for fuzzy matching.

ParametersJSON Schema

Name	Required	Description	Default
`title`	No	Exact title of the note (case-insensitive). Used when note_id is not given; if several notes share the title, the most recently updated one is returned.
`note_id`	No	ID of the note to fetch. Preferred when known.

Output Schema

ParametersJSON Schema

Name	Required	Description
`id`	Yes	Unique numeric ID of the note.
`body`	Yes	Full body text of the note.
`tags`	Yes	Tags attached to the note.
`title`	Yes	Title of the note.
`created_at`	Yes	Creation time (ISO 8601, UTC).
`updated_at`	Yes	Last modification time (ISO 8601, UTC).

TDQS

A4.8/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true. Description adds behavioral details: conflict resolution (note_id wins), case-insensitive title matching, and fallback to most recent if multiple same title. Could mention error handling (e.g., 404 if not found) but output schema might cover that.

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 short sentences plus a bullet. Front-loaded with main action. Every sentence adds value: retrieval method, parameter precedence, fuzzy alternative. No wasted words.

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 get-by-id/title tool, description covers purpose, parameter disambiguation, and when to use sibling tool. Output schema exists, so return format is documented elsewhere. Complete and self-contained.

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

Parameters5/5

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

Schema coverage is 100%, but description adds meaning beyond schema: note_id wins if both given, title is case-insensitive, and if multiple notes share title, most recently updated is returned. These enrich what the schema alone 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?

Description clearly states 'Retrieve a single note by its ID or exact title' with specific verb and resource. Distinguishes from sibling search_notes by mentioning 'fuzzy matching' and from list_recent_notes by indicating single retrieval.

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

Usage Guidelines5/5

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

Explicitly provides when to use: 'Provide note_id OR title (note_id wins if both given)'. Also advises alternative: 'Use search_notes for fuzzy matching'. No other sibling tools are appropriate for this exact retrieval.

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

list_recent_notesA

Read-only

List the most recently created or updated notes, newest first.

    Returns summaries — fetch a full note with get_note.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Maximum number of notes to return.

Output Schema

ParametersJSON Schema

Name	Required	Description
`count`	Yes	Number of notes returned.
`notes`	Yes	Notes ordered by last update, newest first.

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already mark readOnlyHint=true. The description adds that it returns summaries and suggests get_note for full notes, but no additional behavioral traits like pagination or auth needs.

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 concise lines with no fluff. First line states purpose, second adds useful context about summaries and alternative.

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 list tool with 1 parameter and output schema, the description covers essentials. Minor gap: no mention of summary format, 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 clear description for limit parameter. The description provides no additional meaning beyond the schema.

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

Purpose5/5

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

The description clearly states the verb (list), resource (recent notes), and ordering (newest first). It distinguishes from siblings like search_notes and get_note.

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 using get_note for full content but does not explicitly when to use this versus alternatives like search_notes. No exclusion criteria.

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

search_notesA

Read-only

Search notes by keyword, by tag, or both (filters combine with AND).

    Results are summaries (ID, title, snippet, tags) ordered newest-updated
    first — fetch the full body of a hit with get_note.

ParametersJSON Schema

Name	Required	Description
`tag`	No	Return only notes carrying this exact tag (case-insensitive).
`limit`	No	Maximum number of results.
`query`	No	Keyword to match against note titles and bodies (case-insensitive substring).

Output Schema

ParametersJSON Schema

Name	Required	Description
`tag`	Yes	The tag that was filtered on, if any.
`count`	Yes	Number of notes matched (up to the limit).
`notes`	Yes	Matching notes, most recently updated first.
`query`	Yes	The keyword query that was searched, if any.

TDQS

A4.4/5.0

Behavior4/5

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

Annotations indicate read-only (readOnlyHint=true) and non-open world. The description adds that results are summaries ordered newest-first, which is beyond annotations. No contradictions.

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, no fluff, key information front-loaded. Every sentence adds value.

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?

With an output schema present, the description covers result format and ordering, plus links to get_note. It is thorough for a search tool with simple parameters.

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?

Schema coverage is 100% with individual parameter descriptions. The description adds the AND combination logic for query and tag, which is not fully captured in the schema. This provides added meaning.

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 action (search) and resource (notes), specifies filtering options (keyword, tag, both with AND), and distinguishes from sibling tools like get_note and list_recent_notes.

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

Usage Guidelines4/5

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

The description explains how filters combine and directs users to get_note for full body, providing clear context for when to use this tool vs. alternatives. It does not explicitly mention when not to use it or other siblings, but the guidance is sufficient.

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

update_noteA

Destructive

Edit an existing note's title, body, and/or tags.

Only the fields you pass are changed. Passing tags replaces the whole tag set. Returns the updated note.

ParametersJSON Schema

Name	Required	Description
`body`	No	New body text. Omit to keep the current body.
`tags`	No	Replacement tag list. Omit to keep current tags; pass [] to remove all tags.
`title`	No	New title. Omit to keep the current title.
`note_id`	Yes	ID of the note to update.

Output Schema

ParametersJSON Schema

Name	Required	Description
`id`	Yes	Unique numeric ID of the note.
`body`	Yes	Full body text of the note.
`tags`	Yes	Tags attached to the note.
`title`	Yes	Title of the note.
`created_at`	Yes	Creation time (ISO 8601, UTC).
`updated_at`	Yes	Last modification time (ISO 8601, UTC).

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already indicate destructiveness; the description adds behavioral details: partial update semantics and tag set replacement. It also confirms the return of the updated note.

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 two sentences, front-loading purpose and then adding key behavioral notes. No extraneous information.

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 output schema exists and annotations cover destructiveness, the description adequately explains the update behavior. It could mention error conditions but is sufficient for a simple update tool.

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?

With full schema description coverage, the baseline is 3. The description adds value by explaining partial update behavior and tag replacement, which the schema descriptions do not convey.

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 edits an existing note's title, body, and/or tags. This specific verb+resource combination differentiates it from sibling tools like add_note (create) and delete_note (remove).

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

Usage Guidelines4/5

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

The description implies use for modifying existing notes but does not explicitly state when not to use it or compare to alternatives. However, the context of editing vs creating is clear from the wording.

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 updatesv0.1.0Jul 14, 2026
- First observedadd_note
- First observeddelete_note
- First observedget_note
- First observedlist_recent_notes
- First observedsearch_notes
- First observedupdate_note

Install Server

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

TDQS

A4.3/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: create, retrieve by ID/title, list recent, search, update, and delete. No overlap in functionality; get_note is for exact matches while search_notes handles fuzzy/field queries.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (add_note, delete_note, get_note, list_recent_notes, search_notes, update_note). No mixing of conventions.

Tool Count5/5

Six tools is well-scoped for a notes application, covering all essential operations (CRUD, listing, search) without unnecessary redundancy. The count feels appropriate for the domain.

Completeness4/5

Covers all core CRUD operations plus search and recent listing. Minor gap: no explicit 'list all notes' tool (list_recent_notes may return all but its name suggests a limit), and tag management is only via update_note or add_note.

Maintenance

ActivitySlowing

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

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
NoteFlow-MCP
io.github.Surendhar-23
An MCP server that used to create notes
Note Taking Developer Tools
2
TaprootOAuth
com.taproothq
Persistent memory layer for AI tools. Save and recall notes across Claude and other MCP clients.
Knowledge & Memory Note Taking
2

Related MCP Servers

MCP Notes
Note Taking Developer Tools
9Ninety
A
license
A
quality
D
maintenance
A simple note-taking MCP server for recording and managing notes with AI models.
Updated a year ago (2025-05-01 19:42 UTC)
4
22
36
GPL 2.0
Local Knowledge Desk
Note Taking File Systems Search
MatiasLaukka
F
license
A
quality
B
maintenance
A local MCP server for managing Markdown notes, enabling create, list, read, search, summarize, and delete operations through natural language.
Updated 3 days ago (2026-09-03 17:52 UTC)
6
1
-
MCP Note Taker
Note Taking File Systems
TarcisioPhilips
A
license
Not graded
quality
D
maintenance
A proof-of-concept MCP server for AI assistant note-taking, enabling adding notes, fetching the latest note, and summarizing all notes.
Updated a year ago (2025-05-12 12:30 UTC)
5
MIT
notes-mcp
Note Taking Knowledge & Memory
sheimaz
A
license
A
quality
C
maintenance
MCP server for a personal notes/knowledge base that enables AI assistants to create, search, and retrieve notes using natural language. It exposes tools like create_note and search_notes, resources for each note, and a summarize_tag prompt.
Updated a month ago (2026-08-02 16:52 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/gabed5303-ops/notes-mcp'

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