Manages feature documentation and bug tracking inside an Obsidian vault, organized by project.
Click on "Install 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., "@obsidian-vault-mcp list my projects"
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.
A stdio MCP server for managing feature documentation and bug tracking inside an Obsidian vault, organised by project.
npm install
npm run buildRelated MCP server: Obsidian MCP
Set VAULT_PATH to the root of your Obsidian vault:
VAULT_PATH=/path/to/vault node dist/index.jsAdd to ~/.omp/agent/mcp.json:
"obsidian-vault": {
"command": "node",
"args": ["/absolute/path/to/obsidian-vault-mcp/dist/index.js"],
"env": { "VAULT_PATH": "/path/to/your/obsidian/vault" }
}Tool | Description |
| List all projects in the vault |
| Write a feature doc under a project (optional |
| List feature docs, optionally filtered by project and/or |
| File a new bug under a project (optional |
| Get the highest-priority open bug |
| Read a bug or feature note's full frontmatter and content by path — bug vs. feature is auto-detected from the note's own |
| Update a bug or feature note in place by path (type auto-detected). |
| List bugs filtered by project, status, |
Bugs and feature docs both accept optional tags: string[] (grouping labels, e.g. ["wf:payments-v2-migration"]) and links: string[] (absolute paths to related vault notes — e.g. pairing a resolved ticket with the note that recorded its answer).
Bugs additionally accept blocked_by: string[] (absolute paths to bug notes that must reach a terminal status — resolved or out-of-scope — before this one is workable) and ticket_type: string (descriptive only, e.g. research, grilling, task). list_bugs computes an unblocked field per bug and supports unblocked: true to filter to the frontier (open + not blocked). None of these fields are validated for existence — callers are trusted, matching shortcut_card/shortcut_branch.
A bug note's file path never changes across status transitions — update_note only rewrites frontmatter, never moves the file — so a blocked_by reference recorded while the blocker is open stays valid once it resolves. (Earlier versions relocated resolved/out-of-scope bugs into a Bugs/Resolved/ subfolder; this broke blocked_by when the blocker moved out from under an existing reference. list_bugs still scans Bugs/Resolved/ recursively for backward compatibility with any notes relocated before this fix, but no new relocations happen.)
<vault>/
Projects/
<ProjectName>/
Features/<slug>.md
Bugs/<slug>.mdRead the full content and metadata of a bug note by its file path
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute path to the bug note file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a read-only operation via 'Read', which is transparent given no annotations. However, it omits details on authentication, rate limits, or whether any side effects occur beyond reading.
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 extraneous words. It is concise, though it could benefit from a brief additional sentence on return structure without losing brevity.
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 lack of an output schema, the description does not detail the return format (e.g., fields of metadata). For a simple read tool with one parameter, 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?
The single parameter 'path' has a clear schema description ('Absolute path to the bug note file'), and the description adds no new meaning beyond that. With 100% schema coverage, a baseline of 3 is appropriate.
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 'bug note', and the method 'by file path'. It distinguishes from sibling tools like 'list_bugs' (listing) and 'update_bug_status' (updating).
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 when needing full content and metadata of a specific bug note, but lacks explicit guidance on when not to use it or alternatives like 'get_next_bug'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the full content and metadata of a feature document by its file path
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute path to the feature doc file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It indicates a non-destructive read but omits details like return format or any side effects.
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?
Single sentence, no fluff, directly communicates core functionality.
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?
Adequate for a simple read tool with one parameter, but missing return value information since no output schema exists.
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% and already describes 'path' as 'Absolute path to the feature doc file'. The description does not add meaning beyond the 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 the action (Read), the resource (feature document), and the method (by file path). It distinguishes from siblings like list_features (which likely only lists paths) and write_feature_doc.
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 explicit guidance on when to use this tool vs. alternatives like list_features. No mention of prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the highest-priority open bug, optionally scoped to one project
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | Project name — defaults to "all projects" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It states 'highest-priority open bug' but fails to explain what determines priority, whether the operation is read-only, or what happens if no bugs exist. This leaves significant behavioral gaps.
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?
Single sentence with no fluff. It effectively communicates the core purpose. Slightly minimal but appropriate for the tool's simplicity.
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 no output schema, the description should hint at return value but does not. It also omits details on priority resolution and edge cases like empty results. Incomplete for a tool with only a description (no annotations) to rely on.
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% for the single parameter, which already explains the default. The description adds the phrase 'optionally scoped' but does not add meaning beyond the schema. Baseline of 3 is appropriate.
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 retrieves the highest-priority open bug, with optional project scoping. This distinctively separates it from siblings like get_bug (specific bug by ID) and list_bugs (list all bugs).
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?
Usage is implied: use when you need the top-priority bug. No explicit alternatives or exclusions are mentioned. While the optional project parameter gives context, it does not guide when not to use or compare to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List bugs in the vault, optionally filtered by project and/or status
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Filter by status | |
| project | No | Project name — defaults to "all projects" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It indicates the tool lists bugs with optional filtering but does not disclose pagination, default behavior, or any side effects. Adequate but minimal.
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?
Single sentence under 20 words, front-loaded with essential information. Every word adds value; no verbosity.
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 list tool with no output schema, the description is largely complete. Missing details on return format or pagination, but given the simple nature, it is adequate.
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 covers 100% of parameters with descriptions. The description adds no new meaning beyond what is already in the schema (e.g., project defaults, status enum). Baseline score of 3 is appropriate.
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?
Clearly states the verb ('List'), resource ('bugs in the vault'), and optional filters ('by project and/or status'). Distinguishes from siblings like get_bug (single bug) and list_projects (projects).
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 explicit guidance on when to use this tool versus alternatives such as get_bug, list_features, or write_feature_doc. The description only notes optional filters but does not specify context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List feature documents in the vault, optionally scoped to one project
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | Project name — defaults to "all projects" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavior. It only states 'list', which implies a read operation, but lacks details on permissions, rate limits, pagination, or return format. Minimal behavioral insight.
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 clear sentence, 11 words, front-loaded with the action. No unnecessary words, perfectly concise.
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 list tool with one optional parameter and no output schema, the description adequately defines scope and purpose. It could mention the return type (e.g., list of document IDs or objects) but is otherwise complete for the tool's low complexity.
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 single parameter 'project' is described in the schema with default behavior. The description reinforces this by stating 'optionally scoped to one project'. With 100% schema coverage, baseline 3 is appropriate; no additional semantic value beyond 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 the action (List), resource (feature documents), and scope (vault, optionally by project). It distinguishes itself from siblings like list_bugs and list_projects by specifying 'feature documents'.
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 project parameter ('optionally scoped'), but does not provide explicit guidance on when to use this tool over alternatives like list_bugs or list_projects, nor does it specify when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all project names in the Obsidian vault
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description implies a read-only operation but does not specify return format, ordering, or behavior if vault is empty.
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?
Single sentence, front-loaded, no unnecessary words. Perfectly concise for a simple tool.
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?
Lacks output schema or description of return format; agent may not know if result is array of strings or objects. Otherwise complete for a parameterless list.
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?
No parameters in schema, so description adds nothing about parameters. Baseline for 0 parameters is 4, and the description is adequate.
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?
Description clearly states the action 'List' and the resource 'all project names in the Obsidian vault', distinguishing it from sibling tools like list_bugs and list_features.
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 vs alternatives (e.g., list_features, list_bugs). The agent must infer based on the resource alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update the status of a bug note by its file path
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute path to the bug note file | |
| status | Yes | New status |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description does not disclose behaviors such as whether the status is overwritten, what happens if the path is invalid, or any side effects. The description carries the full burden but adds minimal insight.
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, front-loaded sentence with no waste. Every word is necessary.
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?
While the tool is simple (2 params, no output schema), the description lacks critical context such as error handling, whether the file is validated, or behavior when status is same as current. Adequacy is lacking.
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%, so baseline is 3. The description adds no additional meaning beyond what the schema already provides for both parameters.
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 'Update', the resource 'status of a bug note', and the identifier 'by its file path'. It is specific and distinguishes from siblings like get_bug, write_bug, list_bugs.
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 guidance on when to use this tool versus alternatives. It does not specify prerequisites or context for status updates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
File a new bug in the vault under a specific project
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Bug title | |
| project | No | Project name — derive from the git remote name of your working directory (e.g. git remote get-url origin | sed 's|.*/||;s|\.git$||') or use the folder name as fallback | |
| priority | No | Priority 1–N where 1 is highest (default 3) | |
| description | Yes | Bug description in markdown | |
| shortcut_card | No | Shortcut card URL (optional) | |
| shortcut_branch | No | Shortcut helper branch name (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It only states 'file a new bug' but omits side effects (e.g., whether it creates a permanent record), authentication needs, or return value. The agent lacks insight into the tool's behavior beyond its write nature.
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, well-structured sentence that conveys the core purpose without waste. It is concise and efficient, though a bit more detail could be added without harming conciseness.
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 6 parameters, no output schema, and no annotations, the description is incomplete. It does not explain what happens upon success (e.g., returns bug ID), error conditions, or relationships to sibling tools like list_projects for obtaining the project name.
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 has 100% coverage with detailed descriptions for each parameter, including derivation instructions for 'project' and default for 'priority'. The tool description adds no additional meaning beyond the schema, so a baseline score of 3 is appropriate.
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 ('file a new bug') and the target ('in the vault under a specific project'). It distinguishes from sibling tools like list_bugs and get_bug by emphasizing creation. However, it lacks an explicit differentiation statement.
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 provided on when to use this tool versus alternatives like write_feature_doc or update_bug_status. The description does not include any context about prerequisites, typical workflow, or exclusion scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write a feature document to the vault under a specific project
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Feature title | |
| content | Yes | Feature description in markdown | |
| project | No | Project name — derive from the git remote name of your working directory (e.g. git remote get-url origin | sed 's|.*/||;s|\.git$||') or use the folder name as fallback |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool 'writes' but does not disclose whether it creates new or overwrites existing documents, required permissions, side effects, or error conditions. This lacks essential behavioral context.
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 that is front-loaded with the verb and resource. It is concise, but could be slightly more structured to include usage notes or behavioral details without adding much length.
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 lack of annotations, output schema, and complex parameters, the description does not cover important aspects like return value, confirmation, error handling, or idempotency. It feels incomplete for a write operation that might have side effects.
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?
Input schema has 100% description coverage for all 3 parameters, so the schema already explains each parameter. The description adds only the context of writing 'to the vault under a specific project', which is already implied by the project parameter description. Minimal added value.
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 'Write' and clearly identifies the resource ('feature document') and location ('vault under a specific project'). It effectively distinguishes from sibling tools like 'write_bug' and 'list_features' by focusing on creating a feature doc.
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 writing feature documents to a project, but does not provide explicit guidance on when to use this tool versus alternatives (e.g., 'write_bug' or 'get_feature_doc'). No when-not-to-use or precondition information is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct operation on either bugs or features, with no overlap. Bug tools are separated by function (create, read by path, list, get highest priority, update status), and feature tools are similarly distinct.
All tool names consistently follow the verb_noun pattern using snake_case, e.g., list_bugs, write_feature_doc, update_bug_status. No mixed conventions or vague verbs.
9 tools is well-scoped for a project management vault MCP, covering both bugs and features with essential operations. The number feels neither too thin nor excessive.
Bugs have create, read (multiple forms), and update status, but no delete. Features have create and read, but no update or delete. These are notable gaps that could hinder agent workflows requiring full lifecycle operations.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Opinionated sprint tracker. Read/update tickets, sprints, velocity from Claude/Cursor/Zed.
Create and manage MeisterTask projects, tasks, and notes from your AI assistant.
Minimal project management for teams and AI agents.
Search your Obsidian vault to quickly find notes by title or keyword, summarize related content, a…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Lithial/obsidian-vault-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
