메모 + 북마크를 단일 SQLite 파일에 저장하고, 5가지 도구를 통해 Claude에 제공합니다:
add_note, add_bookmark, search_notes, list_notes, delete_note.
PowerShell을 열고 다음을 실행하세요:
powershell -c "irm https://astral.sh/uv/install.ps1 | iex"이후 터미널을 닫고 다시 열어 uv가 PATH에 등록되도록 하세요.
Related MCP server: MCP Notes Server
이 폴더를 영구적인 위치(예: C:\Users\<사용자명>\mcp-vault)에 압축 해제하세요. 그런 다음 폴더 내부에서:
cd C:\Users\<you>\mcp-vault
uv sync이 명령어는 가상 환경을 생성하고 fastmcp를 설치합니다.
uv run fastmcp dev server.py이 명령어는 브라우저에서 MCP Inspector를 엽니다. Tools 탭을 클릭하고 add_note를 호출해 텍스트를 추가한 후 list_notes를 호출하면 저장된 내용이 표시됩니다. 확인이 끝나면 Ctrl+C로 중지하세요.
다음 파일을 열거나 생성하세요:
%APPDATA%\Claude\claude_desktop_config.jsonmcpServers 아래에 vault 항목을 추가하세요. 파일에 이미 다른 서버가 있다면 전체 파일을 덮어쓰지 말고 이 키만 함께 추가하세요.
{
"mcpServers": {
"vault": {
"command": "uv",
"args": [
"run",
"--directory",
"C:\\Users\\<you>\\mcp-vault",
"fastmcp",
"run",
"server.py"
]
}
}
}C:\\Users\\<사용자명>\\mcp-vault를 실제 폴더 경로로 바꾸세요 — 예시와 같이 이중 백슬래시를 사용하세요.
완전히 종료(트레이 아이콘 우클릭 → Quit, 창 닫기 아님)한 후 다시 실행하세요. 채팅 상자에서 도구 아이콘을 클릭하면 5개의 vault 도구가 표시됩니다.
"메모 저장: 여권 갱신, 태그는 todo"
"링크 저장: https://example.com, 제목은 Example, 태그는 reference"
"태그가 todo인 저장 내용 보기"
"메모에서 passport 검색"
"메모 1번 삭제"
데이터는 server.py와 같은 폴더에 있는 vault.db에 저장됩니다 — SQLite 파일이므로 SQLite 브라우저로 직접 열어 확인할 수 있습니다.
각 도구의 docstring은 Claude가 도구 호출 시점을 결정할 때 읽는 내용입니다 — 도구 이름이나 용도를 변경할 경우 docstring도 정확하게 업데이트하세요. 이것이 전체 인터페이스입니다.
Claude Desktop이 서버를 인식하지 못하면 %APPDATA%\Claude\logs\에서 오류를 확인하세요 — 대부분 설정 파일의 경로가 잘못된 경우입니다.
Save a link/bookmark to the vault.
title is required; note is an optional comment on why it's worth keeping.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| note | No | ||
| tags | No | ||
| title | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It indicates a write operation ('Save') but omits consequences such as idempotency, overwrite behavior, or error handling. The output schema exists but is not referenced, and no details about state changes or side effects are given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the primary action. Every sentence adds value: the first states the core function, the second clarifies which parameters are required and the purpose of 'note'. No redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the existence of an output schema, the description covers the basic purpose and two key parameters. However, it omits the 'url' and 'tags' parameters, and does not explain return values or behavior on duplicate URLs. It is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the 'title' parameter (required) and 'note' (optional comment), but does not mention the required 'url' parameter or the optional 'tags' array. Meaning is added for only half the parameters, and the critical 'url' is left undefined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Save a link/bookmark') and the target ('to the vault'). It specifies the resource type (link/bookmark) and distinguishes it from sibling tools like add_note, which are for notes. The verb 'save' is precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for saving web links, but lacks explicit guidance on when to use this tool versus alternatives (e.g., add_note for text). No when-not-to-use scenarios or prerequisites are mentioned. The context is clear enough for a simple tool, but the absence of explicit alternatives is a gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save a quick note or thought to the vault.
Use tags to make it easy to find later, e.g. ["work", "idea", "todo"].
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | ||
| content | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states 'Save a quick note or thought to the vault,' which is minimal. It does not mention whether the note is saved to a specific location, if it can be overwritten, any authentication needs, rate limits, or what the return value looks like (despite an output schema existing).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences and no superfluous words. Every sentence serves a purpose: the first states the action, the second gives a usage tip for tags.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters and an output schema, the description lacks completeness. It does not explain where in the vault the note is saved, if there are limits on content length, or the format of the response. The output schema exists but the description offers no context about it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It partially does by explaining tags: 'Use tags to make it easy to find later, e.g. ["work", "idea", "todo"].' However, it does not explain the 'content' parameter beyond being a note/thought, and no constraints or format details are provided. This partially compensates for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Save a quick note or thought to the vault.' It uses a specific verb ('save') and resource ('note/thought'), and distinguishes it from siblings like add_bookmark (bookmark), search_notes (search), list_notes (list), and delete_note (delete).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention scenarios where add_note is preferred over search_notes, list_notes, or delete_note, nor does it indicate prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a note or bookmark by its id number.
| Name | Required | Description | Default |
|---|---|---|---|
| item_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits like permanence, error handling, or auth requirements. It only says 'delete', implying mutation, but omits consequences such as irreversibility or missing id behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. However, the brevity sacrifices necessary detail; it is efficient but borderline under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even with an output schema, the description fails to cover critical context: permanent deletion, error behavior (missing id), and that it handles both notes and bookmarks without a way to differentiate. This leaves gaps for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage for item_id. The tool description adds 'by its id number', which is nearly redundant with the parameter name. It does not clarify the id's source, format, or disambiguation between note and bookmark ids.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'delete', the resource 'a note or bookmark', and the identification method 'by its id number'. It distinguishes well from sibling tools like add_note, add_bookmark (creation), and search_notes, list_notes (read).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, no prerequisites, and no mention of preconditions like id existence or permissions. The description simply states what it does without context for appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List recent notes and bookmarks, optionally filtered by a single tag.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description informs that results include both notes and bookmarks, and filtering is by a single tag only. This is useful behavioral context beyond the schema. As no annotations are provided, the description carries the full burden, and it adequately warns that any complex filtering or multiple tags would require a different tool like 'search_notes'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one compact sentence: 'List recent notes and bookmarks, optionally filtered by a single tag.' Every word is necessary and front-loaded with purpose. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With two simple parameters, an output schema present, and sibling tools providing contrast, the description covers the essential behavior. It could briefly note that 'limit' defaults to 20 (implied by schema but not described) or that results are sorted by recency, but given the tool's simplicity and available context, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers both parameters with defaults but has 0% description coverage, so the description must add value. The description explains that 'tag' filters by a single tag (not multiple) and implies 'limit' controls recency or count. This compensation makes the param intent clearer, earning a higher score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool lists recent notes and bookmarks with optional tag filtering. It specifies the resource and action distinctly, but doesn't explicitly differentiate from sibling tools like 'search_notes', which could cause slight ambiguity about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a 'list' operation for browsing recent items, contrasting with search or add functions from siblings. However, it lacks explicit when-to-use or when-not-to-use guidance, such as distinguishing from 'search_notes' for non-tag or more complex queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search notes and bookmarks by matching text in the content or tags. Use this when user wants to recall something, Prefer this over guessing.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only mentions searching by text in content or tags but omits critical traits like read-only nature, authentication requirements, pagination, or result limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, consisting of two sentences that front-load the purpose. The second sentence provides usage context, though it is slightly awkward. No unnecessary words, but could be more precise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, output schema exists), the description covers the basic purpose and scope. However, it does not mention whether results are ordered, limited, or how bookmarks are interleaved with notes, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It explains the query parameter implicitly by stating matching text in content or tags, but does not specify format, match type, or behavior for empty queries. The added value is minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches notes and bookmarks by matching text in content or tags, using a specific verb and resource. It distinguishes itself from siblings like add_note, list_notes, and delete_note by focusing on search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using the tool when the user wants to recall something, but it lacks explicit guidance on when not to use it or alternatives. 'Prefer this over guessing' is vague and does not provide concrete exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0add_bookmarkadd_notedelete_notelist_notessearch_notesScored across 5 tools
Each tool has a distinct purpose: adding notes vs bookmarks, searching across both, listing by tag, and deleting by ID. No two tools overlap in function, so an agent can easily select the correct one.
All tool names follow a consistent verb_noun pattern with lowercase and underscores: add_note, add_bookmark, search_notes, list_notes, delete_note. The pattern is uniform and predictable.
Five tools cover the essential operations for a note/bookmark vault (add two types, search, list, delete). The scope is well-defined and each tool serves a necessary role without bloat.
Core operations are covered: create (notes and bookmarks), read (search and list), delete. The only notable gap is the lack of an update/edit tool, but users can work around by deleting and recreating. This is a minor omission.
Persistent memory layer for AI tools. Save and recall notes across Claude and other MCP clients.
Google Keep-style notes app with an MCP server for AI agents to read/write notes.
Markdown-based note-taking with a hosted MCP server. Your notes serve you and your AI.
MCP-native notes and memory for ChatGPT, Claude, and other AI tools.
