Skip to main content
Glama
enesjakozh
truaxki

MCP Notes Server

by truaxki
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

MCP ノートサーバー

鍛冶屋のバッジ

永続ストレージを使用してメモを管理するためのモデル コンテキスト プロトコル (MCP) サーバー実装。

特徴

  • メモの作成、閲覧、更新、削除

  • JSONを使用した永続ストレージ

  • 作成と変更のタイムスタンプ追跡

  • プロンプトによるメモの要約

  • note:// URIスキームを使用したリソースベースのアクセス

Related MCP server: Beeper MCP Note Server

インストール

Smithery経由でインストール

Smithery経由で Claude Desktop のノートを自動的にインストールするには:

npx -y @smithery/cli install notes --client claude

手動インストール

  1. Python 3.10以降がインストールされていることを確認してください

  2. 仮想環境を作成します。

    python -m venv .venv

# On Unix/MacOS:
source .venv/bin/activate

# On Windows:
.venv\Scripts\activate

  3. インストール要件:

    pip install MCP

プロジェクト構造

notes/
├── __init__.py          # Package initialization
├── server.py           # Main server implementation
├── storage.py          # Note persistence layer
├── resources.py        # Resource handling (note:// URIs)
├── prompts.py         # LLM prompt generation
└── tools/             # Server tools
    ├── __init__.py    # Tools package initialization
    ├── list_tools.py  # Tool listing functionality
    └── handle_tools.py # Tool handling implementation

利用可能なツール

  • add-note : 新しいメモを作成する

  • list-all-notes : 保存されているすべてのメモを表示する

  • update-note : 既存のノートを変更する

  • delete-note : メモを削除する

使用法

  1. サーバーを起動します。

    mcp install src/notes
mcp start Notes

  2. 操作例:

    # Create a note
await client.call_tool("add-note", {
    "name": "example",
    "content": "This is a test note"
})

# List all notes
await client.call_tool("list-all-notes")

# Update a note
await client.call_tool("update-note", {
    "name": "example",
    "content": "Updated content"
})

# Delete a note
await client.call_tool("delete-note", {
    "name": "example"
})

ストレージ

メモは次の構造でnotes_storage.jsonに保存されます。

{
    "note_name": {
        "content": "Note content",
        "created_at": "2025-01-12T11:28:16.721704",
        "modified_at": "2025-01-12T11:28:16.721704"
    }
}

リソースアクセス

ノートにはnote:// URI スキームを使用してリソースとしてアクセスできます。

  • リソースの一覧表示: 利用可能なすべてのノートをリソースとして返します

  • リソースの読み取り: note://internal/note_nameを使用して特定のノートにアクセスします。

プロンプト生成

サーバーには、メモの要約のためのプロンプト生成機能が含まれています。

  • 簡潔な要約と詳細な要約の両方をサポート

  • 言語モデル入力のフォーマットノート

  • 「summarize-notes」プロンプトから利用可能

発達

サーバーを変更または拡張するには:

  1. リポジトリをクローンする

  2. 開発依存関係をインストールする

  3. 適切なモジュールに変更を加える

  4. 展開前に徹底的にテストする

テスト

テストでは以下をカバーします:

  • 基本的なCRUD操作

  • 複数のノートの取り扱い

  • エラーケース

  • リソースアクセス

  • プロンプト生成

ライセンス

[ここにライセンスを追加]

Available Tools

4 tools
add-noteC

Create a new note

ParametersJSON Schema
NameRequiredDescriptionDefault
contentYes
nameYes

TDQS

C2.8/5.0
Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. 'Create a new note' implies a write operation but doesn't specify permissions needed, whether it's idempotent, error handling, or what happens on success (e.g., returns a note ID). This leaves significant gaps for a mutation tool.

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, efficient sentence with zero wasted words. It's front-loaded and appropriately sized for a basic tool, though this conciseness comes at the cost of detail.

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?

For a mutation tool with 2 required parameters, 0% schema coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain what the tool returns, error conditions, or parameter semantics, leaving the agent poorly equipped to use it correctly.

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

Parameters2/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 documentation. The description adds no information about the 'content' and 'name' parameters—their meaning, format, constraints, or examples. This fails to compensate 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 'Create a new note' clearly states the action (create) and resource (note), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'update-note' or 'delete-note' beyond the basic verb, 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 like 'update-note' or 'list-all-notes'. There's no mention of prerequisites, context, or exclusions, leaving the agent to infer usage from the tool name alone.

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

delete-noteC

Delete an existing note

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYes

TDQS

C2.8/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, implying a destructive mutation, but fails to address critical aspects like permissions needed, whether deletion is permanent or reversible, error handling, or confirmation requirements. This is a significant gap for a mutation tool.

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, efficient sentence with no wasted words, making it easy to parse. It is appropriately sized for a simple tool, though this conciseness comes at the cost of detail in other dimensions.

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?

For a destructive mutation tool with no annotations, 0% schema coverage, and no output schema, the description is inadequate. It lacks essential context such as behavioral traits, parameter details, and output expectations, making it incomplete for safe and effective use by an agent.

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

Parameters2/5

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

The schema description coverage is 0%, and the description provides no information about the 'name' parameter beyond what the schema indicates (a required string). It doesn't explain what 'name' refers to (e.g., note title, ID, filename) or its format, leaving the parameter's meaning unclear.

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 ('Delete') and resource ('an existing note'), making the tool's function unambiguous. However, it doesn't distinguish this tool from its sibling 'update-note' in terms of destructive vs. non-destructive operations, which would require explicit differentiation for 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 like 'update-note' or prerequisites such as note existence. It lacks explicit context about usage scenarios or exclusions, leaving the agent to infer based on tool names alone.

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

list-all-notesB

Read all stored notes

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

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 full burden for behavioral disclosure. It states 'Read all stored notes,' which implies a safe, read-only operation, but fails to add context like whether it returns all notes at once, uses pagination, requires authentication, or has rate limits. This leaves significant gaps in understanding the tool's behavior.

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 'Read all stored notes' is a single, efficient sentence that front-loads the core purpose with zero waste. It is appropriately sized for a simple tool, making it easy for an agent to parse and understand quickly.

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 simplicity (0 parameters, no output schema, no annotations), the description is minimally adequate. It states the basic action but lacks details on behavior (e.g., return format, pagination) that would be helpful for a read operation, especially without annotations to cover safety or performance aspects.

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 tool has 0 parameters, with schema description coverage at 100%, so no parameter documentation is needed. The description appropriately doesn't mention parameters, aligning with the schema, and thus meets the baseline for a parameterless tool without adding unnecessary details.

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 'Read all stored notes' clearly states the verb ('Read') and resource ('all stored notes'), making the tool's purpose immediately understandable. It distinguishes from siblings like 'add-note' or 'delete-note' by specifying a read-only operation, though it doesn't explicitly contrast with potential filtering alternatives beyond the scope of siblings.

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 lacks context such as prerequisites, timing, or comparisons to other tools (e.g., if there are filtering options not listed as siblings), leaving the agent with minimal usage direction beyond the basic purpose.

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

update-noteC

Update an existing note

ParametersJSON Schema
NameRequiredDescriptionDefault
contentYes
nameYes

TDQS

C2.6/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 'update' implies a mutation, but it doesn't disclose any behavioral traits such as required permissions, whether the update is reversible, error handling, or rate limits. This is a significant gap for a mutation tool with zero annotation coverage, making it minimally transparent.

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, efficient sentence with zero waste. It's appropriately sized and front-loaded, directly stating the tool's purpose without unnecessary elaboration. This exemplifies conciseness, though it may be overly brief given the lack of other information.

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 of a mutation tool with no annotations, 0% schema coverage, and no output schema, the description is incomplete. It doesn't cover parameter meanings, behavioral aspects, usage context, or return values. This inadequacy makes it insufficient for effective agent use, as it leaves critical gaps in understanding.

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

Parameters2/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 details. The description adds no meaning beyond the tool name; it doesn't explain what 'content' and 'name' parameters represent, their formats, or how they interact. This fails to compensate for the lack of schema documentation, leaving parameters largely undocumented.

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 'Update an existing note' clearly states the verb ('update') and resource ('note'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'add-note' or 'delete-note' beyond the basic action, and it lacks specificity about what aspects of the note are updated. This makes it vague but adequate for minimum viability.

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., that a note must exist to update it), contrast with 'add-note' for creation or 'delete-note' for removal, or specify any context for usage. This absence of guidance leaves the agent without direction on tool selection.

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. 4 tool updatesv1.0.0
    • First observedadd-note
    • First observeddelete-note
    • First observedlist-all-notes
    • First observedupdate-note
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

B3.4/5.0

Scored across 4 tools

Disambiguation5/5

Each tool has a clearly distinct purpose targeting specific CRUD operations on notes: add-note for creation, delete-note for deletion, list-all-notes for reading all, and update-note for updates. There is no overlap in functionality, making tool selection unambiguous.

Naming Consistency4/5

The tools follow a mostly consistent verb-noun pattern (add-note, delete-note, update-note), but list-all-notes deviates slightly by including 'all'. This minor inconsistency does not significantly hinder readability or predictability.

Tool Count5/5

With 4 tools, the server is well-scoped for a notes management system, covering the essential CRUD operations. Each tool earns its place without being overly sparse or bloated, fitting the typical 3-15 tool range appropriately.

Completeness5/5

The tool set provides complete CRUD coverage for the notes domain: create (add-note), read (list-all-notes), update (update-note), and delete (delete-note). There are no obvious gaps, allowing agents to handle full note lifecycles without dead ends.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches