vault-mcp

by Lincyaw

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Tools are mostly distinct with clear purposes, but vault_backlinks and vault_traverse (backward direction) both return incoming links, which could cause misselection. However, descriptions clarify the difference: backlinks is a direct lookup, while traverse explores the graph with depth.
Naming Consistency4/5
All tools share the vault_ prefix, and most follow a verb pattern (write, read, edit, delete, list, search, lint, traverse). However, vault_backlinks and vault_write_batch deviate from the verb-only convention, making the set slightly inconsistent.
Tool Count5/5
11 tools cover a complete note management workflow: CRUD, batch, search, list, lint, and graph exploration. The number is well-scoped, neither overwhelming nor thin.
Completeness5/5
The tool set provides full coverage of the vault lifecycle: create, read, update, delete, rename, batch operations, search, and health/link analysis. There are no obvious dead ends or missing core operations.
Average 4.2/5 across 11 of 11 tools scored. Lowest: 3.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It mentions deleting and removing from all indexes but does not state whether deletion is permanent, what happens to links or references, or any error conditions. For a destructive operation, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with one sentence for the action and one for the parameter. Every word earns its place, and it is front-loaded with the key verb and effect, avoiding any filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter delete tool, the description covers the main action and side effect. However, it does not mention the output/return behavior or possible failure modes. Given the presence of an output schema, some of this burden is reduced, but the lack of any operational context leaves room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the parameter description 'path: Note path to delete' adds clear meaning beyond the schema's bare 'Path' title. Although it lacks format details, it adequately compensates for the low schema coverage by clarifying the parameter's role.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete a note' with a specific verb and resource, and adds 'remove it from all indexes' which distinguishes it from sibling tools like vault_edit or vault_rename. This makes the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description reads as a simple command without context for deletion versus editing or renaming, and lacks any notes on prerequisites or irreversible consequences.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses behavioral details such as path root, depth levels, and type filtering, which are useful. However, it doesn't explicitly state whether the operation is read-only, what exactly is returned (note names vs. full contents), or edge cases like hidden files or invalid paths. For a listing tool, this is moderate coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a brief, front-loaded sentence followed by a clean args list. Every line is informative and necessary, with no fluff or repetition. The format is easily scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all three parameters and provides clear examples. The tool is relatively simple, and an output schema exists (so return format is not needed). It lacks explicit guidance on when to use this versus siblings, but given the tool's simplicity and the parameter documentation, it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions for parameters (0% coverage), and the description fully compensates by explaining each parameter with examples (e.g., path uses '"skill"' and '""' for root, depth default, type_filter examples). This adds significant meaning beyond the bare schema types and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Browse notes under a path') and the resource (notes in a vault). It distinguishes from siblings like vault_read (read a single note) and vault_search (search content), though it does not explicitly name alternatives. The verb 'browse' implies listing, which is distinct from other operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for parameters (e.g., path examples, depth default, type_filter usage) but does not explicitly state when to use this tool versus alternatives like vault_traverse or vault_search. Usage is implied through parameter explanations but not explicitly differentiated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It adds the behavioral detail that the tool returns both frontmatter and body, which is useful. However, it does not disclose error behavior (e.g., missing note), permissions, or that it is a read-only operation (inferred but not stated).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus an Args block. It front-loads the purpose, provides essential return info, and uses the example efficiently. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one parameter and an output schema available, the description covers the essential aspects: what it reads, what it returns, and how to specify the path. It lacks explicit edge-case handling (e.g., not found), but this is a minor gap given the tool's simplicity and the presence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining the 'path' parameter as a 'Note path' and providing an example ('concept/connection-pooling'). This gives clear semantic meaning beyond the schema's bare type and title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Read a note from the vault. Returns its frontmatter and body.' This uses a specific verb ('Read') and resource ('note from the vault'), and the return behavior is distinct from sibling tools like vault_write, vault_list, or vault_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus alternatives. While the description implies reading a specific note by path, it does not mention when to use vault_list or vault_search instead, nor does it exclude scenarios or provide context about prerequisites (e.g., note must exist).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It clearly states the read-only nature ('Find all notes') and the specific mechanism (wikilink matching), which is accurate and non-misleading. However, it does not disclose potential edge cases such as path resolution, case sensitivity, or whether the operation is safe (though 'find' implies no side effects). Given no annotations, the description adds a bit of context beyond the tool name but lacks rich behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: two sentences total, front-loaded with the main purpose. The 'Args:' block is directly relevant and adds necessary parameter context. There is zero wasted wording; every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one required parameter, an output schema, and a clear description, the tool definition is largely complete. Since the output schema exists, the description need not explain return values. It covers what the tool does and what the parameter means, but could briefly mention potential use cases or limitations for full completeness given the family of sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage—the 'path' property is only defined by its type. The description compensates with an explicit 'Args:' section stating 'path: Target note path.' This adds clear semantic meaning about the parameter's role. For a single-parameter tool, this is sufficient, though it could specify path format (e.g., absolute vs relative) for extra clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Find all notes that contain a [[wikilink]] to the given path.' This specifies a concrete verb ('find'), a resource ('notes with wikilinks'), and a target ('given path'). It distinguishes itself from siblings like vault_search by focusing specifically on backlink wikilinks rather than general search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied by the tool's name and description: use it to discover inbound wikilinks for a given note path. However, it provides no explicit guidance on when to prefer this over vault_search or vault_read, nor does it mention any exclusions or alternatives. The 'when to use' is left to the agent's inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral details. It explicitly mentions that all [[backlinks]] in other notes are rewritten automatically, which is a side-effect not derivable from the schema. This adds meaningful transparency, though it could also mention failure modes or reversible nature, so a 4 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus a terse Args list. It front-loads the core purpose, then adds the key behavioral note, and finally lists parameters. No wasted words, making it highly efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 required parameters, no annotations) and the presence of an output schema, the description covers the essential aspects: purpose, primary side-effect, and parameter semantics. It could add details about error handling (e.g., if old_path doesn't exist) but is otherwise complete for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for parameters, so the description must compensate. It does so with a simple 'Args' section defining 'old_path' as 'Current note path' and 'new_path' as 'New note path.' This adds basic meaning beyond parameter names but lacks constraints, format, or examples, making it sufficient but not rich.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Rename or move a note' with a specific verb and resource. It also highlights the key behavior of rewriting backlinks, distinguishing it from sibling tools like vault_write and vault_edit. This unambiguous purpose makes selecting the tool straightforward.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for renaming or moving notes but does not explicitly state when to use this tool over alternatives. It does not mention exclusions (e.g., when not to use) or compare with vault_edit or vault_write. The guidance is limited to the tool's obvious purpose, earning a mid-range score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It describes BFS traversal and the return shape, but does not explicitly state that the operation is read-only or free of side effects, nor does it address error handling or performance implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a purpose sentence, an Args block, and a Returns sentence. It is front-loaded and efficient, though the block format adds slight verbosity compared to a prose description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all parameters and the return shape, and an output schema exists so the details of returned nodes and edges are captured. It does not discuss edge cases like missing start nodes or cycles, but for an exploration tool with an output schema, it provides sufficient context for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema contains only parameter names and defaults, with no descriptions. The description compensates by defining 'start', 'depth', and 'direction', including the enumeration of direction values ('forward', 'backward', 'both'), providing clear semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Explore the link graph around a note via BFS traversal', which clearly identifies the tool's function and distinguishes it from simple backlink listing. The mention of forward/backward directions and directed edges further differentiates it from sibling tools like vault_backlinks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies its use case: when an agent needs to explore the connected structure of notes. However, it does not explicitly mention alternatives or exclusions, so guidance is clear but not fully comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. It clearly states that the tool finds dead links and orphan notes, which implies a read-only analysis. It does not explicitly say 'does not modify anything' or describe output format, but the verb 'check' and the specific findings are transparent enough for a zero-parameter tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the purpose and specifics without any waste. Every word earns its place, and the format is highly scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema, the description provides sufficient context: it names the exact issues identified (dead wikilinks and orphan notes). The output schema presumably covers the return structure, so no additional information is necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema already covers everything. The description adds no parameter-specific details, but with no parameters to explain, the schema coverage is complete. Baseline for zero parameters is 4, and the description does not miss anything.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Check vault health') and concrete outputs ('find dead [[wikilinks]] and orphan notes'). This distinguishes it from sibling tools like vault_search (searching) and vault_backlinks (link analysis), making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for health checking but does not explicitly mention when to use it vs alternatives or exclude other scenarios. While 'Check vault health' is clear context, there is no guidance on when to choose this over vault_search or vault_traverse, leaving the 'when' partially implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the operations and their behaviors (e.g., 'set_frontmatter (merge update)'), and notes that it 'Returns warnings if the edit introduces structural issues' — useful behavioral detail. However, it does not mention side effects, permissions, or failure modes beyond warnings.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well organized with a clear first sentence, an 'Args' section listing parameters, and a final note about return behavior. Every line adds necessary information; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool involves multiple operations with nested parameter schemas, and the description covers all of them explicitly. With an output schema present (indicated by context), the description need not explain return values beyond the warning behavior. Complete for invoking the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the schema is minimal (just types/names). The description fully compensates by explaining each parameter (path, operation, params) and provides per-operation parameter structures with examples (e.g., replace_string: {old, new}).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Apply an incremental edit') and a specific resource ('an existing note'), and distinguishes itself from siblings like vault_write ('without rewriting the full content').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool ('without rewriting the full content') but does not explicitly name alternatives or exclusions. It lacks direct comparison to siblings like vault_write or vault_write_batch.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the key atomicity behavior (all-or-nothing) and the structure of entries. It does not mention permissions or overwrite semantics, but atomicity is a critical non-obvious trait.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences plus a parameter breakdown. It front-loads the purpose and every sentence contributes value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch write tool, the description covers atomicity and parameter structure sufficiently. It does not explain overwrite behavior, but given the output schema exists and the sibling tool vault_write provides context, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines entries as an array of arbitrary objects, offering 0% coverage of its internals. The description compensates by explicitly stating each dict must have 'path', 'frontmatter', and 'body' keys, which is essential for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Write multiple notes atomically in a single transaction,' using a specific verb and resource while distinguishing from siblings like vault_write by emphasizing batch and atomicity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for batch atomic writes but does not explicitly name alternatives like vault_write for single notes or state when not to use this tool. Context is clear, but exclusions are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosure. It reveals that the tool overwrites existing notes, requires specific frontmatter fields (type, confidence), expects the body to start with '# Title', and returns warnings for structural issues. This is meaningful behavioral context, though it does not mention permissions, data loss explicitly, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-sentence purpose, a compact argument list, and a final sentence on return behavior. Every sentence earns its place, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a write operation with an output schema, the description covers the core action, all parameters, required metadata, and a return behavior (warnings). It does not mention potential error cases, prerequisites (e.g., vault root must exist), or whether directories are created, but given the simplicity of the tool, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only parameter names and types (body, path, frontmatter) with no descriptions. The description adds substantial meaning: path is relative to vault root with an example, frontmatter is a YAML dict with required fields, and body should start with a heading. This fully compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Create or overwrite a note in the vault.' This uses a specific verb and resource, distinguishing it from sibling tools like vault_read, vault_edit, and vault_delete. It unambiguously identifies 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by describing the action (create/overwrite a note), which tells the agent when to use this tool. However, it does not explicitly mention when not to use it or point to alternatives like vault_write_batch for batch operations or vault_edit for partial edits. Thus it has clear context but no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It explains the search modes, filter structure, default limit, and the shape of returned results, which is substantial behavioral detail. It doesn't cover edge cases like performance or error handling, but those are less critical for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: an introductory sentence plus a structured arg list and a return summary. Every line adds value without bloating, and the key action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is well-specified given its complexity. The description covers all parameters, modes, filters, and return fields, while the presence of an output schema presumably handles structural details. No significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero descriptions, so the description's parameter explanations are essential. It defines 'query', gives a filter example, describes mode with underlying technologies (FTS5, vector, hybrid), and states default limit, fully compensating for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Search the vault by keyword, semantic similarity, or both.' This clearly distinguishes it from sibling tools like vault_read and vault_list by emphasizing search with multiple modes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for when to use the tool (searching the vault) and explains the available modes and filtering. It does not explicitly mention alternatives or exclusion cases, but the sibling list makes the tool's niche evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![vault-mcp MCP server](https://glama.ai/mcp/servers/Lincyaw/vault-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Lincyaw/vault-mcp)

Score Badge

Copy to your README.md:

[![vault-mcp MCP server](https://glama.ai/mcp/servers/Lincyaw/vault-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Lincyaw/vault-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Lincyaw/vault-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server