Skip to main content
Glama
enesjakozh
truaxki

MCP Notes Server

by truaxki
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

MCP Notes 서버

대장간 배지

영구 저장소를 사용하여 노트를 관리하기 위한 MCP(모델 컨텍스트 프로토콜) 서버 구현입니다.

특징

  • 메모 생성, 읽기, 업데이트 및 삭제

  • JSON을 사용한 영구 저장소

  • 생성 및 수정에 대한 타임스탬프 추적

  • 프롬프트를 통한 노트 요약

  • note:// URI 체계를 사용한 리소스 기반 액세스

Related MCP server: Beeper MCP Note Server

설치

Smithery를 통해 설치

Smithery를 통해 Claude Desktop용 메모를 자동으로 설치하려면:

지엑스피1

수동 설치

  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