Obsidian MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose with no significant overlap. For example, obsidian_append_content adds to the end of files, obsidian_patch_content inserts at specific locations, and obsidian_write_note offers multiple write modes. The tools cover different aspects of file operations (read, write, update, delete, search, metadata management) without ambiguity.
Naming Consistency5/5
All tools follow a consistent 'obsidian_verb_noun' naming pattern throughout. The verbs are descriptive (e.g., append, batch_get, delete, get, list, manage, patch, search, update, write), and the nouns clearly indicate the target resource (e.g., content, file_contents, frontmatter, tags, note). There are no deviations in style or convention.
Tool Count5/5
With 13 tools, the server is well-scoped for managing an Obsidian vault and Zettelkasten workflow. Each tool serves a specific, necessary function, from basic CRUD operations (read, write, update, delete) to advanced features like search, metadata management, and batch operations. The count is neither too sparse nor bloated for the domain.
Completeness5/5
The tool set provides comprehensive coverage for Obsidian vault management, including full CRUD for files (create, read, update, delete), metadata handling (frontmatter and tags), directory navigation, search, and specialized operations like patching and batch reads. There are no obvious gaps; agents can perform all essential workflows for note-taking and organization.
Average 4.4/5 across 13 of 13 tools scored.
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 status not available
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is not read-only, not open-world, not idempotent, and not destructive. The description adds useful behavioral context by specifying that it appends to the end of files and can create new files if needed, which goes beyond the annotations. However, it doesn't mention potential side effects like file creation behavior details 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 well-structured and appropriately sized: it starts with a clear purpose statement, provides usage context, details parameters with a structured Args section, specifies return values, and includes a practical example. Every sentence adds value without redundancy, and information is front-loaded effectively.
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 moderate complexity (file operations with creation fallback), the description covers purpose, usage, parameters, and returns adequately. The presence of an output schema means return values don't need explanation. However, for a tool that modifies files, more behavioral details (e.g., what happens if the file doesn't exist, encoding considerations) would enhance completeness.
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?
With 0% schema description coverage, the schema provides no parameter descriptions. The description compensates by listing both parameters (filepath and content) and their basic purpose in the Args section, adding meaningful semantics. However, it doesn't provide format details (e.g., filepath structure, content encoding) or constraints beyond what's implied, leaving some gaps.
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 purpose with specific verbs ('append content', 'create new file') and resource ('existing file'), distinguishing it from siblings like obsidian_patch_content (which patches rather than appends) and obsidian_write_note (which writes rather than appends). The opening sentence provides a precise, actionable summary.
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 provides clear context for when to use this tool ('Quick way to add content to notes', 'Useful for adding new thoughts, references, or connections to existing Zettelkasten notes'), which helps differentiate it from tools like obsidian_patch_content or obsidian_write_note. However, it doesn't explicitly state when NOT to use it or name specific alternatives, preventing a perfect score.
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?
Annotations already provide readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering safety and idempotency. The description adds valuable context by specifying it extracts 'YAML frontmatter' (format), mentions 'Zettelkasten notes' (context), and clarifies it doesn't load full content (performance/scope). No contradictions with annotations.
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 well-structured with clear sections (purpose, Args, Returns, Example) and front-loaded key information. It's concise but includes a slightly verbose example sentence that could be tighter.
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?
Given the tool's low complexity (1 parameter), rich annotations (covering safety and idempotency), and the presence of an output schema (implied by Returns section), the description is complete. It explains purpose, usage context, parameter role, and output format adequately without needing to detail return values.
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?
Schema description coverage is 0%, but the description compensates by explaining the single parameter 'filepath' in the Args section and providing an example use case. However, it doesn't add significant meaning beyond what's implied by the parameter name and basic schema constraints (e.g., path format or vault context).
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 specific action ('Extract YAML frontmatter metadata'), the resource ('from a note'), and distinguishes it from siblings by mentioning it reads metadata 'without loading the full content' (unlike obsidian_get_file_contents). It provides concrete examples of metadata types like tags and creation date.
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 explicitly states when to use it: to 'Read metadata... without loading the full content,' which differentiates it from content-reading tools like obsidian_get_file_contents. However, it doesn't explicitly mention when NOT to use it or name specific alternatives beyond the implied contrast.
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?
The description adds valuable behavioral context beyond annotations: it specifies that only frontmatter is modified while content is preserved, mentions the tool works with 'Zettelkasten notes,' and provides an example of the update format. Annotations already indicate this is a non-destructive, non-readonly operation, so the description appropriately supplements rather than contradicts them.
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 efficiently structured with a clear purpose statement, usage context, parameter explanation, return value, and example - all in well-organized paragraphs with zero redundant information. Every sentence adds value and is appropriately front-loaded.
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 moderate complexity (1 parameter with nested structure), lack of schema descriptions, and presence of output schema, the description provides good coverage of purpose, behavior, and parameter usage. The example helps clarify the updates format, though more detail on filepath validation or error cases would make it fully complete.
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?
With 0% schema description coverage, the description compensates by explaining the 'updates' parameter with examples ('tags', 'status', 'custom properties') and showing dictionary format. However, it doesn't fully document the 'filepath' parameter's requirements or provide comprehensive guidance on the updates dictionary structure beyond basic examples.
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 specific action ('Update YAML frontmatter metadata') and resource ('note content'), distinguishing it from siblings like obsidian_manage_tags or obsidian_patch_content by focusing exclusively on frontmatter updates without modifying note body content.
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 provides clear context about when to use this tool ('Add or update metadata fields like tags, status, or custom properties') and implicitly distinguishes it from content-modifying siblings by emphasizing 'without modifying note content.' However, it doesn't explicitly mention when NOT to use it or name specific alternative tools for related operations.
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?
Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, covering safety and idempotency. The description adds valuable context beyond this by specifying it reads 'complete contents... including frontmatter and body' and provides an example, though it doesn't mention error handling or file existence checks.
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-structured with a clear purpose statement, usage guidelines, parameter details, return value, and an example—all in four concise sentences. Each section adds value without redundancy, and information is front-loaded appropriately.
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?
Given the tool's low complexity (1 parameter), rich annotations covering safety and behavior, and the presence of an output schema (specifying return type as str), the description is complete. It adequately explains the tool's purpose, usage, parameters, and output without needing to duplicate structured data.
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?
Schema description coverage is 0%, but the description compensates by explaining the single parameter 'filepath' in the Args section and providing an example. However, it doesn't add significant meaning beyond what the schema's properties already define (e.g., path format, length constraints).
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 specific action ('Read the complete contents of a single file') and resource ('from the vault'), distinguishing it from siblings like obsidian_get_frontmatter (partial content) or obsidian_batch_get_file_contents (multiple files). The mention of 'Zettelkasten notes' provides domain-specific context.
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 provides clear context on when to use this tool ('to read existing Zettelkasten notes, understand their structure, and find connections for creating new atomic notes'), but does not explicitly state when not to use it or name alternatives like obsidian_get_frontmatter for partial content or obsidian_batch_get_file_contents for multiple files.
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?
Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false. The description adds valuable context beyond this: it clarifies the tool's efficiency ('Efficient way'), scope ('without reading full content'), and practical use case ('analyzing note collections'), which helps the agent understand behavioral traits not covered by annotations.
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-structured and front-loaded with the core purpose, followed by usage context, parameter details, return value, and an example. Every sentence adds value without redundancy, making it efficient and easy to parse.
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?
Given the tool's moderate complexity (single parameter, read-only operation), the description is complete. It covers purpose, usage, parameters, returns (noting JSON format), and includes an example. With annotations providing safety hints and an output schema existing, no additional behavioral or output details are needed.
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?
Schema description coverage is 0%, but the description includes an 'Args' section that documents the single parameter 'params' with its structure, including 'filepaths (List[str]): Paths to files (max 50)'. This adds meaning beyond the schema, but since there's only one parameter, the baseline is 4. However, the description could provide more semantic context (e.g., path format, note types).
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 purpose: 'Get metadata for multiple notes including tags, dates, and sizes.' It specifies the verb ('Get'), resource ('metadata for multiple notes'), and scope ('without reading full content'), distinguishing it from siblings like obsidian_get_file_contents (full content) and obsidian_get_frontmatter (specific metadata).
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 provides clear context for when to use this tool: 'Efficient way to get overview information about several Zettelkasten notes without reading full content. Useful for analyzing note collections.' It implicitly distinguishes it from content-reading tools but does not explicitly name alternatives or state 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering safety aspects. The description adds useful context about the scope ('specific vault directory') and example use case, though it doesn't mention rate limits or authentication needs beyond what annotations imply.
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-structured with purpose statement, usage guidance, parameter explanation, return value, and example - all in concise sentences that earn their place. No wasted words, and key information 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?
Given the tool's simplicity (1 parameter), comprehensive annotations, and existence of an output schema, the description provides complete context. It covers purpose, usage, parameters, returns, and examples without needing to duplicate what structured fields already provide.
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?
Schema description coverage is 0%, but the description compensates by explaining the single parameter dirpath as 'Relative path to directory (empty for root)' and providing an example. However, it doesn't add significant meaning beyond what's already implied by the parameter name and example.
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 purpose with specific verb ('List') and resource ('files and directories in a specific vault directory'), and distinguishes it from sibling tools like obsidian_list_files_in_vault by specifying directory-level listing rather than vault-wide listing.
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 provides clear context for when to use this tool ('to explore the contents of a specific folder') with concrete examples ('Zettelkasten directory or any other organized section'), but doesn't explicitly mention when not to use it or name specific alternatives from the sibling list.
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?
Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false. The description adds valuable behavioral context beyond annotations: it specifies that contents are concatenated with clear separators, mentions the maximum of 20 files, and explains the efficiency rationale for batch reading related notes. No contradiction with annotations.
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 well-structured with clear sections (purpose, Args, Returns, Example) and front-loaded key information. It's appropriately sized, though the example could be more concrete. Every sentence adds value without redundancy.
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?
Given the tool's moderate complexity, rich annotations (read-only, idempotent), and the presence of an output schema (returns str), the description is complete. It covers purpose, usage context, parameter semantics, and behavioral details like concatenation and limits, leaving output specifics to the schema.
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?
Schema description coverage is 0%, but the description compensates by explaining the 'filepaths' parameter in the Args section, including the max 20 constraint. However, it doesn't provide format details (e.g., path syntax, relative/absolute) or error handling. With one parameter documented, this meets the baseline for adequate 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 specific action ('Read multiple files at once, concatenated with headers') and distinguishes it from sibling tools like 'obsidian_get_file_contents' (single file) and 'obsidian_search' (search-based). It explicitly mentions the Zettelkasten context and purpose of understanding connections between notes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: 'Efficient way to read several related Zettelkasten notes together to understand connections and context before creating new atomic notes.' It distinguishes this batch operation from single-file reading and suggests it's for preparatory analysis of related notes.
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?
Annotations already declare readOnlyHint=false, destructiveHint=false, etc., covering basic safety. The description adds useful context about operating on 'note frontmatter' and the purpose ('organizing Zettelkasten notes'), but does not disclose additional behavioral traits like error handling, permissions needed, or effects on note structure beyond what annotations imply.
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-structured and front-loaded with the core purpose, followed by organized sections for Args, Returns, and Example. Every sentence adds value without redundancy, making it efficient for quick comprehension and reference.
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?
Given the tool's moderate complexity (managing tags with three actions), the description is complete: it covers purpose, parameters, return values, and examples. With an output schema present, it appropriately omits detailed return explanations, focusing on practical usage. No gaps remain for effective tool 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?
With 0% schema description coverage, the description fully compensates by detailing all parameters in the 'Args' section: it explains 'filepath', 'action' with its enum values, and 'tags' with optionality rules. This adds significant meaning beyond the bare schema, ensuring the agent understands parameter purposes and constraints.
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 purpose with specific verbs ('Add, remove, or list tags') and resource ('in note frontmatter'), distinguishing it from sibling tools like obsidian_update_frontmatter or obsidian_get_frontmatter. It further explains the organizational context ('for organizing Zettelkasten notes') to reinforce its distinct role.
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 provides clear context for when to use this tool ('Manage tags for organizing Zettelkasten notes... enabling efficient retrieval of related atomic notes'), but does not explicitly state when not to use it or name specific alternatives among siblings. The example section implicitly guides usage for different actions but lacks explicit comparisons.
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?
The description adds significant behavioral context beyond annotations, explaining the four distinct modes with their specific behaviors (e.g., CREATE is safe, OVERWRITE replaces entire file). Annotations provide basic hints (readOnlyHint=false, destructiveHint=false), but the description elaborates on operational details like default modes and safety characteristics, though it doesn't cover rate limits or auth needs.
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-structured and concise, with clear sections (purpose, modes, args, returns, example) and no wasted sentences. Each sentence adds value, such as explaining modes and providing a practical example, making it easy to scan and understand.
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 complexity (multiple modes, 1 parameter with nested object) and the presence of an output schema (returns str), the description is largely complete. It covers purpose, usage, parameters, and behavior, though it could benefit from more detail on error cases or frontmatter handling. The output schema reduces the need to explain return values.
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 description adds some parameter semantics by listing and briefly describing the four parameters (filepath, content, mode, frontmatter) and providing an example. However, with 0% schema description coverage, the schema lacks descriptions, so the description partially compensates but doesn't fully detail formats or constraints (e.g., filepath structure, content limits).
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 purpose with specific verbs ('Create or modify notes') and resources ('notes with content and optional frontmatter'), distinguishing it from siblings like obsidian_append_content by covering multiple modes. It explicitly identifies itself as the 'Primary tool for Zettelkasten note creation,' providing clear differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidelines by detailing four specific modes (CREATE, OVERWRITE, APPEND, PREPEND) with clear behavioral descriptions, including safety notes ('safe, won't overwrite' for CREATE). It distinguishes when to use this tool versus alternatives like obsidian_append_content by offering a comprehensive set of write operations in one tool.
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?
The description adds valuable behavioral context beyond annotations: it explicitly warns 'DESTRUCTIVE OPERATION' and notes 'Requires explicit confirmation,' which aligns with the destructiveHint=true annotation. However, it doesn't mention idempotentHint=true (deleting a non-existent file might succeed or fail), leaving some behavioral traits uncovered. No contradiction with annotations exists.
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 well-structured with clear sections (purpose, warning, usage, Args, Returns, Example) and front-loads key information. It's appropriately sized for a destructive tool, though the example sentence could be slightly more concise. Every sentence adds 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?
Given the tool's complexity (destructive operation with confirmation) and the presence of an output schema (Returns: str), the description is largely complete. It covers purpose, guidelines, parameters, and behavioral warnings, but could benefit from mentioning idempotency or error cases for a fully comprehensive view.
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?
With 0% schema description coverage, the description compensates by explaining both parameters in the Args section: 'filepath (str): Path to file/directory to delete' and 'confirm (bool): Must be True to proceed with deletion.' This adds clear meaning beyond the bare schema, though it doesn't detail constraints like maxLength for filepath.
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 specific action ('Delete a file or directory') and resource ('from the vault'), distinguishing it from sibling tools like obsidian_append_content or obsidian_update_frontmatter which modify content rather than remove files. The verb 'Delete' is precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool ('removing outdated or duplicate notes from your Zettelkasten') and includes a cautionary note ('Use carefully'). It also offers an example scenario ('Delete a duplicate note after merging content into another note'), which helps differentiate it from alternatives like obsidian_patch_content for modifications.
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?
Annotations already indicate read-only, non-destructive, and idempotent behavior, which the description does not contradict. The description adds valuable context beyond annotations by specifying that it returns a 'markdown-formatted list' and helps 'understand the organization and locate folders for Zettelkasten notes,' enhancing behavioral understanding without redundancy.
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-structured and concise, with three sentences that each serve a distinct purpose: stating the tool's function, explaining its utility, and detailing the return format with an example. There is no wasted text, and information is front-loaded effectively.
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?
Given the tool's simplicity (0 parameters, annotations covering safety, and an output schema implied by the description), the description is complete. It explains what the tool does, why to use it, and the return format, which is sufficient since the output schema handles return values. No gaps are present for this context.
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?
With 0 parameters and 100% schema description coverage, the baseline is 4. The description appropriately does not discuss parameters, as none exist, and instead focuses on the tool's output and purpose, adding meaningful context without unnecessary detail.
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 specific action ('List all files and directories'), target resource ('in the vault root'), and scope ('top-level structure'), distinguishing it from sibling tools like 'obsidian_list_files_in_dir' which would handle subdirectories. It explicitly mentions the purpose of understanding vault organization and locating folders for Zettelkasten notes.
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 provides clear context for when to use this tool ('List all files and directories in the vault root'), but does not explicitly state when not to use it or name alternatives. It implies usage for top-level exploration, which differentiates it from directory-specific listing tools, but lacks explicit exclusions or comparisons.
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?
Annotations provide readOnlyHint=false, destructiveHint=false, etc., but the description adds valuable behavioral context: the requirement to read files first to understand structure, the critical heading path format with examples of correct/incorrect usage, and specific examples for block and frontmatter targets. It doesn't contradict annotations and provides operational guidance beyond the basic safety hints.
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?
Well-structured with clear sections (purpose, args, returns, examples, notes). Every sentence earns its place by providing essential guidance. Slightly long due to extensive examples, but the examples are necessary for understanding the critical heading path requirement. The information is front-loaded with the core purpose first.
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?
Given the complexity of location-based patching with hierarchical paths, the description is complete: it covers purpose, all parameters with semantics, critical usage rules, examples for all target types, prerequisites (read first), and mentions the return value. With an output schema present, it doesn't need to detail return values further. The description compensates fully for the 0% schema coverage.
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 schema has descriptions but coverage calculation shows 0%), the description carries full burden and excels: it explains all 5 parameters in detail, provides critical format requirements for 'target' with hierarchical path examples, clarifies 'target_type' options with usage examples, and explains 'operation' behaviors. The description adds substantial meaning beyond the bare 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 clearly states the verb ('Insert content at specific locations') and resource ('within notes'), specifying the three location types (headings, blocks, frontmatter). It distinguishes from siblings like obsidian_append_content (which likely appends to entire files) and obsidian_write_note (which likely writes new files) by emphasizing targeted insertion at specific locations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: 'Always read the file first to see the exact heading structure before patching' establishes a prerequisite. The description distinguishes when to use this tool (for targeted insertion) versus alternatives like obsidian_append_content (for appending to entire files) by implication of its specific location targeting. The critical note about heading paths provides clear when-to-use criteria.
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?
Annotations already provide key behavioral hints (readOnlyHint: true, destructiveHint: false, idempotentHint: true), indicating a safe, non-destructive operation. The description adds valuable context beyond this: it specifies the search scope ('across your vault'), mentions the use of JsonLogic for flexibility, and provides documentation links and available variables ('path', 'content', 'stat'), enhancing transparency without contradicting annotations.
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-structured and appropriately sized. It front-loads the core purpose, follows with usage context, details parameters with examples, and concludes with documentation. Every sentence adds value—no redundancy or fluff—making it efficient and easy to parse for an AI agent.
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?
Given the tool's complexity (query-based searching), low schema coverage (0%), and presence of an output schema (returns a list of matching files), the description is highly complete. It covers purpose, usage, parameter details with examples, behavioral context, and external resources, leaving no gaps for the agent to understand and invoke 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?
The input schema has 0% description coverage, so the description fully compensates by detailing the parameter semantics. It explains that 'params' contains a 'query' field as a JsonLogic object, provides multiple examples with syntax and use cases, lists available variables, and includes a documentation link, adding significant meaning beyond the minimal 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 clearly states the tool's purpose: 'Search vault using powerful JsonLogic queries.' It specifies the verb ('search'), resource ('vault'), and method ('JsonLogic queries'), distinguishing it from sibling tools like 'obsidian_list_files_in_vault' or 'obsidian_get_file_contents' by emphasizing query-based searching rather than simple listing or content retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Essential for Zettelkasten workflow: find notes by patterns, content, tags, or complex criteria.' It distinguishes when to use this tool (for complex, query-based searches) versus alternatives like 'obsidian_list_files_in_dir' (directory listing) or 'obsidian_get_file_contents' (direct content access), and includes common examples to illustrate use cases.
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:

[![obsidian-mcp MCP server](https://glama.ai/mcp/servers/Shepherd-Creative/obsidian-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Shepherd-Creative/obsidian-mcp)

Score Badge

Copy to your README.md:

[![obsidian-mcp MCP server](https://glama.ai/mcp/servers/Shepherd-Creative/obsidian-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Shepherd-Creative/obsidian-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/Shepherd-Creative/obsidian-mcp'

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