Provides tools for interacting with Obsidian vaults via the built-in CLI, enabling AI agents to read, create, update, and delete notes, manage properties, tasks, backlinks, tags, and perform vault operations without requiring plugins or API keys.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@obsidian-cli-mcp search for notes about project planning"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that wraps the official Obsidian CLI
(obsidian, bundled with the Obsidian desktop app) instead of the Local REST API plugin.
Each server instance is pinned to a single vault, so you run one entry per vault.
The REST-API MCP (mcp-obsidian) needs the Local REST API community plugin, an API key,
and a dedicated port per vault. This server drives the Obsidian app through its built-in
CLI, which needs no plugin and no API key, and exposes a much richer surface:
tasks, frontmatter properties, backlinks, search-with-context, vault metadata, and more.
Requirement: the Obsidian desktop app must be running with the target vault open. The CLI talks to the live app, not the files on disk.
Related MCP server: obsidian-mcp
The server is a uv project. No global install is needed —
MCP clients launch it on demand with uv run.
git clone <this repo> && cd obsidian-cli-mcp
uv sync # install dependencies
uv run pytest # run the test suite (no live Obsidian needed)Add one entry per vault to your MCP client config (e.g. Claude Desktop's
claude_desktop_config.json). The vault is selected with the OBSIDIAN_VAULT
environment variable — run obsidian vaults to see the exact names.
{
"mcpServers": {
"obsidian-cli-void": {
"command": "uv",
"args": ["run", "--directory", "/ABSOLUTE/PATH/TO/obsidian-cli-mcp", "obsidian-cli-mcp"],
"env": { "OBSIDIAN_VAULT": "void" }
},
"obsidian-cli-notebook": {
"command": "uv",
"args": ["run", "--directory", "/ABSOLUTE/PATH/TO/obsidian-cli-mcp", "obsidian-cli-mcp"],
"env": { "OBSIDIAN_VAULT": "notebook" }
}
}
}Variable | Required | Default | Purpose |
| yes | — | Vault name this instance targets (injected as |
| no |
| Path to the CLI binary if it isn't on |
| no |
| Run the vault guard before reads too (not just writes). |
| no |
| Allow |
| no |
| Per-command subprocess timeout (seconds). |
| no |
| Seconds to cache a successful vault-guard check. |
| no |
| Log level (logs go to stderr). |
Read / navigate: read_note, search_vault, list_files, list_folders,
note_info, list_backlinks, list_tags, list_tasks, list_properties,
read_property, vault_info, list_vaults
Write / organise: create_note, add_to_note, set_property,
remove_property, move_note, rename_note, delete_note, update_task
Escape hatch: run_obsidian — run any other CLI command (e.g. bookmarks,
wordcount, history). Disruptive commands (restart, reload, eval,
devtools, plugins:restrict, and all dev:*) are blocked.
Notes are addressed by file (resolve by name, like a wikilink) or path
(exact folder/note.md). Most read tools fall back to the active note when both
are omitted; write tools require an explicit target.
The Obsidian CLI silently falls back to the active vault when vault=<name>
names a vault that isn't currently open. To prevent acting on the wrong vault,
this server verifies — via vault info=name — that the configured vault is the
one actually responding before every write (and before reads, by default). If it
isn't, the tool fails with a clear message instead of touching another vault.
This also means the CLI reports failures on stdout with exit code 0; the server detects them by inspecting the output, so genuine errors surface as MCP tool errors rather than being mistaken for success.
MIT © digster
Append or prepend content to an existing note.
position is "append" (default) or "prepend". inline=True adds the content
without a leading/trailing newline.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | ||
| file | No | ||
| path | No | ||
| position | No | append | |
| inline | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 explains that content is appended or prepended and how position and inline affect the result. However, it does not mention side effects (e.g., whether the note must exist) or error behavior, leaving some transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (3 lines) and front-loaded with the main action. It uses clear formatting for parameter details. No unnecessary words, but the omission of file/path is a content issue, not structural.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, 0% schema coverage) and lack of annotations, the description should compensate more. It covers the core action but fails to address the file and path parameters, which are essential for usage. The presence of an output schema does not reduce the need to clarify inputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It adds meaning for content, position, and inline, but completely omits file and path, which are crucial for identifying the note. This leaves significant ambiguity about how to specify the target note.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Append or prepend content to an existing note.' It uses specific verbs and specifies the resource, distinguishing it from siblings like create_note (which creates a new note) or read_note (which reads content).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the primary use case (modifying an existing note by adding content) and details parameters like position and inline. While it does not explicitly list alternatives or exclusions, the context of sibling tools makes the usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new note.
Use name for a simple title or path for an exact location. Optionally
seed content or apply a template. Set overwrite=True to replace an
existing note (otherwise creation fails if it exists).
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| path | No | ||
| content | No | ||
| template | No | ||
| overwrite | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that creation fails if the note exists unless overwrite=True, a key behavioral trait. It does not cover permissions or side effects, but for a create tool, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, then parameter guidance, then a behavioral note. No fluff; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 optional parameters and an output schema, the description covers essential aspects: creation behavior, parameter semantics, and overwrite option. It is complete enough for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, but the description explains all 5 parameters: name vs path, content, template, and overwrite. It adds semantic meaning by specifying when to use each, e.g., 'Use name for a simple title or path for an exact location.'
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new note', identifying the verb and resource. It distinguishes from siblings like add_to_note, delete_note, etc., by focusing on creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear guidance on using name vs path and overwrite behavior. However, it does not explicitly contrast with sibling tools like add_to_note (which might modify existing notes), but the context is sufficient for most cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a note (moves it to trash by default — recoverable).
permanent=True bypasses trash and is only allowed when the server is
configured with OBSIDIAN_ALLOW_PERMANENT_DELETE=true.
| Name | Required | Description | Default |
|---|---|---|---|
| file | No | ||
| path | No | ||
| permanent | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It reveals that deletion is recoverable by default and explains the permanent option's server requirement, but omits other behavioral details like error handling, auth needs, or success indicators.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: first states the primary purpose, second adds a key nuance. It is front-loaded and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of deletion (recoverable vs permanent) and no annotations, the description is incomplete. It fails to clarify the difference between 'file' and 'path' parameters, which is critical for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage. The description only explains the 'permanent' parameter, leaving 'file' and 'path' completely undefined. This is a significant gap for a tool with multiple ambiguous parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deletes a note and explains the default behavior (moves to trash, recoverable). It distinguishes itself from sibling tools like 'move_note' and 'rename_note' which operate on file location or naming, not deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks explicit guidance on when to use this tool versus alternatives. It does explain the permanent parameter's condition, but does not compare with other note operations or provide 'when-not' scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List notes that link to the target note (JSON). counts=True adds link counts.
| Name | Required | Description | Default |
|---|---|---|---|
| file | No | ||
| path | No | ||
| counts | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behaviors. It mentions the output is JSON (already implied by output schema) and the effect of the 'counts' parameter, but does not explain what happens when both 'file' and 'path' are provided, error conditions, or any required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two sentences) with no unnecessary words. It efficiently conveys the core purpose and a key parameter option. However, it could be slightly expanded to cover common parameter combinations without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description fails to provide sufficient context for all three parameters. It omits explanations for 'file' and 'path', which are critical for correct invocation. The lack of error handling or default behavior notes makes it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 only explains the 'counts' parameter ('adds link counts'). The 'file' and 'path' parameters have no explanation in either the schema or the description, leaving their semantics ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('list') and resource ('backlinks' as notes linking to a target note). It specifies the output format (JSON). This distinguishes it from sibling list tools like list_files or list_tags.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as note_info or search_vault. No mention of prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List files in the vault, optionally filtered by folder and/or ext.
| Name | Required | Description | Default |
|---|---|---|---|
| folder | No | ||
| ext | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only states the operation is a list, but does not mention read-only nature, pagination, recursion, or limits. This is insufficient for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, very concise, and front-loads the action. However, it lacks structure and does not fully capitalize on its brevity to convey additional useful information; it is just barely complete enough to earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description does not explain what is returned (e.g., file names, paths, metadata). With no annotations and a simple but not fully specified tool, the description leaves gaps regarding scope (depth) and inclusion of folders vs. files.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description must add meaning. It mentions 'folder' and 'ext' filters but does not explain their format (e.g., full path vs. name, with/without dot). Minimal value added beyond the schema's property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists files in the vault and mentions optional filters, which distinguishes it from sibling tools like 'list_folders' or 'search_vault'. However, it does not specify what qualifies as a file (e.g., all vault files or just markdown), leaving minor ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for general file listing with optional filters, but provides no explicit guidance on when to use this vs. alternatives like 'search_vault' or 'list_folders'. The mention of filters gives some context, but no when-not-to-use or prerequisite information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List folders in the vault, optionally under a parent folder.
| Name | Required | Description | Default |
|---|---|---|---|
| folder | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral disclosure burden. It does not mention that the tool is read-only, whether listing is recursive or flat, or any other behavioral traits beyond 'list folders'. This is insufficient for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 13 words, front-loaded with the main action. There is no unnecessary information, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (1 optional param) and existence of an output schema (not shown), the description is adequate but lacks details on whether listing is recursive or just direct children, which could affect agent behavior. It is minimally complete but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter with 0% description coverage, so the description must compensate. It adds value by explaining the 'folder' parameter as 'optionally under a parent folder', giving meaning beyond the schema's type and default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List folders in the vault' with a specific verb and resource. It differentiates from siblings like list_vaults (different resource) and list_files (different resource) by specifying 'folders'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives like search_vault or list_vaults. There is no mention of exclusions or context for 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.
List frontmatter properties for the vault or a specific note (JSON).
| Name | Required | Description | Default |
|---|---|---|---|
| file | No | ||
| path | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry behavioral info. It states the function and scope but lacks details on side effects, permissions, or what 'vault' means (e.g., returns properties from all notes?).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no fluff. Gets the essential point across efficiently, though could benefit from slightly more structure (e.g., bullet points for parameters).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with an output schema (not shown), the description is adequate. It covers scope and format. Missing details on parameter mapping but overall complete for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%. Description does not explain the two parameters (file, path) or how they map to 'vault or specific note'. No value added beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb (list), resource (frontmatter properties), scope (vault or specific note), and format (JSON). Distinguishes from sibling tools like read_property or set_property.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for retrieving properties globally or per note, but no explicit guidance on when to use this vs. alternatives like read_property or vault_info.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List tags in the vault, or for a specific note (JSON). counts=True adds counts.
| Name | Required | Description | Default |
|---|---|---|---|
| file | No | ||
| path | No | ||
| counts | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. Only states counts=True adds counts; does not mention read-only nature, error cases, or rate limits. Lacks sufficient 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise, one line plus a code hint. Front-loaded, no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three parameters and output schema exists, description lacks details on parameter usage (e.g., file vs path) and does not summarize return structure. Incomplete for agent to use effectively without guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must explain parameters. Adds meaning for 'counts' (adds counts) and hints that file/path specify a note ('or for a specific note'), but does not clarify their roles or mutual exclusivity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'List tags in the vault, or for a specific note'. Verb 'list' and resource 'tags' are specific. Distinguishes from sibling tools like list_files or list_properties, though does not explicitly differentiate from list_properties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. The description mentions scoping to a note but does not explain scenarios where this is preferred over search_vault or note_info.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List tasks across the vault or a note (JSON).
Filter with todo=True (incomplete), done=True (completed), or a specific
status character (e.g. "/" for in-progress).
| Name | Required | Description | Default |
|---|---|---|---|
| file | No | ||
| path | No | ||
| todo | No | ||
| done | No | ||
| status | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes filtering behavior but omits important details such as default behavior (e.g., what is returned if no filters are set), whether it is destructive, or if authentication is needed. The description does not cover these aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences. The first sentence states the purpose, and the second provides filter details. It is well-structured and front-loaded, avoiding unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, 0% schema coverage, and no annotations, the description lacks completeness. It does not explain the return structure (though output schema exists), default behavior, or limitations. The description only partially covers filtering, leaving gaps for a tool with this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It explains todo, done, and status filters with examples, but does not explain file and path parameters. This partial coverage brings the score to 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (List), the resource (tasks), and the scope (across vault or a note). It also specifies the output format (JSON). This distinguishes it from sibling tools like list_files or list_tags, which have different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides specific filtering options (todo, done, status) with example usage, but it does not explicitly state when to use this tool over alternatives like search_vault or list_files. No 'when not to use' guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Obsidian vaults known to this machine, with their paths.
Useful for discovering the exact vault name to put in OBSIDIAN_VAULT. This is a machine-level query, so it is not scoped to the configured vault.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description correctly implies a read-only, non-destructive operation (listing vaults). Without annotations, it carries the full burden, and it adequately describes the function. However, it does not detail the output format or any side effects, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences deliver the core purpose, the key use case, and a critical scope note. No unnecessary words; the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, the presence of an output schema, and the clear description, all necessary information is provided. The description covers the tool's action, utility, and scope, making it fully actionable for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description's role in parameter semantics is minimal. It adds value by explaining the output (paths) and the use case (vault name discovery), which goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action 'list all vaults known to this machine, with their paths' and explicitly distinguishes the machine-level scope from vault-specific operations. The utility for discovering the vault name is directly stated, leaving no ambiguity about the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear guidance that the tool is for discovering vault names to set the OBSIDIAN_VAULT environment variable. It explicitly notes the machine-level scope, contrasting with vault-scoped tools. However, it does not explicitly describe when to avoid this tool or name specific alternatives, which would improve the score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Move a note to a destination folder or path (to).
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | ||
| file | No | ||
| path | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states the action 'move' with no details on effects such as whether the original is deleted, permissions needed, or error behavior. No annotations exist to supplement, leaving significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence without fluff. However, it could be more structured by listing parameter roles, but it earns a high score for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three parameters and no annotations, the description is insufficient for correct invocation. The agent lacks information on parameter relationships, input formats, and return behavior despite an output schema existing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should explain all parameters. It only partially explains 'to' as the destination, while 'file' and 'path' are left undefined, forcing agents to infer their purpose from names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool moves a note to a destination, specifying the verb 'move' and resource 'note'. It distinguishes from siblings like delete_note or rename_note, but does not clarify the role of 'file' and 'path' parameters, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use move versus alternatives like rename_note or copy-like operations. There is no mention of prerequisites (e.g., note existence) or scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show metadata for a note (size, dates, counts). Defaults to the active note.
| Name | Required | Description | Default |
|---|---|---|---|
| file | No | ||
| path | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states metadata retrieval and default behavior but does not disclose any limitations, side effects, or authorization needs. Minimal but accurate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that efficiently communicates the core purpose and default behavior. No wasted words, but could benefit from listing metadata types explicitly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, return value explanation is not needed. However, the description lacks context on when to use this tool over siblings and does not explain parameter usage. Adequate for a simple tool but incomplete for the complex sibling set.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only mentions defaulting to active note. Does not explain the difference between 'file' and 'path' parameters or how they relate to the active note concept. Adds the default context but lacks parameter-specific guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool shows metadata for a note, listing specific types (size, dates, counts) and defaults to active note. Distinguishes from siblings by focusing on metadata rather than content or properties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance. With 20 sibling tools, the description should indicate when to prefer this over related tools like read_note or list_properties. The default behavior is mentioned but no alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a note's full Markdown contents.
Specify the note by file (name) or path (exact). If both are omitted,
the currently active note in Obsidian is used.
| Name | Required | Description | Default |
|---|---|---|---|
| file | No | ||
| path | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden. It discloses that it reads Markdown contents and defaults to the active note. No side effects are implied, which is appropriate for a read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The main action is front-loaded, and the parameter usage is clearly explained in the second sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with an output schema, the description is complete. It covers what the tool does, how to specify the note, and the fallback behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description explains that 'file' is the name and 'path' is the exact path, and both are optional. It adds the key behavior that omitting both uses the active note.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it reads a note's full Markdown contents, specifying the verb and resource. It distinguishes from sibling tools like create_note or delete_note by focusing on reading.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains how to specify the note (by file name or path) and the fallback to the active note. It provides clear usage context but does not explicitly mention when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a single frontmatter property name from a note.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| file | No | ||
| path | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only says 'Read', which implies non-destructive behavior. No details on error handling (missing file or property) or return format are provided, leaving significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence delivers the core purpose. It is efficient, though additional structure (e.g., listing parameters) could improve clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters and no schema descriptions, the description covers the main action but omits details on file/path usage. Output schema exists, so return values are covered, but overall context is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description should compensate. It explains the 'name' parameter (property name) but does not mention 'file' or 'path' parameters, leaving their meaning unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Read' and the resource 'frontmatter property', and distinguishes from sibling tools like list_properties (reads all) and set_property (writes).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives like read_note or list_properties. The usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a frontmatter property name from a note.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| file | No | ||
| path | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It only states the action but does not disclose side effects (e.g., whether the note file is modified), error conditions (e.g., property not found), or required permissions. The output schema exists but is not described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that directly states the tool's purpose with minimal verbosity. The description is front-loaded and contains no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite its simplicity, the description omits necessary context: how to identify the note (file/path), expected return value (output schema exists but not described), and any prerequisites or error handling. The agent may fail to use the tool correctly without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It explains the 'name' parameter (the property to remove) but provides no context for 'file' or 'path', which are critical for identifying the target note. The agent cannot infer how to specify the note correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (remove) and resource (frontmatter property), distinguishing it from sibling tools like set_property and read_property. However, it does not mention how the note is identified, leaving ambiguity about the file/path parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. It does not contrast with set_property or other siblings, leaving the agent without decision-support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rename a note to a new name (keeping it in the same folder).
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| file | No | ||
| path | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states renaming and folder preservation, but discloses nothing about name conflicts, overwriting behavior, or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the main action, but could be more structured without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and multiple sibling tools, the description fails to explain how to specify the note or the success/failure behavior, making it incomplete for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate, but it only explains the 'name' parameter. The 'file' and 'path' parameters are not described, leaving ambiguity about how to identify the note.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'rename' and the resource 'note', and explicitly notes that it keeps the note in the same folder, distinguishing it from sibling 'move_note'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that if you want to change the folder you should use move_note, but does not provide explicit when-to-use or alternatives. No context or prerequisites are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run any Obsidian CLI command not covered by a dedicated tool (power users).
Pass the command name (e.g. "bookmarks", "wordcount", "history") and a
params mapping of CLI options. Boolean flags should be passed as true
(e.g. {"total": true}); value options as strings (e.g. {"format": "json"}).
Set json=True to parse the output as JSON. The configured vault is injected
automatically and the vault guard still applies.
Disruptive commands (restart, reload, eval, devtools, plugins:restrict) and
all dev:* commands are rejected.
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | ||
| params | No | ||
| json | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: the configured vault is injected automatically, vault guard applies, and disruptive commands are rejected. It explains how to pass flags and parse JSON output. However, it does not describe error handling or what happens on invalid commands.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured into clear paragraphs: purpose, parameter usage, and restrictions. It is front-loaded with the main purpose. While it could be slightly more concise, it remains efficient without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity as a CLI wrapper, the description covers usage, parameter details, and restrictions. It does not list all possible commands, which is acceptable. There is no output schema, but the json parsing flag is mentioned. Adequate for the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description adds essential semantics: it explains that `command` is the CLI name, `params` is a mapping with examples (booleans as true, values as strings), and `json` parses output. This compensates fully for the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool runs any Obsidian CLI command not covered by a dedicated tool, and targets power users. This distinguishes it from siblings like create_note or search_vault by covering the gap of unsupported commands.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says when to use (any CLI command not covered by dedicated tools) and when not to use (disruptive commands like restart, reload, etc. are rejected). It provides examples for boolean flags and value options, giving clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the vault for text and return matching files (JSON).
Set context=True to also get the matching lines around each hit, path to
limit to a folder, limit to cap results, and case=True for case-sensitive
matching.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| path | No | ||
| limit | No | ||
| context | No | ||
| case | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description takes on the full burden. It explains key behaviors: returns matching files as JSON, context lines with context=True, folder filtering with path, result limit with limit, and case-sensitive matching with case=True. It omits details about error handling or default behavior but covers primary functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: first states the core purpose, second lists parameter settings. It is concise, front-loaded, and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool complexity (5 params, 1 required) and presence of an output schema, the description covers all user-facing behavior. It explains every parameter and the return format. No critical gaps are evident.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain all parameters. It does so effectively: query is implied as the search text; context, path, limit, and case are each described with their effects. This adds meaning beyond the schema's type and default values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search the vault for text and return matching files (JSON)', which identifies the action (search), resource (vault), and output format (JSON). It distinguishes from sibling tools like list_files by specifying search functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool versus alternatives. It explains parameters but lacks explicit 'when to use' or 'when not to use' context relative to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set a frontmatter property name=value on a note.
type may be one of text, list, number, checkbox, date, datetime.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| value | Yes | ||
| type | No | ||
| file | No | ||
| path | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only states the operation is a write, but omits behavior like overwrite behavior, validation rules, requirements (e.g., active note), or effects on existing properties. The optional file/path parameters are not explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two succinct sentences. The first clearly states the function; the second lists type options. No unnecessary words, but could be better structured (e.g., separate line for file/path).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and an output schema not shown, the description is incomplete. It does not cover side effects, return values, or how file/path default. The sibling tools are numerous, yet no comparison is provided. The note modification context is only partially addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description explains `name`, `value`, and `type` (with examples), but completely omits `file` and `path`. This leaves two parameters undocumented, which is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: setting a frontmatter property on a note, specifying the format `name`=`value` and listing valid types. It differentiates from siblings like read_property and remove_property.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention whether it should be used over add_to_note or when not to use it. The sibling set includes many note tools, but no selection criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a task's status.
Identify the task by ref ("path:line") or by file/path + line.
action is "toggle", "done", or "todo". Alternatively pass a status
character to set it directly (e.g. "/" for in-progress).
| Name | Required | Description | Default |
|---|---|---|---|
| action | No | toggle | |
| ref | No | ||
| file | No | ||
| path | No | ||
| line | No | ||
| status | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the modification behavior and parameter options, but does not mention side effects, return values, or permissions. It is adequate 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences, front-loading the main purpose. Every sentence adds necessary detail without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description sufficiently covers the tool's behavior for a simple update operation. It lacks details on error handling or prerequisites, but is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining the identification methods (ref vs file/path+line) and the action/status parameter values. It adds meaning beyond the raw schema, though some details (like exact accepted status characters) are left to inference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool updates a task's status, distinguishing it from sibling tools like list_tasks or create_note. The verb 'update' and resource 'task' are specific and clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains how to identify the task and the available actions, but does not explicitly state when to use this tool over alternatives or provide exclusions. However, the context makes it clear this is for updating status, not for listing or creation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show info about the configured vault (name, path, file/folder counts, size).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It describes a read operation but doesn't explicitly state it's non-destructive or safe. Adequate but lacks explicit safety disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, 12 words, direct and without any extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple info tool with no parameters and an output schema, the description lists all relevant output fields (name, path, counts, size). Complete for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters in schema (coverage 100%), description adds context about what info is returned, meeting baseline for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool shows info about the vault, listing specific details (name, path, file/folder counts, size). It distinguishes from siblings like list_vaults (list multiple vaults) and note_info (specific note).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines provided; no indication of when to use this vs alternatives like list_vaults or list_files. Agent must infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0add_to_notecreate_notedelete_notelist_backlinkslist_fileslist_folderslist_propertieslist_tagslist_taskslist_vaultsmove_notenote_inforead_noteread_propertyremove_propertyrename_noterun_obsidiansearch_vaultset_propertyupdate_taskvault_infoEach tool targets a distinct action and resource. The list_* family (files, folders, tags, etc.) has clear boundaries, and CRUD operations are separate. No two tools could be easily confused.
All tool names follow a consistent verb_noun or list_noun pattern (e.g., create_note, list_tags). The few exceptions like note_info and vault_info are clearly compound nouns and do not break the pattern.
21 tools is slightly above the typical 3-15 range, but each tool addresses a specific need. The list_* tools could be simplified, but the count is still reasonable for a comprehensive Obsidian CLI interface.
The tool set covers most common operations: CRUD on notes, properties, tasks, search, and vault management. The run_obsidian fallback fills gaps. Missing a dedicated 'replace note content' tool is a minor gap that can be worked around.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Search your Obsidian vault to quickly find notes by title or keyword, summarize related content, a…
Search and reason over your Obsidian-style Markdown vault, right from ChatGPT.
Connect AI assistants to your GitHub-hosted Obsidian vault to seamlessly access, search, and analy…
Create, validate, edit, export (markdown/svg/png/mermaid), and search JSON Canvas files.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/digster/obsidian-cli-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server