This server is a tiny personal MCP vault for storing and retrieving notes and bookmarks in a SQLite database.
add_note: Save a quick note or thought, optionally with tags (e.g., work, todo).
add_bookmark: Save a link/bookmark with a required URL and title, plus optional note and tags.
search_notes: Search saved notes and bookmarks by matching text in content or tags.
list_notes: List recent notes and bookmarks, optionally filtered by a single tag, with a configurable limit.
delete_note: Delete a note or bookmark by its numeric id.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP-Vault save a note: buy groceries, tag it personal"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Notes + bookmarks, stored in a single SQLite file, exposed to Claude through 5 tools:
add_note, add_bookmark, search_notes, list_notes, delete_note.
Open PowerShell and run:
powershell -c "irm https://astral.sh/uv/install.ps1 | iex"Close and reopen your terminal after this so uv is on PATH.
Related MCP server: MCP Notes Server
Unzip this folder somewhere permanent, e.g. C:\Users\<you>\mcp-vault. Then from inside it:
cd C:\Users\<you>\mcp-vault
uv syncThis creates a virtual environment and installs fastmcp.
uv run fastmcp dev server.pyThis opens the MCP Inspector in your browser. Click into the Tools tab, try calling
add_note with some text, then list_notes — you should see it come back. Ctrl+C to stop
it once you're happy.
Open (or create) this file:
%APPDATA%\Claude\claude_desktop_config.jsonAdd a vault entry under mcpServers. If the file already has other servers in it, just
add this key alongside them — don't replace the whole file.
{
"mcpServers": {
"vault": {
"command": "uv",
"args": [
"run",
"--directory",
"C:\\Users\\<you>\\mcp-vault",
"fastmcp",
"run",
"server.py"
]
}
}
}Replace C:\\Users\\<you>\\mcp-vault with wherever you actually put the folder — use
double backslashes as shown.
Fully quit it (right-click the tray icon → Quit, not just closing the window) and reopen. Look for the tools icon in the chat box — click it and you should see the 5 vault tools listed.
"Save a note: renew passport, tag it todo"
"Save this link: https://example.com, title it Example, tag it reference"
"What have I saved tagged todo?"
"Search my notes for passport"
"Delete note 1"
Your data lives in vault.db right next to server.py — it's just a SQLite file, so you
can open it with any SQLite browser if you want to poke at it directly.
Every tool's docstring is what Claude reads to decide when to call it — if you rename or repurpose a tool, keep the docstring accurate, that's the whole interface.
If Claude Desktop doesn't pick up the server, check %APPDATA%\Claude\logs\ for errors —
usually it's a wrong path in the config.
Manal Manzoor Software Engineering Student COMSATS University Islamabad, Wah Campus
GitHub: @manalmanzoor
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.
