How do I use M5 Petit Notes?

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., "@M5 Petit Notes create a note called 'shopping list' with milk and eggs" 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.

M5 Petit Notes

by PetitOnes

Overview Schema Related Servers Score Discussions

Python

Local

M5 Petit Notes

English Page

M5 Petit(や、その他のClaudeベースのエージェント)のためのメモ帳MCPサーバーです。

記憶は「思い出す」もの。メモ帳は「見返す」もの。検索して呼び出す長期記憶とは違い、開けばすぐ見える場所にmarkdownファイルとして残る、永続的なノートを提供します。参照表・リスト・調べもののまとめなど、記憶を検索し直さずにいつでも見返したいものに向いています。

Related MCP server: MCP Notes Server

機能

ノート一覧 — 保存されているノートの名前とサイズを一覧表示
ノート読み取り — 名前を指定してノートの全文を取得
ノート作成・上書き — markdown形式でノートを新規作成、または既存ノートを丸ごと更新
追記 — 既存ノートの末尾にテキストを追加(なければ新規作成)
ノート削除 — 名前を指定してノートを削除
ファイル単位の永続化 — 1ノート=1つの.mdファイル。バックアップも人間による直接編集も簡単

必要環境

Python 3.10+
uv

セットアップ

uvが未インストールの場合は先にインストールします。

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

git clone https://github.com/PetitOnes/m5-petit-notes.git
cd m5-petit-notes
uv sync
uv run notes-mcp

環境変数

変数名	デフォルト	説明
`PETIT_DATA_DIR`	`~/petit_data`	データディレクトリのルート(m5-petit-appと共有)
`CHARACTER_ID`	`default`	キャラクターID。ノート保存先のパス決定に使う
`NOTES_DIR`	`$PETIT_DATA_DIR/characters/<character_id>/notes`	ノートファイル(`.md`)を保存するディレクトリ

Claude Code連携

.mcp.json(または~/.claude/settings.json)に追加します。

{
  "mcpServers": {
    "notes": {
      "command": "uv",
      "args": ["run", "--directory", "/path/to/m5-petit-notes", "notes-mcp"],
      "env": {
        "CHARACTER_ID": "petit"
      }
    }
  }
}

ツール一覧

list_notes

保存されているノートを一覧表示します(名前とサイズ)。

read_note

ノートを名前で読み取ります。

{ "name": "light_values" }

write_note

ノートを新規作成、または上書きします。markdown形式を想定しています。

{
  "name": "favorite_sounds",
  "content": "# 好きな音\n\n- 雨の音\n- 風鈴"
}

append_note

既存ノートの末尾にテキストを追記します。ノートが存在しなければ新規作成します。

{
  "name": "log",
  "content": "今日見つけたこと: ..."
}

delete_note

ノートを名前で削除します。

{ "name": "old_draft" }

開発

# 開発依存をインストール
uv sync --all-extras

# テスト実行
uv run pytest

# lint
uv run ruff check .

アーキテクチャ

m5-petit-notes/
├── src/notes_mcp/
│   ├── server.py       # MCPサーバー(list/read/write/append/delete)
│   └── __init__.py
└── tests/

License

Apache License 2.0

Available Tools

5 tools

append_noteA

Append text to an existing note. If the note doesn't exist, creates it. Use this to add entries to a list or log without rewriting the whole note.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Note name
`content`	Yes	Text to append

TDQS

A4.2/5.0

Behavior4/5

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

Discloses key behavior: creates note if missing, appends text. Without annotations, the description carries the burden and does so adequately, though edge cases like empty content are not addressed.

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 sentences with no fluff, front-loaded with the core action. 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?

Covers input semantics and behavioral context adequately. Without an output schema, the description is sufficient for a simple append operation. Sibling tools provide additional context.

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 parameter descriptions. The description does not add new semantic meaning beyond what the schema provides, meriting baseline 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 action (append text) and resource (existing note), and distinguishes it from the sibling tool write_note (which overwrites). It also mentions creation behavior.

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?

Provides explicit use case: adding entries to a list or log without rewriting. Implicitly advises against using for overwriting, which is covered by sibling write_note.

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

delete_noteB

Delete a note by name.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Note name to delete

TDQS

B3.2/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 only states 'Delete a note by name.' It fails to disclose whether the deletion is permanent, requires confirmation, returns a success indicator, or has any side effects. The description lacks essential behavioral details 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.

Conciseness5/5

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

The description is a single, well-structured sentence. It is concise with no wasted words, and the purpose is front-loaded. All parts are impactful.

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

Completeness2/5

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

Given the complexity (no output schema, no annotations, sibling tools that could confuse usage), the description is incomplete. It does not mention return behavior, error handling, or how this differs from 'write_note' which might also remove content. The description does not fully equip the agent to use the tool 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 coverage is 100% with the parameter 'name' already described. The description adds minimal value beyond restating the parameter's purpose. Baseline score of 3 is appropriate as the description does not enhance understanding of 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 the verb 'Delete', the resource 'note', and the method 'by name'. It effectively distinguishes the tool from its siblings (append, list, read, write) which perform different operations on notes.

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 'write_note' (which could overwrite) or 'read_note' (which could precede deletion). No context about prerequisites or when deletion is appropriate is given.

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

list_notesA

List all notes in the notebook. Returns note names and their sizes. Use this to see what notes you have.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description must convey behavioral traits. It states the operation is a list with a read-like return, but does not explicitly declare non-destructiveness or mention any limitations like pagination 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?

The description consists of two concise sentences with no wasted words. It front-loads the core action and return value, then adds a usage hint.

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 has no parameters, no output schema, and no annotations, the description adequately covers what the tool does and returns. However, it could mention that this is the primary listing tool among siblings.

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 no parameters in the schema, and schema coverage is 100% (vacuously). The baseline for 0 parameters is 4, and the description adds no parameter-specific info, which is acceptable.

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 'List all notes in the notebook' with a specific verb and resource, and distinguishes this tool from siblings (append, delete, read, write) by its listing function. It also specifies what is returned (names and sizes).

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 provides a simple usage suggestion ('Use this to see what notes you have'), but does not explicitly discuss when not to use this tool or mention alternative tools for filtering or searching.

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

read_noteA

Read a note by name. Returns the full content. Use this to look back at something you wrote down.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Note name (e.g. 'light_values' or 'light_values.md')

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description must convey behavioral traits. It indicates a read operation ('Returns the full content') which implies non-destructive, but lacks explicit statements about safety or permissions. Adequate but minimal.

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 efficient sentences with no extraneous information. Front-loaded with the core action and outcome.

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 read tool with one parameter and no output schema, the description covers the purpose, input, and return value ('full content'). Could specify return type more precisely, but sufficient for the task.

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 the input schema already documents the 'name' parameter with an example. The description adds no additional meaning beyond the schema, resulting in a baseline score.

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 identifies the action ('Read'), resource ('note'), and scope ('by name'). It distinguishes from siblings (append, delete, list, write) by focusing on retrieval.

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 states 'Use this to look back at something you wrote down,' which implies retrieval context. While it doesn't explicitly list alternatives, the sibling tool names (append_note, delete_note, list_notes, write_note) provide natural differentiation.

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

write_noteA

Write or update a note. Creates a new note or overwrites an existing one. Use markdown format. Good for reference tables, lists, research summaries, anything you want to look back at without searching memories.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Note name (e.g. 'light_values' or 'favorite_sounds')
`content`	Yes	Full content of the note (markdown)

TDQS

A4/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 full burden. It clearly states that the tool creates a new note or overwrites an existing one, and specifies markdown format. However, it does not discuss side effects like idempotency or 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 consists of two short sentences with no redundant information. It front-loads the core action and efficiently adds context about markdown and use cases.

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 low-complexity tool with no annotations or output schema, the description adequately covers the purpose, behavior, and usage. It could be improved by mentioning the expected return value or clarifying overwrite vs. append behavior.

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 the schema already includes example values for 'name' and 'markdown' for 'content'. The description adds no new information beyond repeating these examples, so it meets the baseline 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 verb (write/update), resource (note), and distinguishes from siblings by specifying that it creates or overwrites a note, with examples like reference tables and research summaries.

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 provides use cases for when to use this tool (reference tables, lists, etc.) but does not explicitly differentiate from the sibling tool 'append_note' or state when to avoid using it.

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.

5 tool updatesv0.1.0Jul 13, 2026
- First observedappend_note
- First observeddelete_note
- First observedlist_notes
- First observedread_note
- First observedwrite_note

Install Server

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

TDQS

A4/5.0

Disambiguation5/5

Each tool has a distinct operation (append, delete, list, read, write) with no overlap. Agents can clearly differentiate them.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case (e.g., append_note, delete_note), making them predictable.

Tool Count5/5

5 tools is an ideal count for a notes server, covering all essential operations without being too sparse or bloated.

Completeness5/5

The tool set provides full CRUD operations plus listing and appending. No obvious gaps for basic note management.

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

Related MCP Servers

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 2 days ago (2026-09-03 17:52 UTC)
6
1
-
MCP Notes Server
Note Taking File Systems
pipinho13
A
license
Not graded
quality
D
maintenance
A beginner-friendly MCP server for managing personal notes. Enables Claude to create, list, read, search, update, and delete notes saved as Markdown files.
Updated 3 months ago (2026-06-12 11:03 UTC)
MIT
MCP Local File Saver
Note Taking File Systems
omcar04
F
license
Not graded
quality
D
maintenance
A Python-based MCP server for Claude Desktop that enables you to save, append, read, and list local text notes, including appending Claude's responses.
Updated 5 months ago (2026-03-27 17:34 UTC)
-
mcp_notes
Note Taking File Systems
FielderNik
F
license
A
quality
C
maintenance
MCP server for saving, reading, and listing Markdown notes in the filesystem. Enables agents to persistently store reports or notes as plain Markdown files.
Updated 2 months ago (2026-06-28 12:53 UTC)
3
-

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/PetitOnes/m5-petit-notes'

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