ObsidianConnector

by luannn010

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: v0.1.0
Disambiguation4/5
Most tools have clear resource-action boundaries (e.g., read_note vs get_frontmatter vs search_notes). A few pairs like list_notes/list_directory and get_project_context/get_project_activity could cause initial confusion but descriptions resolve them.
Naming Consistency5/5
All tools follow a consistent verb_noun snake_case pattern, with verbs like get, list, create, update, delete, search, move, append. No mixed conventions.
Tool Count3/5
22 tools fall into the heavy range (16-25). While each tool has a specific function, the overall surface is broad and might be more than needed for typical Obsidian workflows.
Completeness4/5
Note lifecycle is fully covered (create/read/update/append/delete/search), plus vault registration and frontmatter handling. Missing directory deletion/rename and note metadata operations, but these are minor gaps.
Average 3.7/5 across 22 of 22 tools scored. Lowest: 3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds the list of content types (tasks, decisions, risks, etc.), which is useful context. However, it does not disclose any additional behavioral details such as aggregation rules, sorting, or how 'current' is defined, so it adds only moderate value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no fluff. It immediately states the verb and the specific content categories, making it easy to scan. Every word contributes meaning.
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?
The tool has 3 parameters and no output schema. The description is too brief to explain how the inputs map to the extraction, especially the meaning of 'current project' and how the vault parameter identifies the project. It also fails to describe the return structure or any limitations, leaving significant gaps for an agent trying to invoke it correctly.
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%, and the description does not explain the parameters (vault, maxChars, dailyLimit). The default values and types in the schema give some hints (e.g., maxChars likely limits output length), but this is implicit. The description fails to clarify what 'vault' refers to or how the limits affect results, so it only partially compensates for the lack of schema descriptions.
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 'Extract' and specifies the resource as 'current project tasks, decisions, risks, changelog entries, and recent daily notes.' This provides a specific scope and distinguishes from many sibling tools, though it does not explicitly compare to 'get_project_context', a close sibling.
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?
There is no guidance on when to use this tool versus alternatives, no mention of prerequisites, and no exclusions. The description only states what it does, leaving the agent to infer usage context from the name and sibling list.
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 safety annotations like readOnlyHint or destructiveHint are provided, so the description carries the burden of behavioral disclosure. It only mentions a prerequisite (registered writable vault) and does not disclose side effects, failure conditions, or permission requirements for the create operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with a specific verb and object. It contains no redundant words and every word contributes to the meaning.
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?
This is a mutating tool with no output schema, no parameter descriptions, and minimal annotations. The description leaves critical gaps about how the directory path should be specified, what happens on conflicts, and what the vault registration/writability requirements actually entail.
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?
The input schema has no descriptions for vault or directory (0% coverage), and the description only repeats the concepts of 'vault' and 'directory' without explaining the expected path format, relative vs absolute, or any constraints. The description fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create), the resource (directory), and the scope (inside a registered writable vault). This distinguishes it from sibling tools like create_note and create_vault, making the purpose specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating directories within an existing registered vault, but it does not explicitly state when to use this tool over alternatives or provide exclusions. The prerequisite 'registered writable vault' gives some context but no direct comparison to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool both creates and registers the vault, and constrains its operation to the configured parent directory. This aligns with the openWorldHint=false annotation, which indicates limited scope. However, it does not cover permissions, failure modes, or reversibility. With the annotation providing a baseline, the description adds moderate 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, direct sentence that gets straight to the point. It avoids unnecessary words and is front-loaded with the action, 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?
With four parameters, zero schema descriptions, and no output schema, the description is insufficiently complete. It explains what the tool does but lacks critical details about how parameters affect behavior, the registration process, and return values. This falls well short of what an agent needs for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about the parameters (name, readOnly, dateFormat, dailyDirectory). The agent cannot infer their meaning or expected values from the description alone. This is a critical gap for a 4-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates and registers a new vault, with a specific scope ('under the configured Obsidian vault parent directory'). This distinguishes it from sibling tools like register_vault (which presumably only registers an existing vault) and create_note (which creates a note). The verb+resource+scope pattern is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for new vault creation, but it does not explicitly state when to use it versus alternatives such as register_vault for existing vaults. The usage context is clear enough to infer, but there is no explicit 'when not to use' or mention of alternatives, leaving room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations only include openWorldHint: false, which provides no safety or side-effect information. The description says 'register' but does not disclose whether this writes to disk, modifies configuration, validates the path, or can override an existing registration. The phrase 'safe access' is vague and unexplained, leaving the agent without critical behavioral details.
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, focused sentence. It is front-loaded with the key action and resource, contains no filler or repetition, and every word contributes meaning. This is an example of appropriate minimalism.
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?
With five parameters, no output schema, and minimal annotations, the description provides only a bare statement of purpose. It lacks parameter explanations, side-effect disclosure, prerequisites, and any information about what 'safe access' entails. For an AI agent to invoke this tool correctly and safely, far more context is needed.
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%, so the description must compensate by explaining parameter meanings, but it does not mention any parameters. Although property names like 'path', 'name', and 'readOnly' are somewhat self-explanatory, 'dateFormat' and 'dailyDirectory' are ambiguous, and no guidance is given on required fields, defaults, or relationships between parameters.
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 uses a specific verb ('register') and identifies the resource ('existing Obsidian vault path') and the purpose ('for safe access'). This clearly distinguishes it from sibling tools like create_vault (which creates a new vault) and unregister_vault (which removes an existing registration).
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 word 'existing' implies this tool is for vaults that already exist on disk, suggesting a contrast with create_vault. However, there is no explicit statement of when to use this vs. alternatives, no preconditions (e.g., the path must exist, the vault must not already be registered), and no mention of when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description aligns with a read operation. The description adds minimal context beyond the annotation by specifying the data type (YAML frontmatter) and target (Markdown note), but it does not disclose additional behavioral traits such as return format or behavior if frontmatter is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It states the action and resource efficiently, earning every word.
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?
Although the description is adequate for a simple read tool, it does not describe the return format or behavior when frontmatter is absent, and it provides no parameter context. With no output schema and missing parameter semantics, the description is minimally complete but leaves gaps that could confuse the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has two required parameters (vault, path) with no property descriptions (0% coverage). The description does not explain either parameter or how they relate to the operation, leaving the agent to infer meaning solely from parameter names. This is a significant gap that the description fails to compensate for.
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 uses the specific verb 'Read' and identifies the exact resource: YAML frontmatter properties from a Markdown note. This clearly distinguishes it from sibling tools like read_note (which reads the entire note) and update_frontmatter.
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?
Usage is implied from the name and description—if you need frontmatter, use this tool—but there is no explicit guidance on when to use it versus alternatives like read_note or update_frontmatter. No exclusions or alternative scenarios are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With only openWorldHint=false and no safety annotations, the description carries the transparency burden. It discloses the key behavior of rejecting an existing destination by default (aligning with the overwrite default), but it does not explicitly state that the original source is removed (a destructive effect) or mention permission requirements or impact on backlinks. This is moderately transparent but leaves important mutation details undisclosed.
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 concise sentence that front-loads the primary action and resource, then adds a key behavioral detail. There is no redundant information; every word contributes value.
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 a destructive move operation with four parameters, no output schema, and minimal annotations, the description is too sparse. It fails to explain overwrite behavior, path rules, return values, error conditions, or the requirement that the vault be registered. The tool's disruptive nature demands more context than provided.
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%, so the description must compensate. It identifies a 'registered vault' and 'Markdown note' but does not explain path semantics (relative vs absolute), what 'sourcePath' and 'destinationPath' mean in practice, or what happens when overwrite=true. The brief mention of rejecting existing destinations adds limited meaning beyond the schema's default value.
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 uses the specific verb 'Move' and identifies the resource as 'a Markdown note inside a registered vault', clearly distinguishing this from sibling tools like create_note, update_note, or delete_note. It also specifies a key behavioral nuance (rejecting existing destinations) that separates it from a simple move.
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 the tool is for relocating notes within a vault but provides no explicit guidance on when to use it versus alternatives, nor any exclusions (e.g., moving across vaults). The purpose is clear enough that an agent could infer usage, but explicit when/when-not guidance is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description correctly aligns with that. It adds behavioral context beyond annotations by mentioning 'bounded content' (likely the maxChars parameter) and 'missing-note reporting', which are useful traits not captured by the annotations alone.
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 front-loads the verb and resource. Every word adds value, and it efficiently combines the core action with two key behavioral qualifiers.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter read-only tool with no output schema, the description covers the essential behavior: reading with content bounds and reporting missing notes. It does not detail the exact output format or error handling for unregistered vaults, but the key behaviors are sufficiently stated.
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%, so the description must compensate for parameter meanings. It only hints at 'bounded content' which loosely maps to maxChars, but does not explicitly explain the 'vault' parameter or what missing-note reporting entails. The schema itself provides constraints (default, min/max) but no semantic labels, leaving the description insufficient.
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 reads canonical project notes from a registered vault, using a specific verb and resource. It differentiates from generic note reads ('read_note') by mentioning 'canonical project notes' and 'missing-note reporting', but does not explicitly name alternative tools or contrast with siblings.
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?
Usage context is implied: one would use this tool to read project notes from a vault while imposing a content limit. However, no explicit guidance is provided on when to prefer this over siblings like read_note or get_project_activity, nor any exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds that only Markdown notes are considered and links are Obsidian wiki links. However, it does not disclose return format, ordering, or edge cases (e.g., whether the target itself is included). With annotation coverage, this is adequate but not rich.
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 sentence, starts with the verb, and contains no filler. Every word contributes to the meaning, making it highly efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with two string parameters and no output schema, the description provides the core purpose. However, the missing parameter semantics and lack of usage alternatives make it slightly incomplete for an agent to fully understand how to invoke it correctly.
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% and the description does not explain the 'vault' and 'path' parameters. The phrase 'target note' hints that 'path' points to the note, but this is not explicit. The description fails to compensate for the lack of schema descriptions, leaving parameter meaning ambiguous.
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 uses a specific verb ('List'), identifies the resource ('Markdown notes'), and scopes the operation to those containing 'Obsidian wiki links to a target note'. This clearly distinguishes it from sibling tools like list_notes or search_notes.
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 the use case (find backlinks for a target note) but provides no explicit guidance on when to choose this over alternatives, nor any exclusions or prerequisites. It falls into 'implied usage' rather than explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description adds value by specifying the tag sources. However, it does not disclose whether tags are deduplicated, sorted, or limited by the directory parameter, leaving some behavioral ambiguity.
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?
A single, front-loaded sentence that directly states the tool's purpose with no wasted words. It is appropriately concise for a read-only listing tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose but omits details about output format (no output schema) and parameter semantics. It is adequate for a simple tool but leaves gaps for an AI agent to use it correctly in varied situations.
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%, so the description must compensate by explaining parameters. It does not mention 'vault' or 'directory' at all, leaving their roles to inference from names. This is a significant gap for a 2-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('List') and resource ('tags'), and specifies the sources ('note frontmatter and Markdown hashtag syntax'). This distinguishes it from sibling tools like list_notes or get_frontmatter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you need tags from frontmatter or hashtags), but it does not explicitly mention alternatives or exclusion cases. It provides clear context but no comparative guidance against sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint: true, and the description adds the constraint that the vault must be registered and that the note is Markdown. This is useful context but does not elaborate on error behavior or response format, so it provides moderate added 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, front-loaded sentence with no unnecessary words. It is well-structured and immediately conveys the core function.
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?
With no output schema, the description does not explain what the tool returns (e.g., raw Markdown, parsed content, frontmatter). For a simple read operation, the description is adequate but incomplete regarding output expectations. The two required parameters are straightforward but lack semantic detail.
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 coverage is 0%, so the description must compensate for the undefined parameters. It only says 'from a registered vault' which indirectly relates to the vault parameter, but it does not explain path semantics (e.g., relative path, extension, case sensitivity). The parameter names are self-explanatory to some degree, but the description adds little beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb (read), resource (one Markdown note), and scope (from a registered vault). It distinguishes itself from siblings like list_notes, search_notes, and get_frontmatter by emphasizing a single note read.
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 reading a specific note by vault and path, but does not explicitly state when to use this function versus alternatives like search_notes or list_notes, nor does it mention any preconditions beyond a registered vault.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare the operation as read-only and not open-world. The description adds the useful behavioral detail of 'bounded excerpts' and restricts to 'registered-vault', but it doesn't disclose return format, pagination, or other edge-case behaviors. This matches the level of additional context seen in the calibration example.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core functionality and an important constraint (bounded excerpts) without unnecessary words. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description mentions bounded excerpts and registered-vault scope, it does not specify the return structure (e.g., fields per result), how the limit parameter behaves, or the meaning of the directory parameter. Given no output schema, more detail would be needed for full completeness.
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?
With 0% schema description coverage, the description must compensate for parameter semantics. It explains what the query searches (filenames, content, tags, frontmatter) and implicitly refers to vault, but it fails to explain the 'limit' and 'directory' parameters, which are non-obvious and could affect search scope and result size.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: searching registered-vault filenames, Markdown content, tags, and YAML frontmatter. The verb 'Search' is specific and the resource/scope is detailed, distinguishing it from sibling tools like list_notes or read_note.
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 the tool is used for searching across vault content, but it does not explicitly state when to use it versus list_notes or other retrieval tools. It provides no exclusions or alternative recommendations, leaving usage guidance to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the core behavior (append, not replace) and requires the note to already exist ('existing'), adding context beyond the openWorldHint annotation. However, it does not mention potential error behavior for non-existent paths, formatting details like newline insertion, or whether the operation is atomic. Some behavioral transparency is present but not comprehensive.
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 sentence of ten words, tightly scoped and front-loaded with the core action ('Append content'). It contains no filler and every word contributes to meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with three required parameters and no output schema. The description covers the primary function (append) and the key constraint (note must exist, content not replaced), which is sufficient for most use cases. It doesn't discuss edge cases like missing vault or whether a newline is automatically added, but given the tool's simplicity and the lack of output schema, the description is close to complete.
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%, and the description does not explain any parameters. While the three parameters (vault, path, content) are fairly self-evident from the tool name and siblings, the description does nothing to disambiguate their roles or constraints beyond the schema's own type/minLength definitions. With no parameter details provided, the description fails to compensate for the lack of schema descriptions.
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 uses a specific verb ('append') and resource ('existing Markdown note'), and explicitly contrasts with replacement ('without replacing it'), distinguishing it from update_note and create_note. This is a clear and unambiguous purpose statement.
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 phrase 'without replacing it' implies the tool is for adding content rather than overwriting, which hints at when to use it over update_note. However, there is no explicit when-to-use/when-not-to-use guidance or naming of alternative tools, so usage guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool 'Replace[s]' the note, which implies destructive overwriting, and mentions the concurrency safety mechanism. However, it does not explain what happens if the expected hash does not match, whether the note must exist, or any failure modes. With only openWorldHint=false as an annotation, the description carries the burden but provides only partial 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, tightly written sentence that immediately states the core action and a key optional feature. Every word earns its place, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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, no output schema, and sparse annotations, the description is a bit too brief. It covers the main function and a distinct feature, but it omits information about error conditions, prerequisites (e.g., existing file), and behavior on hash mismatch. In the context of sibling tools, it does enough to separate itself but leaves gaps for an agent to safely invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning to expectedHash by linking it to concurrency safety, and 'Replace' implies content is the full replacement. However, it does not elaborate on vault (the container) or path (the location), although these are self-evident from their names. The description provides some added value but not comprehensive parameter semantics.
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 uses the specific verb 'Replace' with a clear resource 'Markdown note', which distinguishes it from sibling tools like create_note, append_note, and move_note. The mention of an optional SHA-256 hash for concurrency safety further specifies the tool's unique scope.
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 replacing a note when concurrency safety is desired, but it does not explicitly state when to use this tool versus alternatives like create_note or append_note. No exclusions or alternative tools are named, leaving the usage context somewhat implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds the context that the vault must be 'registered' and that it fetches metadata, but does not disclose what happens on missing vaults or what fields the metadata includes. This is acceptable for a simple getter but adds limited extra 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, concise sentence that is front-loaded with the action. Every word is meaningful: 'Get metadata for one registered vault by name.' No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple: one parameter, read-only, clear purpose. The description covers the essential behavior even though there is no output schema. While the term 'metadata' is somewhat vague, it adequately conveys the purpose for a straightforward getter. The annotations and simple schema contribute to the tool's overall completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and there is one required string parameter 'vault'. The description clarifies that this is a name ('by name'), which adds meaning beyond the raw parameter name. However, it doesn't provide details on formatting, case sensitivity, or exact name matching. The description partially compensates for the lack of schema description.
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 'Get metadata for one registered vault by name.' It specifies a precise verb (get), resource (vault metadata), and scope (one registered vault by name). This differentiates it from sibling tools like list_vaults (which lists all) and register_vault (which registers).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when you need metadata for a single vault by name. It does not explicitly mention alternatives or exclusion criteria, but the word 'one' versus 'list' in siblings provides implicit usage context. No explicit 'use instead of...' guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses that only Markdown files and 'safe child directories' are listed, which is non-obvious filtering behavior. This adds valuable context about what the tool will and will not return, though it does not define what qualifies as 'safe.'
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the essential purpose without unnecessary words. It strikes an efficient balance between clarity and brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only listing tool, the description provides the core purpose but omits details about the return format (e.g., whether paths or names are returned) and what 'safe child directories' means. Given the absence of an output schema, these details would help complete the picture.
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?
The schema has no descriptions for 'vault' or 'directory,' and the description does not explain their semantics, such as whether 'directory' is optional, relative to the vault root, or what the default '' means. The phrase 'registered vault directory' hints at the vault parameter but leaves the directory parameter ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'Markdown files and safe child directories inside a registered vault directory.' This distinguishes it from sibling tools like list_notes or list_vaults by specifying the directory-level scope and the Markdown filter.
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 that the tool only works within a 'registered vault directory,' which provides some usage context. However, it does not explicitly mention alternatives or when to prefer this over similar list tools like list_notes or read_note, leaving room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a key behavioral trait not present in the annotations: the operation fails on an existing note unless overwrite=true. This goes beyond the minimal openWorldHint annotation and gives the agent actionable knowledge about idempotency and mutation behavior. It does not say what happens on success, but for a create operation this is a useful level of disclosure.
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 sentence, front-loaded with the primary action, and contains no fluff. Every word contributes meaning, balancing the main verb with the critical overwrite caveat.
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?
The tool is simple, but the description omits any mention of return value (no output schema exists) and side effects like directory creation or content format validation. However, it does capture the most important complexity (overwrite behavior) and the openWorldHint annotation adds a minor contextual signal. Overall it is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description carries the burden for parameter meaning. It explicitly explains the overwrite parameter (the most non-obvious one), but it does not elaborate on path, vault, or content beyond their names. Those names are fairly intuitive, but the description only partially compensates for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a Markdown note') and the resource (a Markdown note). It also includes a critical distinguishing behavior (fails if the note exists unless overwrite is true), which sets it apart from siblings like update_note and delete_note. The verb+resource pairing is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is for creating new notes and that overwriting requires explicit opt-in via the overwrite parameter, but it does not explicitly name alternatives or state when to prefer another tool (e.g., update_note for existing notes). The usage context is clear but exclusions are only implied, not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the critical behavioral trait of not overwriting existing content and indicates that it will either create or append. With only a minimal openWorldHint annotation, this description adds meaningful context about the tool's write behavior. It could be improved by stating whether the note is created if missing or how the date parameter is used, but it covers the main safety concern.
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 concise sentence that is front-loaded with the action. It contains no redundancy and every word adds value, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters, no output schema, and minimal annotations, so the description should do more to explain context such as how the daily note is configured, how date is used, and possible return values. It covers the core purpose but leaves several operational details unspecified, making it minimally viable but not complete.
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?
The schema has 0% parameter description coverage, and the description does not explain any of the parameters (vault, content, date). An agent cannot infer the meaning of 'vault' or how 'date' affects behavior from the description alone. This lack of compensation for the undocumented schema is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with specific verbs ('Create or append') and a specific resource ('configured daily note'). It emphasizes the key non-destructive behavior ('without overwriting existing content') and distinguishes this tool from sibling tools like append_note or create_note by targeting the daily note specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'configured daily note' implies this tool is for daily notes, providing clear context for when to use it. However, it does not explicitly exclude alternatives or compare to siblings like append_note, so there is no explicit 'when not to use' guidance. Score 4 reflects clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With only openWorldHint: false in annotations, the description carries significant weight. It explicitly states that files are not deleted, adding a key behavioral guarantee beyond the annotation. It does not disclose idempotency or error behavior, but for a simple registry operation, this is a strong level of 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, front-loaded sentence with no filler. It states the action and the key qualifier in under 15 words, making it optimally concise and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema. The description covers the core behavior and an important caveat, but the lack of parameter format details and return value expectations leaves gaps. It is adequate for a basic tool but not fully complete.
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?
The schema has zero description coverage for the 'vault' parameter (0%), and the description does not clarify whether the value should be a name, path, or ID. The agent must rely solely on the parameter name, which is insufficient for reliable invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Remove' and clearly identifies the resource 'a vault from the local registry'. It also adds the crucial qualifier 'without deleting its files', which distinguishes this tool from a delete operation and aligns with its purpose among sibling tools like register_vault and create_vault.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the usage scenario: unregister a vault while preserving its files. The phrase 'without deleting its files' provides a clear contrast to deletion, indicating when this tool is appropriate. However, it does not explicitly name alternative tools or state exclusions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only include openWorldHint:false, so the description carries the behavioral burden. It discloses that the operation is a merge and that the note body is untouched, but it does not explain how conflicting properties are handled, whether frontmatter is created if missing, or any other side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the key action ('Merge') and the key constraint ('without replacing the note body'). Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple three-parameter schema and the clear sibling context, this description is largely complete. It distinguishes the tool from other note operations, though it could add detail on behavior when frontmatter is absent or how existing properties are treated in the merge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must add meaning to the parameters. It indicates that 'properties' are the YAML frontmatter properties to merge, but does not explicitly describe the object structure of 'properties' or clarify the roles of 'vault' and 'path' beyond their names.
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 uses the specific verb 'merge' and clearly identifies the resource as 'YAML frontmatter properties'. The explicit constraint 'without replacing the note body' distinguishes it from sibling tools like update_note, which would update the entire note.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for frontmatter-only modifications and the phrase 'without replacing the note body' offers a clear contrast with whole-note updates. It does not explicitly name alternative tools or state when not to use it, but the context is sufficient for an agent to infer the appropriate scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the operation is not a permanent delete but a move to trash, adding meaningful context beyond the destructiveHint annotation. It also restricts the operation to Markdown notes, clarifying scope. It does not mention details like whether the trash folder is auto-created or if the operation can be undone, but the core behavior is well conveyed.
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?
A single sentence of about a dozen words that front-loads the action and includes no filler. Very efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema and an annotation flagging it as destructive, the description covers the essential behavior and clarifies the trash semantics. It could mention parameter formats or error cases, but it is largely sufficient for correct invocation.
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?
The schema has no descriptions for the vault and path parameters, and the tool description does not explain them either. While the names are self-explanatory, the description adds no explicit parameter guidance and thus fails to compensate for the 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool moves a Markdown note to the vault trash, a specific action that distinguishes it from a permanent delete and from the sibling move_note tool. The verb 'Move' and the resource 'Markdown note' make the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'instead of permanently deleting it' implies this tool is for reversible deletion, giving clear context for when to use it. However, it does not explicitly name alternative tools or state when not to use it, so it stops short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds valuable behavioral context: it requires a 'registered vault' and filters by directory, and clarifies that it lists only 'Markdown notes' rather than all files. This goes beyond the structured annotations and aligns with them; no contradiction.
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 front-loads the action and resource. It contains no redundant words or filler, making it maximally concise while still covering all essential aspects.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no output schema, but the description gives enough to understand its scope: vault prerequisite, optional directory, and Markdown notes. It does not specify return format (e.g., paths vs. names), sorting, or recursion, which might matter, but for a listing operation the description is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It does map both parameters: 'vault' corresponds to the registered vault, and 'directory' is the optional subdirectory filter. However, it does not explain path formats, whether the directory is exact or prefix, or traversal behavior, so the semantics are only partially clarified.
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 uses the specific verb 'List' with the resource 'Markdown notes in a registered vault' and an optional directory filter, clearly distinguishing it from sibling tools like list_tags, list_backlinks, and list_vaults. It unambiguously states what the tool returns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by specifying it operates on 'a registered vault' and optionally 'below a directory', making it obvious when to use this over tools like search_notes or read_note. However, it does not explicitly name alternatives or state when not to use it, so it falls short of the highest tier.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates a read-only operation. The description adds useful context by specifying that the vaults are 'explicitly registered', clarifying the scope of the list. It does not contradict the annotations and provides enough behavioral transparency for a simple list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It conveys the tool's purpose and scope efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only list tool with no output schema, the description adequately covers what the tool does. It could mention that it returns the list of vaults, but the verb 'List' and the context make this obvious enough. The description is complete for its simplicity.
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?
There are zero parameters, so the schema is fully covered at 100%. The description naturally has no parameter details to add. Per guidelines, a baseline of 4 is appropriate when there are no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'List the explicitly registered Obsidian vaults available for selection.' It uses a specific verb ('List') and resource ('registered Obsidian vaults'), and differentiates from sibling tools like register_vault or get_vault by focusing on enumeration of registered vaults.
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 ('available for selection') but does not explicitly state when to use this tool versus alternatives such as get_vault or register_vault. No exclusions or alternative recommendations are provided, leaving the guidance implicit.
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:

[![obsidianconnector MCP server](https://glama.ai/mcp/servers/luannn010/obsidianconnector/badges/card.svg)](https://glama.ai/mcp/servers/luannn010/obsidianconnector)

Score Badge

Copy to your README.md:

[![obsidianconnector MCP server](https://glama.ai/mcp/servers/luannn010/obsidianconnector/badges/score.svg)](https://glama.ai/mcp/servers/luannn010/obsidianconnector)

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/luannn010/obsidianconnector'

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