Advanced Obsidian MCP Server

by ToKiDoO

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: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, but there is some overlap between obsidian_simple_search and obsidian_complex_search that could cause confusion. The descriptions help differentiate them, but both are search tools with similar naming, which might lead to misselection if an agent isn't careful. Other tools like obsidian_append_to_file and obsidian_patch_file are clearly distinct in their file modification roles.
Naming Consistency5/5
All tool names follow a consistent snake_case pattern with the prefix 'obsidian_' followed by a descriptive verb_noun combination. This uniformity makes the tools predictable and easy to understand, such as obsidian_list_files_in_dir, obsidian_delete_file, and obsidian_get_active_note. There are no deviations in naming conventions across the set.
Tool Count4/5
With 16 tools, the count is slightly high but reasonable for an advanced Obsidian server that aims to provide comprehensive vault management. It covers a wide range of operations from file CRUD to search and vault analysis, though it might feel a bit heavy compared to simpler servers. Each tool appears to have a specific role, justifying its inclusion without excessive redundancy.
Completeness5/5
The tool set provides complete coverage for managing an Obsidian vault, including CRUD operations (e.g., obsidian_put_file, obsidian_delete_file), search capabilities (simple and complex), file navigation (list, open), vault understanding, and specialized features like periodic notes and command execution. There are no obvious gaps; agents can perform all typical workflows without dead ends.
Average 3.2/5 across 16 of 16 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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but lacks behavioral details. It states 'Append content' implying mutation, but doesn't disclose permissions needed, whether appending is additive or destructive to existing content, error handling (e.g., if file doesn't exist), or rate limits. This is a significant gap for a mutation tool with zero annotation 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 single, efficient sentence with zero waste. It front-loads the core action ('Append content') and target, making it easy to parse. Every word earns its place, achieving maximum clarity with minimal length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation operation with 2 parameters), no annotations, and no output schema, the description is incomplete. It lacks details on behavioral traits, error conditions, return values, and differentiation from siblings. For a tool that modifies files, this minimal description leaves critical gaps for an AI agent.
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 100%, so the schema fully documents both parameters (filepath and content). The description adds no additional meaning beyond what the schema provides, such as format details or usage examples. Baseline 3 is appropriate when the schema does the heavy lifting, but no extra value is contributed.
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 clearly states the action ('Append content') and target ('to a new or existing file in the vault'), specifying the verb and resource. It distinguishes from siblings like obsidian_delete_file (deletion) and obsidian_patch_file (partial update), though not explicitly named. However, it doesn't fully differentiate from obsidian_put_file (which might overwrite vs. append), leaving some ambiguity.
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?
The description provides no guidance on when to use this tool versus alternatives like obsidian_put_file (for overwriting) or obsidian_patch_file (for partial updates). It mentions 'new or existing file' but doesn't clarify prerequisites (e.g., file must exist for appending vs. creation) or exclusions, offering only implied usage without explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. While it states the action ('Delete'), it doesn't mention critical details like whether deletion is permanent, requires specific permissions, affects linked files, or has safety mechanisms (e.g., the 'confirm' parameter implies a safeguard, but this isn't explained). 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 a single, clear sentence with zero wasted words. It front-loads the core action ('Delete') and efficiently specifies the target ('a file or directory from the vault'), making it easy to parse quickly. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature, lack of annotations, and absence of an output schema, the description is insufficient. It doesn't address behavioral risks (e.g., permanence, error handling), usage context relative to siblings, or expected outcomes. For a deletion tool with no structured safety hints, more completeness is needed to guide safe agent use.
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 100%, so the input schema already fully documents both parameters ('filepath' and 'confirm'). The description adds no additional meaning beyond what's in the schema, such as clarifying path formats or the rationale for the confirmation requirement. This meets the baseline for high schema coverage but doesn't enhance understanding.
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 clearly states the verb ('Delete') and resource ('a file or directory from the vault'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'obsidian_put_file' (which might handle overwrites) or 'obsidian_patch_file' (which modifies content), leaving room for improvement in sibling distinction.
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?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'obsidian_put_file' (for creating/overwriting) and 'obsidian_patch_file' (for partial updates), there's no indication of whether deletion is irreversible or if other tools might handle file removal indirectly. This lack of context could lead to misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'enhanced API approach' but doesn't clarify behavioral traits like error handling, performance, or side effects. It states it returns metadata and content, but lacks details on format, pagination, or limitations.
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 front-loaded with the core purpose and efficiently structured in two sentences. However, the second sentence could be more concise by integrating 'enhanced API approach' into the first sentence to reduce redundancy.
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?
Given the tool's moderate complexity (single parameter, no output schema, no annotations), the description is minimally adequate. It covers what the tool does but lacks details on output format, error conditions, and usage context, leaving gaps for an AI agent to infer behavior.
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 100%, with the parameter 'period' fully documented in the schema. The description adds no additional meaning beyond the schema, such as examples or edge cases, so it meets the baseline of 3 without compensating for any gaps.
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 clearly states the verb ('Get') and resource ('current periodic note'), specifying it retrieves both metadata and content. It distinguishes from siblings like obsidian_get_active_note by focusing on periodic notes, but doesn't explicitly differentiate from obsidian_recent_periodic_notes, which might have overlapping functionality.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when-not scenarios or prerequisites, and with siblings like obsidian_recent_periodic_notes available, there's no indication of which to choose for different use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 behavioral disclosure. It mentions creating or updating files, implying mutation, but fails to detail critical aspects like whether it overwrites existing content entirely, requires specific permissions, or handles errors. This leaves significant gaps in understanding the tool's behavior.
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, efficient sentence that directly states the tool's function without unnecessary words. It is front-loaded and wastes no space, making it highly concise and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity as a file mutation operation with no annotations and no output schema, the description is insufficient. It lacks details on behavioral traits, error handling, or return values, making it incomplete for safe and effective use by an AI agent in a vault environment.
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 input schema has 100% description coverage, clearly documenting both parameters ('filepath' and 'content'). The description adds no additional semantic details beyond what the schema provides, such as file format constraints or content handling specifics, so it meets the baseline for adequate but unenhanced parameter information.
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 clearly states the verb ('create' or 'update') and resource ('file in your vault'), making the purpose evident. However, it does not explicitly differentiate from sibling tools like 'obsidian_append_to_file' or 'obsidian_patch_file', which also modify files, so it lacks sibling distinction for a perfect score.
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?
The description provides no guidance on when to use this tool versus alternatives, such as 'obsidian_append_to_file' for appending content or 'obsidian_patch_file' for partial updates. It also omits prerequisites like file permissions or vault accessibility, leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 behavioral disclosure. It mentions execution order ('in order') and a prerequisite for note-specific commands, but fails to cover critical aspects like whether this tool is read-only or destructive, what permissions are needed, error handling, or rate limits. This leaves significant gaps in understanding the tool's behavior.
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 appropriately sized with two sentences that are front-loaded: the first states the core purpose, and the second adds a specific usage note. There's no wasted text, though it could be slightly more structured for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of executing commands in an interface, the lack of annotations, and no output schema, the description is incomplete. It misses details on return values, error cases, side effects, and how it interacts with sibling tools, making it inadequate for safe and effective use by an AI agent.
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 input schema has 100% description coverage, clearly documenting the 'commands' parameter as a list of strings. The description adds minimal value beyond this by emphasizing execution order and note-related context, but doesn't provide additional semantic details like command examples, format, or constraints. This meets the baseline for high schema coverage.
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 clearly states the action ('Execute one or more commands in obsidian interface') and specifies the resource ('obsidian interface'), making the purpose understandable. However, it doesn't explicitly differentiate this tool from sibling tools like 'obsidian_list_commands' or 'obsidian_understand_vault' beyond the execution aspect, which prevents a perfect score.
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 provides implied usage guidance by mentioning 'For commands used on specific notes, make sure to open a note first,' which suggests a prerequisite context. However, it lacks explicit when-to-use vs. alternatives (e.g., compared to 'obsidian_list_commands' or other sibling tools) and doesn't specify exclusions, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions that 'empty directories will not be returned' (via schema), which is useful, but lacks other behavioral details like permissions needed, rate limits, output format, pagination, or error conditions. For a tool with no annotation coverage, this is insufficient.
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?
Single sentence with zero waste—front-loaded with the core action and scope. Every word earns its place, making it highly efficient and easy to parse.
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?
Given the tool's low complexity (single parameter, no annotations, no output schema), the description is minimally adequate but has clear gaps. It covers the basic purpose but lacks usage guidance, behavioral context, and output details, which are needed for effective agent use.
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 100%, so the schema already fully documents the single parameter 'dirpath'. The description adds no additional parameter semantics beyond what's in the schema, such as path format examples or edge cases. Baseline 3 is appropriate when schema does all the work.
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 clearly states the verb ('Lists') and resource ('all files and directories') with specific scope ('in a specific Obsidian directory'). It distinguishes from some siblings like search tools but doesn't explicitly differentiate from 'obsidian_batch_get_files' or 'obsidian_open_files' which might have overlapping functionality.
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 on when to use this tool versus alternatives like 'obsidian_simple_search', 'obsidian_complex_search', or 'obsidian_batch_get_files'. The description implies directory-focused listing but doesn't specify use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 behavioral disclosure. It states the action ('Open') and outcome ('in a new leaf'), implying a read operation that may involve UI changes, but doesn't specify permissions, side effects (e.g., if files must exist), error handling, or what 'new leaf' entails (e.g., tab, window). This is a significant gap for a tool with potential user interface impacts.
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, efficient sentence that front-loads the core action and outcome. Every word earns its place, with no redundancy or unnecessary details. It's appropriately sized for a straightforward tool.
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?
Given the tool's moderate complexity (opening files with UI implications), no annotations, and no output schema, the description is minimally adequate. It covers the basic purpose but lacks details on behavior, error cases, or return values. It meets the minimum viable threshold but has clear gaps in contextual information.
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 100%, with the parameter 'filepaths' fully documented in the schema as an array of file paths relative to the vault root. The description adds no additional meaning beyond the schema, such as format examples or constraints. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Open') and resource ('one or more files in the vault'), specifying the outcome ('in a new leaf'). It distinguishes from siblings like obsidian_get_active_note (retrieves content) or obsidian_list_files_in_dir (lists files), but doesn't explicitly differentiate from all siblings. The purpose is specific but not fully contrasted with every alternative.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., file existence), exclusions, or compare to siblings like obsidian_get_active_note for viewing current content or obsidian_simple_search for finding files first. Usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 behavioral disclosure. It states the tool retrieves files but lacks details on permissions, rate limits, error handling, or the return format (e.g., list structure, metadata included). This is a significant gap for a tool with potential operational implications.
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, efficient sentence that directly states the tool's function without unnecessary words. It is front-loaded and easy to parse, making it highly concise and well-structured for quick understanding.
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?
Given the tool's low complexity (2 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on behavioral aspects and usage context, which are needed for a complete understanding, especially without annotations to fill in gaps.
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 input schema has 100% description coverage, clearly documenting both parameters ('limit' and 'days') with defaults and constraints. The description does not add any parameter-specific information beyond what the schema provides, so it meets the baseline score of 3 for adequate but no extra value.
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 clearly states the tool's purpose with a specific verb ('Get') and resource ('recently modified files in the vault'), making it immediately understandable. However, it does not explicitly differentiate from sibling tools like 'obsidian_list_files_in_dir' or 'obsidian_simple_search', which might also list files under different criteria, so it falls short of a perfect score.
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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention scenarios where this tool is preferred over siblings like 'obsidian_list_files_in_dir' for listing all files or 'obsidian_simple_search' for filtered searches, leaving the agent to infer usage based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states what the tool does, not how it behaves. It doesn't disclose whether this modifies files permanently, requires specific permissions, handles errors, or has any side effects. For a file modification tool with zero annotation coverage, this leaves critical behavioral aspects undocumented.
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?
Single sentence that's perfectly front-loaded with all essential information. No wasted words, no unnecessary elaboration - every word earns its place in conveying the tool's core functionality efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a file modification tool with 5 parameters, no annotations, and no output schema, the description is insufficient. It explains what the tool does but not how it behaves, what it returns, or potential consequences. The agent would need to guess about error handling, file locking, or whether changes are reversible.
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 100%, so the schema already documents all 5 parameters thoroughly. The description adds minimal value beyond what's in the schema - it mentions 'heading, block reference, or frontmatter field' which aligns with target_type enum values but doesn't provide additional context about parameter interactions or usage patterns.
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 ('Insert content'), target resource ('existing note'), and positioning method ('relative to a heading, block reference, or frontmatter field'). It distinguishes from sibling tools like obsidian_append_to_file by specifying targeted insertion rather than simple appending.
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 on when to use this tool versus alternatives like obsidian_append_to_file or obsidian_put_file. The description implies usage for targeted content insertion but doesn't specify scenarios, prerequisites, or exclusions that would help an agent choose between similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. It mentions that the search is 'simple' and 'across all files,' but doesn't describe key behaviors such as whether it's case-sensitive, how results are returned (e.g., format, pagination), performance implications, or error handling. For a search tool with zero annotation coverage, this leaves significant gaps in understanding its operation.
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 concise with two sentences that directly state the purpose and usage. It's front-loaded with the core functionality and avoids unnecessary details. However, the second sentence is somewhat redundant with the first, slightly reducing efficiency, but overall it's well-structured and to the point.
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?
Given the tool's moderate complexity (search function with 2 parameters), no annotations, and no output schema, the description is minimally adequate. It covers the basic purpose and usage but lacks details on behavior, output format, and differentiation from siblings. It meets the minimum viable threshold but has clear gaps that could hinder effective tool selection and invocation.
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 100%, so the input schema already documents both parameters ('query' and 'context_length') with descriptions. The description adds no additional parameter semantics beyond what's in the schema, such as examples of query syntax or how context_length affects output. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't enhance parameter understanding.
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 clearly states the tool's purpose: 'Simple search for documents matching a specified text query across all files in the vault.' It specifies the verb ('search'), resource ('documents'), and scope ('across all files in the vault'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from its sibling 'obsidian_complex_search' beyond the 'simple' qualifier, which is somewhat vague.
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 provides some guidance with 'Use this tool when you want to do a simple text search,' which implies usage for basic searches. However, it doesn't specify when to use this versus 'obsidian_complex_search' or other search-related tools, nor does it mention any prerequisites or exclusions. The guidance is implied but lacks explicit alternatives or detailed context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 discloses that it returns content and metadata, and clarifies the note selection as 'most recently edited', which adds useful context. However, it doesn't cover other behavioral aspects such as error handling, performance, or whether it requires specific permissions or has side effects, leaving gaps for a tool with no annotation support.
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 front-loaded and concise, consisting of two clear sentences that directly explain the tool's purpose and behavior without any wasted words. Every sentence adds value, making it efficient and well-structured.
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?
Given the tool has no parameters, no annotations, and no output schema, the description provides basic purpose and selection criteria. However, for a tool that retrieves note content and metadata, it lacks details on the return format, potential errors, or how 'active' is defined in edge cases, making it adequate but incomplete for full contextual understanding.
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 parameters with 100% coverage, so no parameter information is needed. The description appropriately adds no parameter details, focusing on the tool's function instead. This meets the baseline for zero parameters, as it doesn't need to compensate for any schema gaps.
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 clearly states the verb ('Get') and resource ('content and metadata of the currently active note in Obsidian'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from siblings like 'obsidian_recent_changes' or 'obsidian_open_files', which might also relate to note access or state.
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 by specifying 'currently active note' and 'most recently edited', suggesting it should be used when the user needs the latest edited note. However, it lacks explicit guidance on when to use this tool versus alternatives like 'obsidian_recent_changes' or 'obsidian_open_files', and doesn't mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. The description mentions that it 'lists' commands, which implies a read-only operation, but it doesn't specify whether this requires specific permissions, what the output format looks like, or if there are any rate limits or constraints. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
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 two sentences, each serving a distinct purpose: the first states the tool's function, and the second provides a usage tip. There is no wasted language, and the information is front-loaded with the core purpose. This is an excellent example of concise and well-structured description.
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?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate but could be more complete. It explains what the tool does and offers a usage tip, but without annotations or output schema, it doesn't fully cover behavioral aspects like response format or constraints. This meets the minimum viable standard for such a tool.
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 parameters with 100% coverage, so no parameter information is needed. The description appropriately adds no parameter details, focusing instead on usage context. This aligns with the baseline expectation for tools with no parameters, earning a high score for not cluttering the description with unnecessary information.
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 clearly states the tool's purpose: 'List all available commands you can run in obsidian interface.' This specifies the verb ('list') and resource ('available commands'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'obsidian_execute_commands' or 'obsidian_understand_vault', which prevents a perfect score.
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 provides some usage guidance with the second sentence: 'For commands used on specific notes, make sure to open a note first.' This implies a prerequisite context for certain commands, but it doesn't explicitly state when to use this tool versus alternatives like 'obsidian_execute_commands' or other siblings. The guidance is helpful but incomplete for distinguishing between tools.
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 provided, the description carries full burden. It discloses the include_content behavior (comprehensive metadata vs. basic) and mentions 'enhanced API approach', adding some context. However, it doesn't cover rate limits, error conditions, or what 'most recent' means temporally (e.g., by creation date, modification date).
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?
Two sentences, front-loaded with the core purpose. The second sentence efficiently explains the include_content parameter effect. No wasted words, though it could be slightly more structured (e.g., bullet points for behaviors).
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?
Given no annotations and no output schema, the description is moderately complete for a read operation. It covers the core purpose and key parameter effect, but lacks details on return format (e.g., structure of returned notes), error handling, or pagination behavior. Adequate but with clear gaps.
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 100%, so the schema fully documents all parameters. The description adds marginal value by explaining the effect of include_content=True ('comprehensive metadata... and note content'), but doesn't provide additional semantics beyond what's in the schema. Baseline 3 is appropriate.
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 clearly states the verb ('Get') and resource ('most recent periodic notes'), specifying the period type parameter. It distinguishes from sibling 'obsidian_periodic_notes' by focusing on 'most recent' notes, though the distinction could be more explicit. The purpose is specific and actionable.
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 context by mentioning 'most recent' and the include_content parameter effect, but doesn't explicitly state when to use this tool versus alternatives like 'obsidian_periodic_notes' or 'obsidian_recent_changes'. No explicit when-not or prerequisite guidance is provided.
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 provided, the description carries the full burden. It discloses that the tool 'Supports standard JsonLogic operators plus 'glob' and 'regexp' for pattern matching' and that 'Results must be non-falsy,' adding useful behavioral context. However, it doesn't cover aspects like performance implications, error handling, or result format details, leaving gaps for a mutation-like search operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately front-loaded with key information, but includes extensive examples that, while helpful, make it lengthy. Every sentence adds value, but the structure could be more streamlined by integrating examples more succinctly or moving some details to the schema.
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?
Given the tool's complexity (involving JsonLogic queries with nested objects) and lack of annotations and output schema, the description is moderately complete. It covers purpose, usage, and parameter semantics with examples, but doesn't fully address behavioral aspects like result formatting or error cases, leaving room for improvement in contextual coverage.
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 description coverage is 100%, so the baseline is 3. The description adds value by explaining that the query uses 'JsonLogic operators plus 'glob' and 'regexp' for pattern matching' and provides multiple examples that illustrate syntax and usage, enhancing understanding beyond the schema's technical documentation.
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 clearly states the tool performs 'complex search for documents using a JsonLogic query,' which specifies the verb (search) and resource (documents) with the method (JsonLogic). It distinguishes from sibling 'obsidian_simple_search' by emphasizing complexity, but doesn't explicitly contrast their capabilities beyond naming.
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 explicit guidance: 'Use this tool when you want to do a complex search, e.g. for all documents with certain tags etc.' This gives clear context for when to use it, though it doesn't explicitly mention when not to use it or name alternatives like 'obsidian_simple_search' as direct comparisons.
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 provided, the description carries full burden. It describes what the tool returns (directory tree and NetworkX graph) and the scope of analysis, but lacks details about performance characteristics, error conditions, or what 'comprehensive understanding' entails. It doesn't mention whether this is a read-only operation or has 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the main purpose. All sentences contribute value by explaining outputs and scope, though it could be slightly more concise by combining some concepts about what's included in the analysis.
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 tool with 3 parameters, 100% schema coverage, but no annotations or output schema, the description provides adequate context about what the tool does and returns. However, it lacks details about the format/structure of the returned data and behavioral characteristics that would be helpful for an AI agent.
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 100%, so the schema already documents all three parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema, maintaining the baseline score of 3 for high schema 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 purpose: 'Get a comprehensive understanding of the vault structure' with specific outputs (directory tree and NetworkX graph) and scope (combines filesystem structure with note relationships). It distinguishes from siblings like obsidian_list_files_in_dir by emphasizing comprehensive analysis rather than simple listing.
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 understanding vault structure and connections, but doesn't explicitly state when to use this tool versus alternatives like obsidian_list_files_in_dir or obsidian_complex_search. No specific exclusions or prerequisites are mentioned.
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 provided, the description carries full burden. It discloses the tool reads files and returns content/metadata, but lacks details on permissions needed, error handling for non-existent files, rate limits, or return format. It adds basic behavioral context but leaves gaps for a read operation.
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, efficient sentence that front-loads the core purpose ('Return the contents and metadata') without wasted words. Every part earns its place by specifying scope and resource.
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?
Given no annotations and no output schema, the description is minimally complete for a read tool with one parameter. It covers what the tool does but lacks details on output structure, error cases, or vault-specific constraints. Adequate but with clear gaps in behavioral context.
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 100%, so the schema fully documents the single parameter 'filepaths'. The description adds no additional parameter semantics beyond implying multiple files can be specified, which is already clear from the schema's array type. Baseline 3 is appropriate as the schema does the heavy lifting.
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 action ('Return') and target resource ('contents and metadata of one or more notes (.md files) in your vault'), specifying both verb and resource. It distinguishes from siblings like obsidian_get_active_note (single active note) and obsidian_list_files_in_dir (list files without 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 implies usage for reading multiple notes by specifying 'one or more notes', providing clear context. However, it doesn't explicitly state when not to use it (e.g., vs. obsidian_simple_search for filtered content) or name alternatives, missing explicit exclusions.
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:

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

Score Badge

Copy to your README.md:

[![mcp-obsidian-advanced MCP server](https://glama.ai/mcp/servers/ToKiDoO/mcp-obsidian-advanced/badges/score.svg)](https://glama.ai/mcp/servers/ToKiDoO/mcp-obsidian-advanced)

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/ToKiDoO/mcp-obsidian-advanced'

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