Skip to main content
Glama
ppd-matsuda-yoshitaka

stickynotes-mcp-ppd

by ppd-matsuda-yoshitaka
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

stickynotes-mcp-ppd

Windows の付箋（Microsoft Sticky Notes）を、MCP クライアント（Claude など）から扱うためのサーバーです。

既定では読み取り専用です。付箋アプリのデータベース plum.sqlite を読み取り専用モードで開き、一覧・取得・検索だけを提供します。

環境変数で有効にした場合に限り、付箋の新規作成と末尾への追記もできます。既存の行の書き換え、色の変更、削除、ファイルへの書き出しは行いません。

業務で使う前に

  • 付箋の本文は MCP クライアントを経由して AI の提供元へ送られます。業務メモを扱う場合は、社内の AI 利用規程に従ってください。

  • plum.sqlite は Microsoft が仕様を公開していないデータベースです。付箋アプリの更新で構造や保存形式が変わると、読み取りに失敗したり、書き込んだ付箋がアプリで正しく表示されなかったりする可能性があります。

  • 付箋に書かれた文章は AI への入力になります。外部から貼り付けた文章に指示が含まれていると、AI がそれに従って付箋を作成・追記する可能性があります。書き込みを有効にする場合は、クライアント側で書き込みツールを「毎回確認」にしてください。書き込みが無効なら、このサーバーには書き込みや送信の手段はありません。

  • クラウド同期（Microsoft アカウントでのサインイン）を使っている環境では動作を確認していません。

Related MCP server: mcp-snippetbox

ツール

ツール

内容

主な引数

list_notes

更新日時の新しい順に一覧（1行目のプレビュー付き）

limit（1〜100、既定 20）, offset, theme, is_open, include_deleted

get_note

1件の本文と属性

note_id

search_notes

本文の部分一致検索（大文字小文字を区別しない）

query, limit（1〜100、既定 20）, include_deleted

書き込みを有効にしたときだけ、次の2つが追加されます。

ツール

内容

主な引数

create_note

新しい付箋を作る

text, theme（既定 Yellow）, is_open（既定 true）

append_to_note

既存の付箋の末尾に行を足す

note_id, text

  • 読み取りの3つには MCP の readOnlyHint を付けています。クライアント側で「読み取り専用ツールは自動許可」といった設定ができます。書き込みの2つには付けていません。

  • 色（theme）: Yellow, Green, Pink, Purple, Blue, Grey, Charcoal。それ以外を指定するとエラーになります。

  • 本文は太字・斜体・取り消し線・箇条書きを Markdown に変換して返します。下線は Markdown に対応する記法がないため、文字だけを返します。本文中のバックスラッシュ（C:\build など）はそのまま返します。

  • 検索は書式記号を取り除いた後の本文に対して行います。% や _ はワイルドカードではなく、ただの文字として扱います。

セットアップ

Python 3.10 以上が必要です。PowerShell で実行します。

git clone https://github.com/ppd-matsuda-yoshitaka/stickynotes-mcp-ppd.git
cd stickynotes-mcp-ppd
python -m venv .venv
.\.venv\Scripts\python.exe -m pip install -e .

MCP クライアントの設定（mcpServers 形式の例）。パスは実際の場所に置き換えてください。

{
  "mcpServers": {
    "sticky-notes": {
      "command": "C:\\path\\to\\stickynotes-mcp-ppd\\.venv\\Scripts\\python.exe",
      "args": ["C:\\path\\to\\stickynotes-mcp-ppd\\server.py"]
    }
  }
}

付箋のデータベースは既定で次の場所から読みます。

%LOCALAPPDATA%\Packages\Microsoft.MicrosoftStickyNotes_8wekyb3d8bbwe\LocalState\plum.sqlite

別の場所を使う場合は、環境変数 STICKY_NOTES_DB_PATH にパスを指定します。

書き込みを有効にする

クライアント設定のサーバー定義に env を追加します。

"env": {
  "STICKY_NOTES_ENABLE_WRITE": "1"
}

書き込みには次の制限と安全策があります。

  • 付箋アプリを閉じておく必要があります。 Microsoft.Notes.exe が動いている間は書き込みを拒否します。アプリが開いたままだと、アプリが持っている内容で書き込みが上書きされるためです。作成・追記した内容は、次にアプリを開いたときに表示されます。

  • 書き込みのたびにバックアップを取ります。 SQLite のバックアップ機能を使い、書き込み途中のデータ（WAL）も含めて %LOCALAPPDATA%\sticky-notes-mcp-ppd\backups に保存します。直近 20 件を残し、それより古いものは削除します。保存先は STICKY_NOTES_BACKUP_DIR で変えられます。バックアップに失敗した場合は書き込みません。

  • 既存の行は書き換えません。 追記は末尾に行を足すだけなので、元の書式はそのまま残ります。削除済みの付箋には追記できません。

  • 書き込む本文はプレーンテキストです。 ** などの Markdown は書式に変換せず、そのまま文字として保存します。1回の書き込みは 10,000 文字までです。

バックアップから戻すときは、付箋アプリを閉じて plum.sqlite をバックアップファイルで置き換え、同じフォルダの plum.sqlite-wal と plum.sqlite-shm を削除します。

テスト

テストは一時フォルダに作った小さなデータベースだけを使います。本物の付箋データベースには触れません。

.\.venv\Scripts\python.exe -m pip install -e ".[test]"
.\.venv\Scripts\python.exe -m pytest

経緯

widisaadi/stickynotes-mcp（MIT License）をレビューした結果を受けて、データを失いにくい最小構成として、それを参考に書き直したものです。一部の関数と定数は元のコードと同じ形をしています。元のプロジェクトの著作権表示とライセンス文は THIRD_PARTY_NOTICES.md に載せています。

Available Tools

3 tools
get_noteA
Read-onlyIdempotent

Get the full text and details of one sticky note.

Args: note_id: The note ID from list_notes or search_notes.

ParametersJSON Schema
NameRequiredDescriptionDefault
note_idYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered elsewhere. The description adds only that the result includes full text and details; no auth, rate-limit, or not-found behavior is disclosed, but the annotation bar is met.

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?

One front-loaded sentence states the purpose, followed by a terse args annotation. The args restatement slightly duplicates the schema, but it adds the ID-source hint, so it earns most of its space.

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?

Output schema exists, so return values need no explanation, and annotations cover the safety profile. For a single-parameter read tool the description is essentially complete, missing only explicit sibling routing.

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 0%, so the description must carry the single parameter. It does so usefully by naming note_id and specifying its provenance (from list_notes or search_notes), which the bare string schema does not convey.

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?

States a specific verb ('Get') and resource ('one sticky note') with the scope of the return ('full text and details'). It implicitly distinguishes itself from list_notes/search_notes by specifying a single note, but never names those siblings explicitly.

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 note_id arg text ('The note ID from list_notes or search_notes') implies the workflow: obtain a note_id from those tools first, then call this one. There is no explicit when-to-use/when-not statement or named alternative for retrieval itself.

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

list_notesA
Read-onlyIdempotent

List sticky notes with a one-line preview, newest updates first.

Args: limit: Maximum notes to return (1-100, default 20). offset: Number of notes to skip for paging. theme: Filter by color (Yellow, Green, Pink, Purple, Blue, Grey, Charcoal). is_open: Filter by saved open/closed state. include_deleted: Include notes marked as deleted.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNo
themeNo
offsetNo
is_openNo
include_deletedNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already cover readOnly, idempotent, and non-destructive behavior, so the bar is lower. The description adds real context beyond them: results are previews rather than full notes, ordering is newest-update-first, and include_deleted reveals a soft-delete model that annotations do not convey.

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?

Front-loaded single-sentence purpose followed by a compact per-argument block; no filler. The Args block is slightly mechanical but every line adds parameter meaning the schema lacks.

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?

An output schema exists, so return values need not be explained, and the description still notes the one-line preview shape. With no required parameters, a 0% schema coverage list fully compensated, and paging covered, an agent has everything needed to call it correctly.

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 description coverage is 0%, so the description must carry all five parameters, and it largely does: limit range 1-100 with default 20, offset as a paging skip count, the full theme color set, is_open as saved open/closed state, and include_deleted for soft-deleted notes. Only the accepted theme spelling/casing and offset interaction with limit are left implicit.

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?

States a specific verb+resource (list sticky notes) and adds distinguishing behavior: a one-line preview and 'newest updates first' ordering. It does not explicitly name siblings search_notes/get_note, so an agent must infer the difference from 'preview' vs. full retrieval.

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

Usage Guidelines3/5

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

Usage is implied by the filter list (theme, is_open, include_deleted) and by the 'one-line preview' framing that suggests lightweight listing versus full note retrieval. However, it never states when to use this instead of search_notes or get_note, and gives no exclusions.

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

search_notesA
Read-onlyIdempotent

Search note text for a keyword (case-insensitive, plain substring match).

Args: query: Text to look for. limit: Maximum notes to return (1-100, default 20). include_deleted: Include notes marked as deleted.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNo
queryYes
include_deletedNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent and non-destructive, so safety is covered. The description adds genuinely useful behavioral detail beyond them: the match is case-insensitive substring, not token/regex/phrase matching. It omits result ordering and how deleted notes are matched, but that is a modest 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 core behavior is front-loaded in the first sentence and the Args block is terse and scannable. The Args formatting is slightly heavier than necessary given the schema lists the same names, but nothing is wasted prose.

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, return values need not be described, and the parameters and matching semantics are covered. Missing pieces are result ordering/limits behavior and sibling differentiation, which are minor for a three-parameter search 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?

Schema description coverage is 0%, so the description carries the burden and does so: it defines query, gives the limit's 1-100 range and 20 default (the schema only supplies the default, not the bounds), and explains that include_deleted controls notes marked as deleted. Only the query semantics could be richer (title vs body scope).

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?

Specific verb+resource (search note text) plus the matching algorithm in parentheses, so an agent knows this is keyword search rather than enumeration or retrieval. It does not explicitly name list_notes or get_note as the alternatives, which is the only thing keeping it from a 5.

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?

Searching by keyword is implicitly the reason to pick this over list_notes/get_note, and the 'plain substring match' note hints that it is not a semantic/full-text search. However there is no explicit statement of when to use it versus the siblings, nor any exclusion guidance.

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.

  1. 3 tool updatesv0.2.0
    • First observedget_note
    • First observedlist_notes
    • First observedsearch_notes
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.6/5.0

Scored across 3 tools

Disambiguation4/5

list_notes (enumerate/filter), get_note (single note by ID), and search_notes (keyword substring) each target a distinct retrieval pattern, and the descriptions make the boundaries clear. Minor overlap exists because list_notes and search_notes both return paginated note collections, so a broad search can look like a list.

Naming Consistency4/5

All three tools follow a clean snake_case verb_noun pattern (list_notes, get_note, search_notes). The only deviation is singular 'get_note' versus plural 'list_notes'/'search_notes', which is a conventional single-vs-collection distinction rather than an inconsistency.

Tool Count3/5

Three tools is on the thin side for a note-management domain; it covers only read access. It is not an extreme mismatch, but the surface feels under-scoped for what a sticky-notes server would typically need to be useful.

Completeness2/5

The set is read-only: there is no create_note, update_note, or delete_note, even though filters like 'include_deleted' and flags like 'is_open' imply write/lifecycle operations exist. An agent asked to add, edit, close, or delete a note would hit a dead end.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • Sticky Notes MCP Server

    vedantparmar12
    A
    license
    A
    quality
    D
    maintenance
    Enables creating, reading, updating, and deleting sticky notes with persistent text file storage through the MCP protocol.
    4
    MIT

  • mcp-snippetbox

    AAAdiaosbrk
    A
    license
    Not graded
    quality
    C
    maintenance
    Enables managing notes through a simple MCP server, providing tools to add, retrieve, update, delete, and list notes for use with Claude Desktop.
    MIT

  • notes-mcp

    SUTD-AI-Interest-Group
    F
    license
    Not graded
    quality
    C
    maintenance
    Enables AI agents to read, search, create, and append Markdown notes from a local vault (e.g., Obsidian) via MCP, allowing natural-language note management through compatible clients.
    -