Enhanced Obsidian MCP Server

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 some overlap exists: 'analyze_note_relationships' and 'suggest_connections' both focus on note connections, and 'extract_keywords' and 'suggest_tags' both analyze content for tagging/keywords. Descriptions help differentiate them, but an agent might occasionally confuse these pairs.
Naming Consistency5/5
Tool names follow a consistent verb_noun pattern throughout, using snake_case uniformly. Examples include 'create_note', 'list_tags', 'search_vault', and 'update_note'. This predictability makes it easy for agents to understand and use the toolset.
Tool Count3/5
With 25 tools, the count is borderline high for an Obsidian server, feeling heavy but not extreme. It covers many advanced features like analysis and automation, which may be justified for an 'enhanced' server, but could overwhelm simpler use cases.
Completeness5/5
The toolset provides comprehensive coverage for note management in Obsidian, including full CRUD operations for notes and templates, folder management, search, tagging, analysis, and automation features like backlinking and templating. No obvious gaps are present for the domain.
Average 2.9/5 across 25 of 25 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed 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 for behavioral disclosure. 'Create a new template' implies a write/mutation operation but provides no information about permissions required, whether templates are unique by name, what happens on duplicate names, or what the response contains. For a creation tool with zero annotation coverage, this leaves critical behavioral aspects 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 maximally concise at three words with zero wasted language. It's front-loaded with the core action and resource. While under-specified in content, it's structurally efficient with every word serving the core purpose statement.
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 creation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what happens after creation, whether the template becomes immediately available for use, what validation occurs, or what format the response takes. The context suggests this is part of a note/vault system, but the description doesn't connect to that broader 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 input schema already documents all three parameters thoroughly. The description adds no parameter information beyond what's in the schema. The baseline score of 3 reflects adequate parameter documentation through the schema alone, though the description contributes nothing additional about parameter meaning or usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new template' is a tautology that essentially restates the tool name without adding meaningful specificity. It doesn't clarify what kind of template is being created or what domain this operates in (though sibling tools suggest note/vault management). While the verb 'create' is clear, the resource 'template' remains vague without context about what templates are used for in this system.
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 about when to use this tool versus alternatives. Sibling tools include 'apply_template' and 'list_templates', but the description doesn't mention relationships with these tools or prerequisites like needing existing templates to apply. There's no indication of when this creation operation is appropriate versus other template-related operations.
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 'generate' and 'for visualization', implying a read-only operation that produces data, but fails to specify critical details such as whether this is a computationally intensive process, if it requires specific data inputs (e.g., existing notes), or what the output entails (e.g., structure, size limits). This leaves significant gaps for a tool with potential complexity.
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 directly states the tool's purpose without unnecessary words. It is front-loaded and easy to parse, though it could be slightly more informative without sacrificing brevity.
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 lack of annotations and output schema, the description is incomplete for a tool that likely involves graph generation—a non-trivial operation. It doesn't explain what 'knowledge graph data' means in this context, how it's derived (e.g., from notes, tags), or what the output looks like, leaving the agent with insufficient 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 input schema has 100% description coverage, with clear documentation for both parameters ('format' and 'includeOrphans'). The description adds no parameter-specific information beyond what the schema provides, so it meets the baseline score of 3 for adequate but non-additive coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'generate[s] knowledge graph data for visualization', which provides a clear verb ('generate') and resource ('knowledge graph data') but lacks specificity about what constitutes 'knowledge graph data' or how it relates to the sibling tools. It distinguishes itself from obvious non-siblings (e.g., 'create_note'), but doesn't clarify its unique role versus tools like 'analyze_note_relationships' or 'suggest_connections' that might involve graph-like operations.
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. The description doesn't mention prerequisites, typical use cases, or comparisons to sibling tools like 'analyze_note_relationships' or 'suggest_connections', 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?
No annotations are provided, so the description carries full burden but offers minimal behavioral insight. It doesn't disclose if the search is case-sensitive, supports regex, returns structured data, has pagination, or any performance traits. This leaves the agent guessing about how the tool behaves beyond basic functionality.
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, straightforward sentence with no wasted words, making it easy to parse. However, it's overly concise at the expense of clarity, as it could benefit from more detail to improve usability without becoming verbose.
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 search functionality and lack of annotations or output schema, the description is incomplete. It doesn't explain return values, error handling, or how results are structured, which is critical for an agent to use the tool effectively in a vault with many sibling tools.
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 'query' parameter documented in the schema. The description adds no additional meaning beyond implying a search query, so it meets the baseline of 3 where the schema handles parameter documentation adequately without extra value from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('Search') and target ('content in the Obsidian vault'), which is clear but vague. It doesn't specify what type of content (notes, tags, files) or how results are returned, and it doesn't differentiate from sibling tools like 'search_by_tags' or 'list_notes', leaving ambiguity about its specific scope.
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. With siblings like 'search_by_tags', 'list_notes', and 'find_similar_notes', the description lacks context for choosing this tool, such as whether it searches full text, metadata, or across all vault content, leading to potential 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 the full burden of behavioral disclosure. It states the action ('Search') but lacks details on permissions, rate limits, output format, pagination, or error handling. For a search 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 a single, efficient sentence with zero waste. It is appropriately sized and front-loaded, directly stating the tool's purpose without unnecessary elaboration, 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 complexity of a search operation with 2 parameters (one with an enum), no annotations, and no output schema, the description is incomplete. It does not address behavioral aspects, parameter details, or return values, leaving the agent with insufficient context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning parameters are undocumented in the schema. The description mentions 'tags' but does not explain the 'operator' parameter or provide any additional semantic context beyond the basic action. It fails to compensate for the low schema coverage, leaving key parameters unclear.
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 notes by tags' clearly states the verb ('Search'), resource ('notes'), and filtering mechanism ('by tags'), which is specific and actionable. However, it does not explicitly differentiate from sibling tools like 'search_vault' or 'find_similar_notes', which may offer overlapping or alternative search functionalities, preventing 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. With sibling tools such as 'search_vault', 'find_similar_notes', and 'list_notes', there is no indication of context, prerequisites, or exclusions for selecting this tool, leaving the agent without usage 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 full burden for behavioral disclosure. 'Add tags to a note' implies a mutation operation but reveals nothing about permissions needed, whether tags are appended or replace existing ones, error handling for invalid tags or paths, or what happens if tags already exist. 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?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core purpose and appropriately sized for a simple tool with only two parameters.
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 mutation tool with no annotations and no output schema, the description is inadequate. It doesn't explain what the tool returns (success confirmation, updated note, error details), behavioral constraints, or how it integrates with the broader vault system. Given the complexity of modifying data and the lack of structured safety hints, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters ('path' and 'tags') well-documented in the schema. The description adds no additional semantic context about parameters beyond what the schema provides, such as tag format requirements or path validation rules. The baseline of 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 'Add tags to a note' clearly states the action (add) and target resource (tags to a note), making the purpose immediately understandable. It distinguishes this from sibling tools like 'list_tags' or 'search_by_tags', but doesn't specify how it differs from similar mutation tools like 'update_note' which might also handle tags.
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 'update_note' (which might also modify tags) and 'suggest_tags' (which might recommend tags), there's no indication of when this specific tag-adding operation is preferred or what prerequisites might be needed.
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 analyzes relationships but doesn't describe what the analysis entails, the output format, computational cost, or any side effects. For a tool with no annotations and no output schema, 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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and every part contributes meaning, 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 complexity of relationship analysis, no annotations, and no output schema, the description is incomplete. It lacks details on what the analysis produces, how results are formatted, or any behavioral traits. For a tool that likely returns structured data, this leaves the agent with insufficient context to use it 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 input schema has 100% description coverage, with clear documentation for both parameters ('includeBacklinks' and 'includeTagRelations'). The description doesn't add any parameter-specific information beyond what the schema provides, so it meets the baseline of 3 for high schema coverage without compensating 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: 'Analyze relationships between notes based on links and references.' It specifies the verb ('analyze'), resource ('relationships between notes'), and method ('based on links and references'). However, it doesn't explicitly distinguish this from sibling tools like 'find_similar_notes', 'suggest_connections', or 'generate_knowledge_graph', which might have overlapping functionality, preventing a score of 5.
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, context, or exclusions, nor does it refer to sibling tools like 'find_similar_notes' or 'suggest_connections' for comparison. This leaves the agent without clear direction on appropriate usage scenarios.
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 creates a new note, implying a write operation, but does not cover permissions, error handling, or side effects. 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 no wasted words, clearly front-loading the core action. It is 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 the tool's complexity (3 parameters, no annotations, no output schema), the description is incomplete. It lacks details on behavioral traits, usage context, and output expectations, 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?
Schema description coverage is 100%, so the schema already documents all three parameters. The description adds no additional meaning beyond what the schema provides, such as examples or constraints, resulting in a baseline score of 3.
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 ('apply') and resource ('template') to create a new note, making the purpose evident. However, it does not differentiate from sibling tools like 'create_note' or 'create_template', which handle similar note/template operations, leaving some ambiguity about when to choose this specific tool.
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 'create_note' or 'create_template'. It lacks context about prerequisites, typical scenarios, or exclusions, leaving the agent to infer usage from 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 for behavioral disclosure. While 'Create' implies a write operation, it doesn't address important aspects like permissions needed, whether the operation overwrites existing files, what happens if the path is invalid, or what the response looks like. This is inadequate 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 that communicates the core purpose without any wasted words. It's appropriately sized and front-loaded with the essential information.
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 mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens on success/failure, what permissions are required, or how it interacts with sibling tools. Given the complexity of file creation operations and the rich sibling toolset, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters. The description doesn't add any additional meaning or context about the parameters beyond what's in the schema. This meets the baseline expectation 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 ('Create') and target resource ('new note in the Obsidian vault'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'create_template' or 'update_note', which would require more specificity about what distinguishes this particular creation operation.
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. There's no mention of when to choose 'create_note' over 'create_template', 'apply_template', or 'update_note', nor any prerequisites or context for when this operation is appropriate.
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 destructive action ('Delete') but lacks critical details: whether deletion is permanent or reversible, what permissions are required, how errors are handled (e.g., if the note doesn't exist), or what the response looks like. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with zero wasted words. It front-loads the core action and resource efficiently, making it easy to parse and understand immediately.
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 no output schema, the description is incomplete. It fails to address safety considerations, error handling, or response format, which are crucial for an agent to use this tool correctly and safely in a vault management 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%, with the single parameter 'path' fully documented in the schema. The description adds no additional parameter semantics beyond implying the path targets a note, which the schema already covers. 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 ('Delete') and resource ('a note from the Obsidian vault'), making the purpose immediately understandable. It distinguishes this as a deletion operation among siblings that include create, read, update, and move operations, though it doesn't explicitly contrast with similar destructive tools like delete_template.
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. It doesn't mention prerequisites (e.g., note must exist), exclusions, or compare with similar tools like move_note or delete_template, leaving the agent to infer usage from context 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. While 'Delete' implies a destructive mutation, it doesn't specify whether deletion is permanent/reversible, what permissions are required, or what happens to associated data. This is inadequate for a destructive operation 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 extremely concise with just three words, front-loading the essential action and resource. There's zero wasted language, making it efficient 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?
For a destructive tool with no annotations and no output schema, the description is insufficient. It lacks critical context about the mutation's impact, success/failure behavior, or return values, leaving significant gaps for agent decision-making.
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 'name' fully documented in the schema. The description adds no additional parameter information beyond what's in the schema, so it meets the baseline of 3 where 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 ('Delete') and the resource ('a template'), providing a specific verb+resource combination. However, it doesn't differentiate this from sibling tools like 'delete_note' or 'create_template' beyond the obvious resource difference, missing explicit 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. It doesn't mention prerequisites (e.g., template must exist), exclusions, or comparisons to related tools like 'create_template' or 'apply_template', leaving usage context entirely implicit.
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 the TF-IDF algorithm, which hints at computational behavior, but doesn't cover critical aspects like performance (e.g., processing time for large notes), error handling (e.g., what happens if the path is invalid), or output format (e.g., list of keywords with scores). This leaves significant gaps for an agent to understand how the tool behaves.
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: 'Extract keywords from note content using TF-IDF algorithm.' It is front-loaded with the core purpose and includes the method, with zero wasted words. This makes 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 complexity of keyword extraction (involving algorithms and data processing), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what the output looks like (e.g., a list of keywords, possibly with scores), error conditions, or behavioral traits like rate limits. This leaves the agent with insufficient context for reliable 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 both parameters ('path' and 'maxKeywords') well-documented in the schema. The description adds no additional parameter semantics beyond what the schema provides, such as explaining the note format expected at the path or how TF-IDF influences keyword selection. Baseline score of 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 tool's purpose: 'Extract keywords from note content using TF-IDF algorithm.' It specifies the verb ('extract'), resource ('keywords from note content'), and method ('TF-IDF algorithm'), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'suggest_tags' or 'analyze_note_relationships', which might offer 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 prerequisites, such as requiring an existing note at the specified path, or compare it to similar tools like 'suggest_tags' or 'analyze_note_relationships' for keyword extraction. Usage is implied by the purpose but lacks explicit context 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states what the tool does but doesn't describe how it behaves: e.g., whether it returns a list, paginates results, requires specific permissions, or has rate limits. For a 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 a single, efficient sentence that directly states the tool's purpose without any fluff or redundancy. It is appropriately sized and front-loaded, making it easy for an agent 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 complexity of finding orphaned notes (which involves relational logic) and the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'orphan' means in this context (e.g., no links but possibly tags), the return format, or error handling. This leaves gaps for an agent to understand the tool fully.
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 one parameter ('includeTagged') fully documented in the schema. The description adds no additional parameter semantics beyond what the schema provides, such as explaining edge cases or examples. This meets the baseline of 3 since the schema handles 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 tool's function as 'Find notes that have no incoming or outgoing links,' which is a specific verb+resource combination. It distinguishes itself from siblings like 'list_notes' or 'search_vault' by focusing on orphaned notes. However, it doesn't explicitly differentiate from 'find_similar_notes' in terms of purpose, which slightly reduces clarity.
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, context (e.g., after cleaning up a vault), or exclusions (e.g., not for general listing). With many sibling tools available, this lack of usage context leaves the agent to infer when this tool is appropriate.
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 method ('cosine similarity') but doesn't describe what 'similar content' entails (e.g., text-based, semantic), how results are ordered, whether it's read-only or has side effects, or any performance considerations like rate limits. This leaves significant gaps for a tool that performs computational analysis.
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 ('Find notes with similar content') and includes the method ('using cosine similarity') without unnecessary words. Every part earns its place, 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a similarity-finding tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral aspects (e.g., read-only nature, performance), output format (e.g., what data is returned), and doesn't compensate for the absence of structured fields. This makes it inadequate for guiding an agent effectively in 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?
The input schema has 100% description coverage, with clear parameter details (e.g., 'path' as reference note, 'threshold' range 0-1, 'maxResults' default). The description adds no additional parameter semantics beyond what's in the schema, such as explaining how 'threshold' affects similarity matching or format requirements for 'path'. 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 verb ('Find') and resource ('notes'), specifying the method ('using cosine similarity') and goal ('with similar content'). It distinguishes from obvious siblings like 'search_vault' or 'list_notes' by focusing on content similarity rather than keyword matching or listing, though it doesn't explicitly contrast with 'analyze_note_relationships' or 'suggest_connections' which might have overlapping purposes.
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. It doesn't mention prerequisites (e.g., needing a reference note), exclusions (e.g., not for exact matches), or compare to siblings like 'analyze_note_relationships' or 'suggest_connections' that might handle similar tasks differently. The description implies usage for finding content-similar notes 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('generate a summary') but doesn't explain how the summary is produced (e.g., algorithm, length constraints beyond maxSentences), what happens if the note doesn't exist, or the output format. For a tool 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 extremely concise and front-loaded with a single sentence: 'Generate a summary of note content.' It wastes no words and directly communicates the core function, making it easy for an agent to parse quickly. Every part of the sentence earns its place by defining the tool's purpose.
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 a summary generation tool with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects like how summaries are generated, error handling, or return values, leaving the agent with insufficient information to use the tool effectively beyond basic parameter passing.
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 semantics beyond what the input schema provides. With 100% schema description coverage, the schema already documents 'path' and 'maxSentences' clearly. The description doesn't elaborate on usage examples or constraints, so it meets the baseline of 3 for high schema coverage without adding 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: 'Generate a summary of note content.' It specifies the verb ('generate') and resource ('summary of note content'), making the function understandable. However, it doesn't differentiate from sibling tools like 'extract_keywords' or 'analyze_note_relationships' that might also process note content, leaving some ambiguity about its unique role.
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, such as needing an existing note, or compare it to siblings like 'extract_keywords' for different analysis types. Without any context on usage scenarios or exclusions, the agent must infer this 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. While 'List all notes' implies a read-only operation, it doesn't specify important behavioral aspects like whether results are paginated, sorted, or limited; what format they return; or whether the optional folder parameter affects performance. This leaves significant gaps for an agent to understand how to use the tool effectively.
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 - a single sentence that states exactly what the tool does with zero wasted words. It's front-loaded with the core functionality and doesn't include any unnecessary elaboration or repetition.
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 lack of annotations and output schema, plus the existence of many similar sibling tools, the description is insufficiently complete. A list operation needs more context about what 'list' means practically - does it return metadata, full content, paths only? How does it handle large vaults? Without this information, an agent cannot reliably use this tool.
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%, with the single parameter 'folder' clearly documented as 'Folder path within the vault (optional)'. The description doesn't add any additional parameter information beyond what's in the schema, which is acceptable given the high schema coverage. The baseline score of 3 reflects adequate but minimal 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 verb ('List') and resource ('all notes in the Obsidian vault'), making the purpose immediately understandable. However, it doesn't distinguish this tool from other list/search tools like 'list_tags', 'list_templates', or 'search_vault', which could cause confusion about when to use this specific tool.
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 multiple sibling tools like 'search_vault', 'search_by_tags', 'read_multiple_notes', and 'find_similar_notes', there's no indication of when this broad listing tool is preferable to more targeted search or read operations.
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 offers minimal behavioral context. It states the action ('move or rename') but doesn't disclose critical traits like whether this is a destructive operation, what happens if the destination path exists, permission requirements, or error handling. For a mutation tool with zero annotation coverage, this is inadequate.
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 action and scope, making it easy 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 this is a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns, error conditions, or behavioral nuances like atomicity or side effects. For a tool that modifies vault state, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters fully. The description adds no additional meaning beyond what's in the schema (e.g., path formats, vault structure, or rename vs. move semantics). 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 verb ('move or rename') and resource ('a note'), and specifies the scope ('in the Obsidian vault'). However, it doesn't explicitly differentiate from sibling tools like 'update_note' or 'manage_folder' that might also modify note locations or metadata.
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, exclusions, or compare with siblings like 'update_note' (which might handle content updates) or 'manage_folder' (which might handle folder-level operations).
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 offers minimal behavioral insight. It implies a read operation but doesn't disclose error handling (e.g., if some paths are invalid), performance characteristics (e.g., rate limits for batch reads), or output format (e.g., whether content is returned as raw text or structured data). The description adds little beyond the obvious 'read' action.
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 functionality ('Read content from multiple notes simultaneously'). There is zero wasted verbiage, and every word earns its place by specifying the action, target, and key differentiator (batch operation).
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 inadequate. It doesn't explain what 'content' entails (e.g., full text, metadata), how results are structured for multiple notes, or error scenarios. Given the complexity of batch operations and lack of structured context, more completeness is needed to guide the agent 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 input schema has 100% description coverage, with the 'paths' parameter fully documented in the schema itself. The description adds no additional meaning about parameters—it doesn't clarify path format, constraints, or examples. Since the schema does the heavy lifting, 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 ('Read content') and target resource ('from multiple notes'), making the purpose immediately understandable. It distinguishes from the sibling 'read_note' by specifying 'multiple notes simultaneously', though it doesn't explicitly contrast with other read-like tools like 'search_vault' or 'list_notes'.
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 batch reading is preferable over individual 'read_note' calls, nor does it address prerequisites like note accessibility or performance considerations. The agent must infer usage 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 the full burden of behavioral disclosure. It states the action ('Read') but doesn't mention whether this requires specific permissions, if it's safe (non-destructive), what happens on errors (e.g., invalid path), or the format of returned content. For a read operation with zero 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?
The description is a single, efficient sentence that directly states the tool's purpose without any fluff. It's appropriately sized and front-loaded, 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 lack of annotations and output schema, the description is incomplete. It doesn't explain what 'content' includes (e.g., raw text, metadata), how errors are handled, or any limitations (e.g., file size). For a tool with 1 parameter and no structured behavioral hints, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the 'path' parameter fully documented in the schema. The description adds no additional meaning beyond implying the note is identified by a path, which is already clear from the schema. 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 verb ('Read') and resource ('content of a note in the Obsidian vault'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'read_multiple_notes' or 'list_notes', which would be needed 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 like 'read_multiple_notes' for bulk operations or 'list_notes' for metadata. It lacks any context about prerequisites, exclusions, or typical use cases, leaving the agent to infer usage 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 states the tool suggests connections based on content similarity, but doesn't describe how it works (e.g., algorithm, performance implications), what it returns (e.g., format, structure), or any limitations (e.g., computational cost, data requirements). This leaves significant gaps for a tool that likely involves analysis.
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 unnecessary words. It's front-loaded with the core functionality, making it easy to understand at a glance, and every part of the sentence contributes essential information.
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 lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., a list of note pairs with similarity scores), how to interpret results, or any behavioral traits like performance or error handling. For a tool that analyzes content and suggests connections, more context is needed to use it 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 input schema has 100% description coverage, with clear documentation for both parameters ('threshold' and 'maxSuggestions'). The description doesn't add any parameter-specific information beyond what the schema provides, such as explaining what the similarity threshold means in practice or how suggestions are ranked. 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 tool's purpose: 'Suggest potential connections between notes based on content similarity.' It specifies the verb ('suggest'), resource ('connections between notes'), and mechanism ('content similarity'). However, it doesn't explicitly distinguish this from sibling tools like 'find_similar_notes' or 'analyze_note_relationships', which appear related but have different functions.
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 sibling tools like 'find_similar_notes' (which might find individual similar notes) or 'analyze_note_relationships' (which might analyze existing connections), leaving the agent to infer usage context 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 mentions 'content analysis' but doesn't specify how the analysis works, what types of tags are suggested (e.g., topics, entities), whether it's read-only or has side effects, or any performance considerations like rate limits. For a tool with no annotations, 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: 'Suggest tags for a note based on content analysis.' It is front-loaded with the core purpose, has zero wasted words, and is appropriately sized for the tool's complexity. Every part of the sentence contributes to understanding the tool's function.
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 lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., a list of tags, confidence scores), how the analysis is performed, or any limitations. For a tool that suggests tags based on content, more context is needed to understand its full behavior and output, making it inadequate for the agent's needs.
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 ('path' and 'maxTags'). The description adds no additional semantic context beyond what's in the schema, such as explaining the note format or tag selection criteria. Since the schema does the heavy lifting, a 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 tool's purpose: 'Suggest tags for a note based on content analysis.' It specifies the verb ('suggest'), resource ('tags'), and method ('content analysis'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'extract_keywords' or 'suggest_connections,' which might have overlapping functionality, preventing 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 doesn't mention prerequisites, such as needing an existing note, or compare it to siblings like 'add_tags' (which might apply tags) or 'extract_keywords' (which might return similar outputs). Without any context on usage scenarios or exclusions, the agent must infer when this tool is appropriate.
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, the description carries full burden but lacks critical behavioral details. It mentions 'text replacements, deletions or precise insertions' but does not disclose permissions needed, whether edits are atomic/undoable, rate limits, or error handling. This is inadequate 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 is front-loaded with the core purpose and uses clear, direct language 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?
For a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., side effects, error cases), usage context, and output expectations, leaving significant gaps for an agent to invoke it correctly.
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 parameters (path, edits, dryRun). The description adds no additional meaning beyond implying 'edits' involve text operations, but does not clarify syntax, format, or examples for the edits array. 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('update content') and resource ('existing note'), specifying the operation involves text modifications. It distinguishes from siblings like create_note (creates new) and delete_note (removes), but could be more explicit about differentiating from move_note (relocates) or apply_template (applies templates).
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. It does not mention prerequisites (e.g., note must exist), exclusions (e.g., not for creating new notes), or comparisons to siblings like edit_note (if present) or apply_template for structured changes.
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 'usage count', which adds context about the return data, but fails to describe other key behaviors such as pagination (implied by 'limit' parameter), error handling, or whether this is a read-only operation. For a tool with no annotations, this leaves significant gaps in understanding its operational traits.
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 ('List all tags in the vault') and adds a key detail ('with usage count'). There is no wasted text, and it's appropriately sized for a simple listing tool, making it easy to scan 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 low complexity (2 parameters, no output schema, no annotations), the description is somewhat complete but has gaps. It covers the basic action and a return detail, but without annotations or output schema, it should ideally mention more about behavior (e.g., read-only nature) or parameter usage. It's adequate as a minimum viable description but lacks depth for full contextual understanding.
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 2 parameters with 0% description coverage, so the description must compensate. It doesn't mention any parameters explicitly, but the phrase 'with usage count' hints at the 'sortBy' parameter's 'count' option. However, it doesn't explain 'sortBy' choices or 'limit' functionality. With low schema coverage, the description adds minimal value, meeting the baseline for partial compensation.
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 ('List') and resource ('all tags in the vault'), specifying what the tool does. It distinguishes from siblings like 'search_by_tags' or 'suggest_tags' by indicating it returns all tags with usage counts, not filtered or suggested ones. However, it doesn't explicitly differentiate from all siblings, such as 'list_notes' or 'list_templates', beyond the resource type.
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 'list_tags' over 'search_by_tags' for filtered results or 'suggest_tags' for recommendations, nor does it specify prerequisites or exclusions. Usage is implied by the action, but no explicit context is given.
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 action ('add backlinks') and scope ('entire vault'), but lacks critical details: whether this is a destructive operation (modifies notes), requires specific permissions, handles errors, or provides progress feedback. For a tool that likely modifies multiple notes, 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 a single, well-structured sentence that efficiently conveys the core functionality without redundancy. It front-loads the main action ('automatically add backlinks') and elaborates only as needed. Every word earns its place, making it highly concise.
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 (vault-wide processing with 6 parameters) and lack of annotations or output schema, the description is insufficient. It doesn't explain the return value (e.g., success status, report), error handling, or performance implications (e.g., time-intensive for large vaults). For a potentially destructive batch operation, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 6 parameters. The description adds no parameter-specific information beyond implying a vault-wide processing scope. This meets the baseline of 3, as the schema does the heavy lifting, but the description doesn't enhance understanding of parameter interactions or defaults.
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 ('automatically add backlinks') and the resource ('throughout the entire vault'), with precise mechanics ('detecting note names in content and converting them to wikilinks'). It distinguishes itself from siblings like 'suggest_connections' or 'analyze_note_relationships' by focusing on automated link creation rather than analysis or suggestion.
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., needing existing notes), exclusions (e.g., not for real-time editing), or compare to siblings like 'suggest_connections' (which might propose links without applying them). 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'List all available templates' implies a read-only operation, but it doesn't specify whether this requires permissions, how results are returned (e.g., pagination, format), 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, efficient sentence with zero waste: 'List all available templates'. It is front-loaded and appropriately sized for a simple list operation, with every word contributing to clarity without unnecessary elaboration.
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 the purpose but lacks details on behavior, output format, or usage context. For a basic list tool, this might suffice, but it doesn't provide enough information for optimal agent use without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, avoiding redundancy. Since there are no parameters, the baseline score is 4, as the description 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 'List all available templates' clearly states the verb ('List') and resource ('templates'), with 'all available' specifying scope. It distinguishes from siblings like 'create_template' or 'apply_template' by focusing on retrieval rather than creation or application. However, it doesn't explicitly differentiate from other list tools like 'list_notes' or 'list_tags' beyond the resource name.
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, context for usage, or compare it to similar tools like 'list_notes' or 'search_vault'. The agent must infer usage from the tool name alone, with no explicit when/when-not instructions.
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 mentions operations like 'delete' which imply destructive actions, but does not disclose behavioral traits such as permission requirements, whether deletions are permanent, error handling for invalid paths, or effects on linked notes. 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 that front-loads all key operations and the resource. There is zero waste—every word earns its place by clearly stating the tool's purpose without redundancy or unnecessary detail.
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 a multi-operation mutation tool with no annotations and no output schema, the description is incomplete. It lacks information on behavioral aspects (e.g., safety, permissions), output format, error conditions, or how operations interact with the vault structure. This is inadequate for a tool that can perform destructive actions like deletion.
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 parameters (operation, path, newPath) with descriptions and enum values. The description adds no additional meaning beyond what the schema provides, such as explaining path formats or operation-specific nuances. 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb ('Create, rename, move, or delete') and resource ('a folder in the Obsidian vault'), distinguishing it from sibling tools like create_note, move_note, or delete_note which operate on notes rather than folders. It precisely defines the tool's scope and differentiates it from alternatives.
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 folder operations in an Obsidian vault, but does not explicitly state when to use this tool versus alternatives (e.g., create_note for notes, move_note for moving notes). It provides context but lacks explicit guidance on exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/jianruidutong/obsidian-mcp'

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