AI 에이전트에 검색 가능한 마크다운 노트 보관소를 제공하는 MCP 서버입니다. YAML 스타일 프론트매터가 있는 .md 파일의 단일 디렉터리 위에서 동작하는 여섯 가지 도구를 제공합니다.
노트는 디스크에 일반 마크다운으로 저장됩니다. 데이터베이스에 잠겨 있는 것이 없으므로 동일한 파일을 편집기, grep, git에서 그대로 사용할 수 있습니다.
~/notes/
├── pad-thai.md
├── sourdough-starter.md
└── weekly-review.md도구 | 설명 |
| 노트를 생성합니다. 생성된 slug를 반환합니다. |
| slug로 노트 하나를 전체 읽습니다. |
| 요약(본문 제외)을 최신순으로 나열하며, 선택적으로 태그로 필터링합니다. |
| 스니펫이 포함된 관련도순 전체 텍스트 검색. |
| 제목/본문/태그를 패치합니다. slug는 변경되지 않습니다. |
| slug로 노트를 삭제합니다. |
Related MCP server: Memory MCP Server
npm install
npm run build클라이언트의 서버 구성에 추가하세요. Claude Desktop의 경우 claude_desktop_config.json에 추가합니다:
{
"mcpServers": {
"notes": {
"command": "node",
"args": ["/absolute/path/to/mcp-notes-server/dist/src/index.js", "--vault", "/absolute/path/to/notes"]
}
}
}보관소 디렉터리는 --vault <dir>, 그다음 $NOTES_VAULT, 그다음 ~/notes 순서로 결정됩니다. 시작 시 존재하지 않으면 생성됩니다.
slug는 정체성이며 검증됩니다. 노트는 <vault>/<slug>.md에 저장되며, 모든 slug는 파일 시스템에 도달하기 전에 /^[a-z0-9]+(?:-[a-z0-9]+)*$/ 정규식으로 검사됩니다. 이것이 read_note({slug: "../../.ssh/id_rsa"})를 단지 가능성이 낮은 것이 아니라 불가능하게 만듭니다. 이스케이프 방식이 아니라 허용 목록(allowlist) 방식입니다. slug는 업데이트 간에도 안정적입니다. 제목이 변경될 때 파일 이름을 바꾸면 모델이 이전 도구 호출에서 아직 보유하고 있는 slug가 무효화되기 때문입니다.
도구 오류는 예외가 아니라 데이터입니다. "slug X인 노트가 없습니다"는 isError: true가 포함된 일반 도구 결과로 반환되므로 모델이 이를 읽고 스스로 수정합니다. 예외로 던져졌다면 클라이언트는 프로토콜 오류를 보게 되며, 모델은 이를 복구할 수 없습니다. 실제 버그(VaultError가 아닌 모든 것)는 여전히 던져지므로 확실히 드러납니다.
검색은 가중치가 적용된 용어 빈도입니다. 제목의 용어는 3배, 태그의 용어는 2배로 계산되므로 sourdough를 검색하면 sourdough에 대한 노트가 지나가는 언급만 있는 노트보다 위에 순위가 매겨집니다. 의도적으로 단순하게 유지됩니다. 동기화할 인덱스가 없으며 수천 개 노트 규모의 보관소도 수 밀리초 안에 스캔됩니다.
보관소는 MCP에 대해 아무것도 알지 못합니다. src/vault.ts는 순수 파일 시스템 코드이고, src/server.ts는 MCP 바인딩이며, src/index.ts는 stdio 진입점입니다. 이러한 분리 덕분에 보관소는 직접 테스트할 수 있고 서버는 인메모리 전송을 통한 실제 MCP 클라이언트로 테스트할 수 있습니다. 하위 프로세스나 목(mock)이 필요 없습니다.
npm test # 46 tests, vitest
npm run typecheck # tsc --noEmit
npm run build # emit to dist/테스트는 보관소를 직접(test/vault.test.ts) 다루고, 서버는 InMemoryTransport를 통한 실제 MCP Client로 종단 간(test/server.test.ts) 테스트합니다. 따라서 도구 스키마, 인수 검증, 결과 형태가 모두 검증되며, 그 뒤의 로직만 검증되는 것이 아닙니다.
MIT
Create a new markdown note. Returns the generated slug, which is the identifier every other tool takes. Slugs are derived from the title and de-duplicated automatically.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | Markdown body of the note. | |
| tags | No | Lowercase topic tags used for filtering, e.g. ['recipes', 'thai']. | |
| title | Yes | Human-readable title for the note. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=false and idempotentHint=false, so the description carries the burden of explaining side effects. It discloses that a slug is generated, derived from the titlehol and de-duplicated automatically, which is beyond what annotations convey. It doesn't mention auth or rate limits, but for this simple create tool that's acceptable.
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?
Two sentences with zero fluff. The key facts (creates note, returns slug, slug derivation) are all present and front-loaded. No wasted words.
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?
Complete for a two-parameter create tool. It explains the return value (slug), its role with other tools, and the de-duplication behavior. No output schema exists, so the description carries that burden, and it does so well. Nothing an agent needs to call it correctly is missing.
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 coverage is 100% (body, title), so baseline is 3. The description adds value by explaining the relationship: slug derived from title and de-duplicated automatically. This clarifies the title parameter's role beyond its schema description. Body is straightforward.
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 (create) on the resource (markdown note) and immediately explains the key return value (slug). It distinguishes this tool from siblings (update, delete, search, read) by focusing on creation and the slug as the identifier for other tools.
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 this is the creation tool and explains the slug's role as the identifier that other tools use (read, update, delete). It doesn't explicitly list alternatives or exclusion criteria, but the purpose is unmistakable from the name and description, so this is firmly a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Permanently delete a note by slug. This cannot be undone.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Slug of the note to delete. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already include destructiveHint=true and readOnlyHint=false, and the description adds meaningful behavioral context with 'Permanently delete' and 'This cannot be undone.' It does not contradict the annotations, though it could go further by noting behavior for nonexistent slugs or permission requirements.
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?
Two short sentences with no filler. The key fact—permanent deletion—is front-loaded, and irreversibility is stated immediately. Every word earns its place.
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?
For a single-parameter destructive operation with annotations already signaling destructive and read-only characteristics, the description is complete enough. The agent knows what happens, what identifier is required, and the irreversible consequence.
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 100%, and the parameter slug is already described in the schema. The description only restates 'by slug' without adding additional meaning or format details, so it stays at the baseline for a fully documented schema.
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 states a specific verb ('delete'), a specific resource ('note'), and the exact key ('by slug'). This clearly distinguishes it from siblings like create_note, read_note, update_note, and list_notes.
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 is given about when to use this tool versus alternatives, such as update_note for modifying a note or search_notes for finding one. The description only implies destruction but provides no exclusions, prerequisites, or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List note summaries (no bodies), most recently updated first. Use this to get your bearings before reading or searching.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | Only return notes carrying this tag. | |
| limit | No | Max notes to return. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true already covering the safety profile, the description adds value by disclosing that responses contain only summaries (no bodies) and are sorted by recency. This is concrete behavioral context beyond the annotation; it does not describe pagination or the contents of a summary, which keeps it from a 5.
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?
Two sentences with no redundancy: the first packs the operation, output scope, and sort order; the second adds a single piece of usage guidance. Every clause earns its place, and key facts are front-loaded.
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?
For a two-optional-parameter list tool with a read-only annotation, the description covers the core invocation needs: what is returned (summaries), what is excluded (bodies), and ordering. The only gap is that 'summaries' is not defined (e.g., which fields appear), and there is no output schema to compensate, so it is not a 5.
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 100%: both 'tag' and 'limit' have clear inline descriptions, so the schema carries the parameter documentation. The tool description itself adds no parameter-level meaning, matching the baseline of 3 for high 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 states a clear verb ('list'), resource ('notes'), and immediately scopes the result to 'summaries (no bodies)', which differentiates it from read_note and search_notes. It also pins the ordering to 'most recently updated first', leaving no ambiguity about what the tool does.
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?
'Use this to get your bearings before reading or searching' explicitly frames when to call it, positioning it as the orientation step ahead of content retrieval and search. It implies but does not explicitly name the sibling alternatives (read_note for full bodies, search_notes for search), so it stops short of a full when-not/alternatives breakdown.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a single note in full, by slug.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Slug of the note, e.g. 'pad-thai'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description doesn't need to state that it's a read operation. The description adds that it reads 'in full' and uses a slug, which is useful but minimal. No side effects or limitations are mentioned, but the read-only nature is already covered.
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?
A single, front-loaded sentence conveys exactly what the tool does without any filler. Every word earns its place.
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?
For a simple read operation with one parameter and readOnlyHint annotation, this is nearly complete. The description tells the agent the key input and outcome. Lack of an output schema is acceptable because 'in full' implies the entire note. Minor gaps like error handling or not-found behavior are not critical for a straightforward read.
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 coverage is 100% with a clear description of the slug parameter. The description merely reiterates 'by slug', adding no new semantic detail beyond the schema. Baseline 3 is appropriate since the schema does the heavy lifting.
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 verb (read), the resource (a single note), and the scope (in full, by slug). It distinguishes itself from siblings like list_notes (multiple notes) and search_notes (query-based) by specifying 'single note' and the unique identifier 'slug'.
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 gives clear context: use this tool when you have a slug and want the entire note. However, it does not explicitly mention when not to use it (e.g., for listing or searching) or name alternatives, so it lacks exclusions. Still, the intended use is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full-text search over titles, tags, and bodies. Returns ranked hits with a snippet; matches in the title or tags outrank matches in the body.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max hits to return. | |
| query | Yes | Search terms, whitespace separated. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint already indicates read-only behavior. The description adds valuable details about return format (ranked hits with snippets) and ranking rules (title/tag matches outrank body matches), enhancing transparency beyond the annotation.
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?
Two concise sentences with no redundancy. Each phrase contributes meaning (search scope, return type, ranking rule), achieving high information density without clutter.
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?
Combined with the schema and annotation, the description covers purpose, return behavior, and ranking logic. An agent has sufficient information to invoke the tool correctly, including expected output format and ranking priority.
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 input schema already provides descriptions for both parameters ('query' and 'limit'). The tool description does not add parameter-specific semantics beyond what is already documented, so it only meets the baseline for a fully covered schema.
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 a specific verb ('search'), resource ('notes'), and scope ('over titles, tags, and bodies'). It distinguishes from sibling tools like list_notes by emphasizing full-text search and ranking, making the purpose unambiguous.
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 when to use the tool (for content-based search) but does not explicitly contrast with alternatives (e.g., 'use list_notes to retrieve all notes'). It is clear enough for an agent to infer the appropriate scenario, though explicit guidance would be stronger.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Replace the title, body, and/or tags of an existing note. Omitted fields are left untouched. The slug never changes.
| Name | Required | Description | Default |
|---|---|---|---|
| body | No | New markdown body, replacing the old one. | |
| slug | Yes | Slug of the note to update. | |
| tags | No | New tag list, replacing the old one. | |
| title | No | New title. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the operation is destructive and not read-only, and the description reinforces this by saying fields are 'replaced.' It adds valuable behavioral detail beyond the annotations: omitted fields are left untouched and the slug never changes, which clarifies partial-update semantics and identity stability.
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?
Three short sentences, no filler. The first sentence states the operation and scope, the second clarifies the partial-update behavior, and the third removes a common concern about identifier changes. Every sentence earns its place.
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?
For a simple 4-parameter mutation tool with full schema coverage and no output schema, the description covers the essential behavioral contract: what can be changed, what is preserved, and what remains stable. Nothing critical is missing for an agent to invoke the tool correctly.
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 coverage is 100%, so the baseline is 3, but the description adds meaning by grouping 'title, body, and/or tags' as optional replacement fields and specifying that the slug is immutable. This helps an agent understand that omitting a field means preserving its current value, which the schema alone does not convey.
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 uses a specific verb ('Replace') with a clear resource ('an existing note') and names the exact fields that change: title, body, and/or tags. It is instantly distinguishable from the sibling tools create_note, read_note, list_notes, search_notes, and delete_note.
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 clearly situates the tool as a mutation of an existing note, which implicitly excludes creation, reading, listing, searching, and deletion. It does not explicitly name alternatives or state when not to use it, but the context is clear enough for agent selection.
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.0create_notedelete_notelist_notesread_notesearch_notesupdate_noteScored across 6 tools
Each tool has a distinct purpose: create, read, list, search, update, and delete notes. No two tools overlap in functionality, and the descriptions clearly differentiate them.
All tool names follow a consistent verb_noun pattern (create_note, read_note, list_notes, search_notes, update_note, delete_note), making the API predictable and easy to navigate.
With 6 tools covering the full CRUD lifecycle plus listing and search, the set is well-scoped for a notes server. No redundant or missing tools; each earns its place.
The tool surface provides complete coverage for note management: create, read, list, search, update, and delete. There are no obvious dead ends or missing operations for the intended domain.
Markdown notes and whiteboards your AI agent can read and write.
Markdown notes in folders, with files, that your AI assistant can read, write and organise.
Markdown notes in folders, with files, that your AI assistant can read, write and organise.
Search, read, and safely update Markdown notes in your connected Phasoric knowledge vaults.
