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