笔记 + 书签，存储在单个 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.json在 mcpServers 下添加一个 vault 条目。如果文件中已有其他服务器，只需将此键与它们并列添加——不要替换整个文件。
{
"mcpServers": {
"vault": {
"command": "uv",
"args": [
"run",
"--directory",
"C:\\Users\\<you>\\mcp-vault",
"fastmcp",
"run",
"server.py"
]
}
}
}将 C:\\Users\\<你>\\mcp-vault 替换为你实际存放文件夹的位置——请使用如所示的双反斜杠。
完全退出（右键单击系统托盘图标 → 退出，而非仅关闭窗口）并重新打开。在聊天框中查找工具图标——点击它，你应该能看到列出的 5 个 vault 工具。
"保存一条笔记：更新护照，标签为 todo"
"保存此链接：https://example.com，标题为 Example，标签为 reference"
"我保存了什么标签为 todo 的内容？"
"搜索我的笔记中关于 passport 的内容"
"删除笔记 1"
你的数据存储在 server.py 旁边的 vault.db 中——它就是一个 SQLite 文件，因此你可以用任何 SQLite 浏览器直接打开查看。
每个工具的文档字符串是 Claude 决定何时调用它的依据——如果你重命名或重新调整工具用途，请务必保持文档字符串准确，这就是整个接口。
如果 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.
