Obsidian MCP Server

by Victors081

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Every tool has a clearly distinct purpose with no ambiguity. For example, 'get_file' reads file content while 'get_metadata' extracts structured data, and 'list_files' enumerates files whereas 'search_files' finds specific content. The actions (append, execute, get, list, open, search, write) are well-differentiated and target specific Obsidian operations.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern using snake_case throughout, such as 'append_content', 'execute_command', 'get_active_file', and 'write_file'. This predictable naming convention makes it easy for agents to understand and select the right tool based on the intended action and target resource.
Tool Count5/5
With 12 tools, the count is well-scoped for managing Obsidian vaults and files. Each tool earns its place by covering distinct aspects like file operations (read, write, append), metadata handling, vault management, UI interactions, and search capabilities, without being overly broad or sparse for the domain.
Completeness5/5
The tool set provides complete CRUD/lifecycle coverage for Obsidian vault and file management, including create (write_file), read (get_file, get_metadata), update (append_content, write_file), delete (implied via write/overwrite), and utility operations like listing, searching, and UI control. No obvious gaps exist for core workflows in this domain.
Average 3/5 across 12 of 12 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 the full burden of behavioral disclosure. It states the action ('append') but doesn't cover critical aspects like whether this requires specific permissions, how it handles errors (e.g., if file doesn't exist), if it's idempotent, or what the response looks like. For a mutation tool with zero annotation coverage, 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, efficient sentence with zero waste. It's front-loaded with the core purpose and appropriately sized for the tool's complexity.
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 this is a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain behavioral traits, error handling, or return values, which are critical for an agent to use it correctly. The description alone is inadequate for a tool that modifies files.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so all parameters are documented in the schema itself. The description doesn't add any meaning beyond what the schema provides (e.g., it doesn't explain 'vault' or 'filepath' further). Baseline 3 is appropriate when 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 ('append content') and target resource ('to an existing file'), which is specific and unambiguous. However, it doesn't differentiate from sibling tools like 'write_file' or 'open_file', 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 like 'write_file' or 'open_file'. It doesn't mention prerequisites (e.g., file must exist) or exclusions, leaving the agent to infer usage context from the tool 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions a prerequisite ('requires REST API plugin'), which is helpful context. However, it doesn't describe what happens during execution—such as whether it's a read-only or destructive operation, potential side effects, error handling, or what the response looks like. For a tool that executes commands with no 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 a single, efficient sentence that directly states the tool's purpose and a key prerequisite. It's front-loaded with the main action and avoids unnecessary details, making it easy to parse quickly. Every word earns its place without redundancy.
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 Obsidian, the lack of annotations, and no output schema, the description is incomplete. It doesn't explain what types of commands can be executed, potential risks or side effects, or what the tool returns. For a tool that could perform various operations (from reads to writes), more context is needed to ensure safe and effective 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?
The schema description coverage is 100%, so the schema already documents all three parameters (vault, commandId, args) with descriptions. The description doesn't add any additional meaning or context about these parameters beyond what the schema provides, such as examples of command IDs or typical argument structures. This meets the baseline score when schema coverage is high.
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') and resource ('an Obsidian command'), making the purpose understandable. However, it doesn't differentiate this tool from its siblings like 'append_content' or 'write_file', which also perform actions in Obsidian. The mention of 'requires REST API plugin' adds useful context but doesn't specifically distinguish the tool's unique function.
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 mentions a prerequisite ('requires REST API plugin'), but doesn't explain scenarios where executing a command is appropriate compared to other tools like 'write_file' or 'search_files'. There are no explicit when/when-not instructions or named alternatives provided.
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 states this is a read operation, which implies it's non-destructive, but doesn't mention other traits like error handling (e.g., what happens if the file doesn't exist), authentication needs, rate limits, or return format. 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 a single, efficient sentence ('Read a file from a vault') that front-loads the core purpose without unnecessary words. It avoids redundancy 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 complexity (a read operation with 3 parameters) and the lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., file content, metadata, or errors), behavioral aspects like error conditions, or how it differs from siblings. For a tool with no structured output information, the description should provide more context to be fully helpful.
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, providing clear documentation for all three parameters (vault, filepath, parseFrontmatter). The description adds no additional meaning beyond what's in the schema, such as explaining the format of 'vault' or 'filepath' or detailing the effects of 'parseFrontmatter'. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
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 ('Read') and resource ('a file from a vault'), making the purpose immediately understandable. It distinguishes this from siblings like 'write_file' (write vs. read) and 'list_files' (list vs. read), though it doesn't explicitly differentiate from 'get_active_file' (which likely reads the currently active file). The description is specific but could be more precise about sibling differentiation.
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 to choose 'get_file' over 'get_active_file' (for reading a specific file vs. the active one) or 'list_files' (for listing vs. reading content), nor does it specify prerequisites like needing a valid vault identifier. Usage is implied by the name and purpose but lacks 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?
With no annotations provided, the description carries full burden for behavioral disclosure but offers minimal information. It doesn't indicate whether this is a read-only operation, what permissions might be required, what format the information is returned in, or potential error conditions. The description merely restates the basic function without adding meaningful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core purpose without unnecessary words. It's appropriately sized for a simple tool with one parameter and gets straight to the point. Every word earns its place in this minimal but functional description.
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 tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what information is returned, what format it's in, or any behavioral characteristics. While the schema covers the single input parameter well, the overall context for using this tool effectively is lacking given the absence of structured metadata about outputs and 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?
The input schema has 100% description coverage, with the single parameter 'vault' clearly documented as 'Vault identifier (name or path)'. The description adds no additional parameter information beyond what the schema provides, which is acceptable given the comprehensive schema coverage. The baseline score of 3 reflects adequate but not enhanced parameter 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 action ('Get information') and target resource ('about a specific vault'), making the purpose immediately understandable. It distinguishes itself from sibling tools like 'list_vaults' by focusing on a single vault rather than listing multiple. However, it doesn't specify what type of information is retrieved, 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. It doesn't mention prerequisites like needing to know the vault identifier first, nor does it differentiate from similar tools like 'get_metadata' or 'get_file' that might also retrieve information. The agent must infer usage context from the tool 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 for behavioral disclosure. It mentions nothing about permissions needed, rate limits, pagination behavior, error conditions, or what format the file list returns. 'List files' implies a read operation, but lacks details about scope, performance, or constraints.
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's front-loaded with the core purpose and appropriately sized for a straightforward listing tool.
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 tool with 4 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what constitutes a 'file' in this context, how results are structured, whether there are limitations on listing size, or how it differs from search capabilities. The agent would lack important operational 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 parameters are fully documented in the schema. The description doesn't add any parameter-specific context beyond implying a vault context. This meets the baseline for high schema coverage but doesn't enhance understanding of parameter usage or relationships.
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 ('List') and resource ('files in a vault'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'search_files' or 'list_vaults', which would require more specificity about scope or filtering capabilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'search_files' (for filtered searches) or 'list_vaults' (for listing vaults instead of files). The description only states what it does, not when it's appropriate compared to other options.
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 the UI interaction aspect and a plugin requirement, but doesn't describe what 'open' actually does (e.g., does it bring the file to foreground, open in new tab, trigger visual effects?), whether it requires specific permissions, or what happens on failure. For a UI-interaction tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core purpose and a key requirement. It's appropriately sized and front-loaded with the main action. However, it could be slightly more structured by separating the requirement into a second sentence for clarity.
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 (UI interaction with prerequisites), no annotations, and no output schema, the description is minimally adequate. It covers the what and a key requirement, but lacks details on behavioral outcomes, error handling, or UI-specific effects. For a tool that interacts with a UI, more context about what 'open' entails would be beneficial.
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 both parameters ('vault' and 'filepath') clearly documented in the schema. The description doesn't add any parameter-specific information beyond what the schema provides, such as format examples or constraints. With high schema coverage, the baseline score of 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 action ('Open a file') and the target resource ('in Obsidian UI'), which provides a specific verb+resource combination. However, it doesn't explicitly distinguish this tool from similar siblings like 'get_file' or 'get_active_file' in terms of UI vs. data retrieval 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 mentions a prerequisite ('requires REST API plugin'), which provides some context, but offers no guidance on when to use this tool versus alternatives like 'get_file' (which might retrieve file content without UI interaction) or 'open_graph' (which opens a different UI view). No explicit when/when-not or alternative recommendations are provided.
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 states the tool opens a graph view and requires a plugin, but lacks details on behavioral traits such as whether this is a read-only or interactive operation, what happens if the vault doesn't exist, or any side effects like UI changes. The description is minimal and leaves key behaviors unspecified.
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 purpose and a key requirement. It is front-loaded with the main action and has no wasted words, making it highly concise and well-structured.
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 has no annotations, no output schema, and a simple input schema, the description is incomplete. It lacks information on what the tool returns (e.g., success/failure, graph data), error conditions, or detailed behavioral context. For a tool that likely interacts with a UI or system, more completeness is needed to guide effective 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%, with the single parameter 'vault' documented as 'Vault identifier'. The description adds no additional meaning beyond this, such as explaining what a vault is or format examples. With high schema coverage, the baseline score of 3 is appropriate as the schema handles parameter documentation adequately.
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 graph view') and target ('in Obsidian'), which is specific and understandable. However, it doesn't differentiate this tool from sibling tools like 'open_file' or 'get_active_file' that also interact with Obsidian files/views, missing explicit 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 mentions a prerequisite ('requires REST API plugin'), which provides some context, but offers no guidance on when to use this tool versus alternatives like 'open_file' or other sibling tools. There are no explicit when/when-not statements or named alternatives.
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 ('Search for text') but doesn't mention critical aspects like whether this is a read-only operation, if it requires specific permissions, how results are returned (e.g., pagination, format), or potential rate limits. This is a significant gap for a search tool with multiple parameters.
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 purpose without any fluff or redundancy. It's front-loaded and wastes no words, making it easy for an agent to parse quickly.
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 (6 parameters, no annotations, no output schema), the description is insufficient. It doesn't explain what the search returns (e.g., file names, snippets, match counts), how results are structured, or any behavioral nuances. This leaves the agent with incomplete context for effective 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?
The description doesn't add any parameter-specific information beyond what's already in the schema, which has 100% coverage with clear descriptions for all 6 parameters. This meets the baseline score of 3, as the schema adequately documents the inputs without needing extra explanation in the description.
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 'Search for text in vault files' clearly states the verb ('Search') and resource ('text in vault files'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_files' or 'get_file' which might also involve file operations, so it doesn't reach the highest 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 like 'list_files' for browsing or 'get_file' for retrieving specific files. It lacks any mention of prerequisites, exclusions, or contextual recommendations, 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 the full burden of behavioral disclosure. It states the action ('write or update') but lacks critical details: it doesn't specify if this overwrites existing files, requires authentication, has rate limits, or handles errors. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded in a single sentence that directly states the tool's purpose. There is no wasted language or unnecessary elaboration, making it efficient and easy to parse at a glance.
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 6 parameters, no annotations, and no output schema), the description is insufficiently complete. It doesn't cover behavioral aspects like side effects, error handling, or return values, leaving the agent with critical gaps in understanding how to use the tool effectively.
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 no parameter-specific information beyond what's already in the schema, which has 100% coverage. It doesn't explain the semantics of parameters like 'frontmatter' (e.g., its format or use cases) or 'expectedModTime' (e.g., how conflict detection works). With high schema coverage, the baseline is 3, as the description doesn't compensate with extra insights.
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 ('write or update') and resource ('a file in a vault'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'append_content' (which might modify existing files differently) or 'get_file' (which reads files), missing full 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. For example, it doesn't mention when to choose 'write_file' over 'append_content' for modifying files, or prerequisites like needing write access to the vault. This lack of contextual direction leaves usage 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?
No annotations are provided, so the description carries the full burden. It discloses a prerequisite (REST API plugin) and that it retrieves the 'currently active' file, which adds some behavioral context. However, it doesn't cover other important traits like whether it's read-only, what happens if no file is active, error handling, or response format, leaving significant gaps for a tool with no 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the purpose and a key prerequisite. It's appropriately sized and front-loaded with the main action, though it could be slightly more structured by separating the prerequisite into a second sentence 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 no annotations and no output schema, the description is incomplete. It mentions a prerequisite but lacks details on behavior, error cases, or return values. For a tool that retrieves stateful information (the active file), more context is needed to understand how it operates and what to expect, making it inadequate for the complexity.
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 the single parameter 'vault' with its description. The description doesn't add any meaning beyond what the schema provides, such as explaining what a 'vault identifier' is or how it relates to the active file. Baseline 3 is appropriate when 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 ('Get') and resource ('currently active file in Obsidian'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'get_file' or 'open_file', which likely retrieve or open files differently, so it misses full 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when the active file is needed, and mentions a prerequisite ('requires REST API plugin'), providing some context. But it doesn't explicitly state when to use this tool versus alternatives like 'get_file' or 'open_file', leaving usage guidelines partially implied rather than fully clear.
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 states the tool retrieves metadata, implying a read-only operation, but doesn't mention any behavioral traits such as permissions required, error handling, or performance considerations. This leaves gaps in understanding how the tool behaves beyond its basic function.
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 purpose and elaborates on the metadata components. It is front-loaded with the core action and avoids any unnecessary words, 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 adequate but has clear gaps. It covers what metadata is retrieved but lacks details on behavioral aspects and usage context. For a read operation with no annotations, it should ideally provide more guidance on when and how to use it relative to siblings, making it minimally viable but incomplete.
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, with clear documentation for both parameters ('vault' and 'filepath'). The description adds no additional meaning beyond what the schema provides, as it doesn't explain parameter usage or constraints. According to the rules, with high schema coverage, the baseline is 3, which is appropriate here.
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 ('metadata for a file'), and it elaborates on what metadata includes (frontmatter, tags, links, word count). However, it doesn't explicitly differentiate this tool from siblings like 'get_file' or 'get_active_file', which might also retrieve file-related information, so it doesn't reach the highest 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. With siblings like 'get_file' and 'get_active_file' that likely handle file data, there's no indication of whether this tool is for metadata-only retrieval or how it differs in context, leaving the agent to infer usage without explicit direction.
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 states the tool lists vaults but doesn't explain what 'accessible' means (e.g., permissions, authentication needs), how results are returned (e.g., format, pagination), or any limitations (e.g., rate limits). 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 a single, clear sentence that efficiently conveys the core purpose without any wasted words. It's front-loaded and appropriately sized for a simple tool, making it easy to parse and understand quickly.
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 minimally adequate. It states what the tool does but lacks details on usage context, behavioral traits, or output format. For a list operation with no structured support, it should ideally provide more guidance on results and limitations to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% description coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate here. A baseline of 4 is applied since there are no parameters to explain, and the description doesn't introduce unnecessary complexity.
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 ('List') and resource ('all accessible Obsidian vaults'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this tool from sibling tools like 'get_vault_info' or 'list_files', which might also relate to vault operations, so it doesn't reach the highest 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. With sibling tools like 'get_vault_info' and 'list_files' available, it's unclear if this tool is for high-level vault enumeration or if it overlaps with other functions. No explicit when/when-not instructions 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.

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-server MCP server](https://glama.ai/mcp/servers/Victors081/obsidian-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/Victors081/obsidian-mcp-server)

Score Badge

Copy to your README.md:

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

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/Victors081/obsidian-mcp-server'

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