kObsidian MCP

Server Quality Checklist

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

Latest release: v0.3.4
Disambiguation4/5
Tools are generally distinct with clear categories (notes, links, tags, etc.), but some potential overlap exists between dataview.query and dataview.fields.write, and between multiple search tools (notes.search, tags.search, tasks.search).
Naming Consistency5/5
All tools follow a consistent category.tool naming pattern with clear verbs (list, create, read, etc.), making the surface predictable and easy to navigate.
Tool Count3/5
42 tools is a large surface for an Obsidian assistant, covering many features but feeling somewhat heavy. Some tools could be consolidated (e.g., multiple links.* tools).
Completeness3/5
Covers core Obsidian operations well, but missing a notes.move tool for renaming, and no simple tool to list all notes (only search). Wiki tools are extensive but other areas are slightly incomplete.
Average 4.6/5 across 42 of 42 tools scored. Lowest: 4/5.
See the Tool Scores section below for per-tool breakdowns.
- 4 of 4 community issues answered or closed in the last 6 months
- 5 commits in the last 12 weeks
- Last stable release on July 16, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under Apache 2.0.
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.
This repository includes a glama.json configuration file.
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.
View related servers

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 cover read-only, destructive, idempotent hints. Description adds context about splitting tags and vault selection behavior, but doesn't mention edge cases like missing note or no tags. Adds moderate value beyond 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?
Three sentences, front-loaded with main purpose, no unnecessary words. Each sentence serves a distinct function: result, usage guidance, context.
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 output schema exists, return values need not be described. Description covers primary usage, vault selection, and sibling distinction. Missing edge cases (e.g., no tags, non-existent path) but overall complete for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema describes 'path' param well, but 'vaultPath' has no schema description. Description compensates by explaining vaultPath overrides default vault, adding meaning. Baseline for 50% schema coverage is low, so description provides partial improvement.
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?
Clearly states the tool returns tags from a single note split into three categories. Distinguishes from sibling tags.search by specifying it's for one note vs scanning whole 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?
Explicitly says when to use (for one note's tags) and contrasts with tags.search. Also mentions vault selection context. However, doesn't explicitly state when not to use or list alternatives other than the sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description claims replace mode is 'idempotent-destructive,' contradicting annotations where idempotentHint and destructiveHint are both false. This is a serious inconsistency. Additionally, it lacks disclosure of permissions or other side effects beyond the annotation contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a general statement, mode details, vault context, and three examples. It is slightly lengthy but every sentence adds value; could trim redundant phrasing like 'always wins'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the annotation contradiction, the description covers all necessary context: modes, parameters, failure conditions, vault selection, and provides examples. Output schema exists, so return values need not be explained. The description is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no properties, but the description defines all parameters (mode, path, content, anchor, vaultPath) with clear semantics, including enum values for mode and anchor usage. This fully compensates for the missing schema definitions.
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 mutates the body of an existing note and explains the modes (replace, append, etc.). It distinguishes from notes.create by noting that the note must exist, offering a clear verb+resource action with sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use (edit note body) and when not to: 'Fails if the note does not exist — use notes.create first.' It also explains mode selection and vault context, providing clear guidance on 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, destructiveHint, idempotentHint, openWorldHint. The description adds that the tool requires specific plugins and operates on the active vault. However, it mentions an optional 'vaultPath' parameter that does not exist in the input schema, which is misleading and reduces trust.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise with two paragraphs. However, the second paragraph introduces a non-existent vaultPath parameter, which is an inaccuracy that slightly undermines conciseness. Otherwise, it is well-structured and front-loaded.
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 tool's complexity (arbitrary DQL), the description covers prerequisites, vault context, and fallback guidance. An output schema exists (not shown), so return values are covered. The missing vaultPath in the schema is a gap, but overall the description is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'query' has 100% schema description coverage, so baseline is 3. The description adds concrete DQL examples and clarifies raw DQL usage, which provides additional semantic value beyond the schema. The misleading vaultPath reference is not about this parameter, so it doesn't detract significantly.
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 executes arbitrary DQL queries, provides concrete examples, and distinguishes from sibling tools by mentioning the simpler sugar tools (listByTag, etc.). This makes the purpose highly 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises when to use this tool versus alternatives: 'prefer those when applicable and fall back to dataview.query for custom DQL.' It also lists prerequisites (Dataview plugin, Local REST API configured) and explains vault selection context.
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 idempotentHint=true. The description reinforces 'Read-only' and adds that result items can be used with `tasks.toggle` or `tasks.updateMetadata`. It also mentions the vault selection behavior. This is adequate extra context 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 concise, front-loaded with the main purpose, and contains no unnecessary words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 10 parameters, 90% schema coverage, and an output schema, the description covers all essential aspects: filters, results, usage context, vault selection, and links to sibling tools. No significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 90%, so schema already documents most parameters. The description adds meaningful context: it enumerates filter types, explains that sortBy controls ordering and limit caps results, and clarifies vaultPath overrides session vault. This provides value 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 the tool scans vault for Tasks-plugin markdown task lines and filters by various criteria. It distinguishes from sibling `tasks.stats` by specifying that search gives per-task details while stats gives counts. The verb 'scan' and resource 'markdown task lines' are specific.
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 specifies when to use (to find tasks with filters) and explicitly mentions an alternative `tasks.stats` for vault-wide counts. It also explains how the vault context works (session-active vs explicit vaultPath). However, it does not compare with other sibling tools like `notes.search` or `dataview.query`.
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 all annotations false, the description carries the full burden. It clearly states what the tool does and does not do (does not change the live Obsidian process), mentions gating via env vars, and notes HTTP deployment sharing. It provides sufficient behavioral context without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear first sentence, followed by detailed explanations and examples. While it is relatively long, every section adds necessary context, and it is not overly verbose for the complexity of the tool.
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 tool's role in setting session state and the presence of an output schema, the description covers identification methods, precedence, gating, HTTP behavior, and scope limitations. It is nearly complete, though it could mention error handling if no matching vault is found.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions. The tool description adds value by explaining the precedence chain, mutual exclusivity (already in schema), and the ad-hoc path capability. Examples further illustrate usage.
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 sets the session-active vault for subsequent filesystem tool calls, which distinguishes it from siblings like vault.list (list vaults) and vault.reset (reset selection). It also differentiates from workspace.* tools that remain tied to the API URL.
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 explains the precedence chain (per-call vaultPath overrides session selection, which overrides env var) and provides guidance on when to use per-call vaultPath instead, especially for HTTP deployments. It also notes that this tool does not affect workspace.* and commands.* tools, giving context on its scope. However, it could be more explicit about alternatives like vault.current.
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 confirm read-only, non-destructive, idempotent behavior. The description adds that it never writes, and explains output structure and staleness defaults, adding value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear front-loaded purpose, parameter context, and examples. It is slightly lengthy but each sentence adds value.
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 output schema exists, the description adequately covers the tool's behavior, finding categories, and pairing suggestions. It is complete for a read-only diagnostic tool with good annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions. The description adds context on defaults (180 days) and vault overriding logic, with examples illustrating usage, going 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 it is a 'Read-only health check across the wiki' and enumerates the specific findings it returns (orphans, brokenLinks, etc.), distinguishing it from sibling tools like notes.move or wiki.indexRebuild by suggesting pairing.
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 advises periodic use and pairing with fix tools, providing clear context. It mentions vault selection logic but does not explicitly state when not to use this tool or list alternatives.
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 key behavioral traits: missing columns are created automatically, and the return format is a mutation envelope. Annotations (readOnlyHint=false, destructiveHint=false) are consistent with mutation. No contradictions, but could mention failure scenarios.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear front-loaded summary and detailed explanations per op followed by examples. It is slightly lengthy but every section earns its place; examples enhance clarity.
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 tool's complexity (multiple ops, conditional parameters), the description is comprehensive, covering all operations, parameter requirements, and return format. It lacks error handling details but is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no properties, so the description carries full burden. It clearly defines parameters (op, filePath, columnName, etc.) and explains which are required for each operation, adding essential meaning beyond the empty 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 explicitly states the tool adds, moves, or toggles a card on a Kanban board. It clearly distinguishes from sibling tools like kanban.parse and kanban.stats by focusing on mutation operations.
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 detailed guidance on when to use each op (add, move, toggle) and explains required fields per op. It also clarifies the scope (session-active vault vs explicit vaultPath). However, it does not explicitly state when NOT to use this tool or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint), description discloses that output shape varies by 'part', explains the vault selection fallback, and details the three retrieval modes, adding significant 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with front-loaded purpose and clear explanation, but contains some redundancy (e.g., 'Read-only' repeated) and could be slightly more concise.
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 tool's complexity and the existence of an output schema, the description adequately covers retrieval variants and vault interaction, though it does not detail edge cases like missing vault or invalid indices.
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?
Description mentions parameters like 'part', 'slideId', 'index', and 'vaultPath', but the input schema is empty, creating a contradiction. This misalignment reduces clarity and may lead the agent to attempt invalid invocations.
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?
Description clearly states it reads a Marp presentation deck, specifies the 'part' field for selecting what to return, and distinguishes from sibling tool 'marp.update', which is used for mutation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly marks the tool as read-only, instructs to use 'marp.update' for mutations, and explains vault context resolution, providing clear guidance on when and how to use.
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?
While no annotations are provided, the description discloses important behavioral traits such as idempotency (only trivial, every call appends), auto-initialization, and vault selection logic. It could be more explicit about error handling or side effects, but overall it is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately long but well-structured with a clear purpose, usage guidelines, and two practical examples. Each part serves a purpose, though it could be slightly more concise without losing value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 parameters, no annotations), the description covers purpose, usage context, behavioral traits, and includes examples. The existence of an output schema also lessens the need to describe return values. It is complete for an agent to decide when and how to use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% description coverage, so the schema itself documents each parameter well. The description adds examples and context (e.g., op enum values, format of title, refs list) but does not provide significantly new meaning beyond what the schema already offers.
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 ('append one typed entry to wiki/log.md'), specifies the canonical format, and distinguishes the tool from siblings by noting that 'ingest' and 'merge' log themselves, so this tool is for other wiki-meaningful actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use (when no other wiki.* tool logs the action) and when not to use (ingest and merge handle their own logging). It also mentions that the tool auto-runs wiki.init if needed, providing clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond annotations: it notes idempotency, destructiveness, language guard, and vault override. No contradiction with annotations (destructiveHint=true, idempotentHint=true).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with examples, front-loaded with the main action. Every sentence adds value, though slightly long; still justified by complexity.
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 output schema exists, the description sufficiently explains behavior and constraints. It covers key scenarios and error conditions (language mismatch). Could mention return value briefly, but not necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (83%), and the description adds meaning for 'source' (without fences), 'language' guard, and precedence of blockId over index. vaultPath description missing in schema, but description covers it.
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 it replaces a fenced block's body source-preservingly, with specific verbs like 'Replace' and 'Locate'. It distinguishes from sibling tools like blocks.list and blocks.read by focusing on updating.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases and examples, but does not explicitly state when not to use this tool or directly compare to alternatives. However, the examples and context imply appropriate usage.
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?
Describes failure condition, overwrite behavior, and vault operation. Annotations provide no safety hints, so description carries burden. Could add details on permissions or side effects, but it's adequate.
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?
Four sentences, each adding essential information: core action, overwrite, file description, next steps, vault context. No redundancy, front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all relevant aspects: creation, overwrite, format, sibling tool, vault selection. Has output schema so return values are handled elsewhere. Complete for its complexity.
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?
Adds context for vaultPath beyond schema, and reinforces filePath and overwrite semantics. Schema coverage is 67%, so description compensates well. However, path format is not fully 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?
Clearly states it creates a new empty .canvas file at a given path. Distinguishes from sibling canvas.edit by mentioning it is for adding nodes/edges after creation. Also explains the file format.
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?
Explicitly describes overwrite behavior and suggests using canvas.edit for adding content. Mentions vault selection context. However, it does not explicitly state when not to use this tool (e.g., for editing an existing canvas).
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 indicate destructiveHint=true. The description adds that the effect depends on the command, urging verification. It also reveals the plugin dependency and the vault.select limitation, providing additional behavioral context beyond 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 extremely concise, with only three sentences covering all key points without redundancy. It front-loads the main action and adds necessary caveats efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 does not need to explain return values. It covers the purpose, parameters (via schema), destructive nature, plugin requirement, and a nuance about vault.select. This is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains that args is an optional map and that most commands take no arguments, adding meaning beyond the schema's generic description. Schema coverage is 100%, so the description supplements it well.
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 identifies the verb 'Execute' and the resource 'Obsidian command', and specifies that the commandId is the internal id from commands.list. This distinguishes it from the sibling commands.list tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit context: requires the Local REST API plugin, is destructive, and advises to verify the command id. It also clarifies that vault.select does not affect this tool. While it could explicitly state when not to use it, the guidance is sufficient.
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 indicate idempotentHint=true and destructiveHint=false. The description adds behavioral details such as idempotency convergence, operation modes (add/remove), and syntax options, enhancing transparency beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullet points and code examples, making it easy to follow. While comprehensive, it is slightly lengthy; each sentence adds value, but could be trimmed slightly without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema is present (not shown), the description does not need to explain return values. It covers operation, parameter details, idempotency, vault selection, and examples, making it fully complete for a write tool with good annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero properties, yet the description fully compensates by detailing all parameters (op, key, value, syntaxType, insertAt, lineNumber, scope, filePath, vaultPath) with examples and semantics. This provides complete parameter understanding despite the empty 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 'Insert or remove a Dataview field in a single note,' specifying the action (insert/remove) and resource (Dataview field in a note). It distinguishes itself from sibling tools like dataview.fields.read or dataview.query by focusing on writing operations.
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 for usage, including the vault selection mechanism and idempotency. However, it does not explicitly state when to use this tool versus alternatives (e.g., when to choose add vs remove), nor does it mention exclusion criteria, but the context is sufficient for typical use.
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 confirm read-only and idempotent. Description adds context: returns source file, line number, link text, unresolved target. Mentions pairing with notes.move, which implies it is safe and non-destructive.
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?
Two sentences, front-loaded with main purpose, includes a practical usage tip. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists and annotations cover safety, the description provides sufficient context: purpose, scope, return fields, and a relevant sibling tool for fixing. Complete for a read-only diagnostic tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 2 parameters with 50% description coverage (directory described, vaultPath not). Description adds meaning: directory is optional scope, vaultPath overrides session vault. This compensates for the schema 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 it finds broken links (links whose target does not resolve to an existing note), scoped to a directory or whole vault. It is distinct from sibling tools like links.outgoing or links.orphaned.
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?
It specifies when to use (finding broken links) and suggests pairing with notes.move for fixing. It explains vaultPath behavior. However, it does not explicitly contrast with other link tools.
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 indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds context about operating on the session-active vault unless an explicit vaultPath is provided, and mentions the not_found error condition. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise paragraphs with no redundant sentences. The core purpose is front-loaded, and every sentence adds value without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 and the moderate complexity of the tool, the description covers all necessary aspects: inputs, behavior, error handling, and vault context. It is complete without needing to explain return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%. The description adds meaning by explaining the default value for include, the purpose of each option, and the vaultPath override behavior, going beyond the schema's basic 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 states 'Read a note and return any combination of its body, parsed frontmatter metadata, and lightweight statistics.' This provides a specific verb and resource, clearly distinguishing it from sibling tools like notes.list or notes.search.
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 advises when to use specific include options, e.g., 'Ask for ['stats'] alone when you only need word/character/heading/link/task counts and want to skip loading the full body.' It also mentions the not_found error for missing paths, though it does not explicitly contrast with alternatives like dataview queries.
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 and idempotentHint. The description adds 'zero side effects' and details the return values, providing behavioral context beyond the annotations. No contradictions.
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?
Two short sentences: the first describes return content, the second states purpose and safety. No wasted words; perfectly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no input parameters and the existence of an output schema, the description fully covers what the tool does and when to use it. No gaps remain.
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?
No parameters are present, so the description does not need to explain them. The baseline is 4 for zero parameters, and the description adds no redundant information.
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 returns the running kObsidian server's package name, semver version, host runtime, and runtime version. It uniquely identifies this as a version/health-check tool, distinguishing it from sibling tools which are focused on content operations.
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?
Explicitly states to use as a health-check or to confirm which server build a client is talking to. It also notes read-only and zero side effects, guiding appropriate usage. Lacks explicit when-not alternatives, but its simplicity makes that unnecessary.
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?
Description adds behavioral context beyond annotations: date stamping, failure condition for non-task lines, vault path precedence. Annotations are minimal (no readOnly/destructive hints), so description carries the burden well. No contradictions.
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?
Two concise paragraphs. First sentence states core action. Subsequent sentences add essential detail (date stamping, error condition, vault context) without fluff. Well front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all necessary aspects: action, parameters, failure mode, vault context, and guidance to sibling tool. Output schema exists, so return values need not be described. Complete for a toggle operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 75% coverage (vaultPath missing description). Description adds meaning: explains doneDate defaults to today, lineNumber is 1-based, vaultPath overrides session vault. Adds value beyond schema specifications.
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?
Description clearly states the action ('Flip a task line between `[ ]` and `[x]` in place'), identifies the resource (task line via sourceFile and lineNumber), and distinguishes from sibling tools like tasks.create and tasks.search. It also explains the date stamping behavior for marking tasks done.
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?
Explicitly advises to use tasks.search to find the correct sourceFile/lineNumber pair. Mentions vault path handling (session-active vs explicit). Could be more explicit about when not to use, but the tool's purpose is distinct and condition (fails if not a checkbox) provides implicit 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 provide readOnlyHint, idempotentHint, and destructiveHint. The description adds significant context beyond these: it specifies that the tool operates on the session-active vault unless a vaultPath is given, and that it only returns .md files. This enriches the agent's understanding of the tool's behavior. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus a short paragraph on vaultPath. It is front-loaded with the core purpose and immediately connects to the sibling tool. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 optional parameters, no required ones) and the presence of an output schema, the description covers all essential aspects: what the tool does, when to use it, what files it lists, where it looks, and how vault selection works. No gaps remain for the agent's decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50% (only templateFolder has a description). The description compensates by explaining both parameters: templateFolder defaults to the vault's configured Templates folder, and vaultPath overrides the active vault. This adds meaning beyond the schema's minimal metadata.
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'), resource ('markdown templates'), and scope ('in the vault's templates folder' or custom folder via templateFolder). It also explicitly mentions that it is read-only and only returns .md files, and distinguishes itself from the sibling tool templates.use by indicating this is a discovery step before using that tool.
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 directly tells when to use the tool: 'Use this to discover what templates are available before calling templates.use.' It also explains the vaultPath override behavior. However, it does not explicitly state when not to use it or mention alternative discovery methods, though the context is clear.
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?
No annotations are provided, so the description must fully disclose behavior. It explains that cross-references are not applied here, returns proposedEdits array, and that the agent should apply those via notes.* tools. It also explains vault selection logic. Minor gap: no error handling or conflict resolution details, but overall transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and includes two concrete examples. It is slightly verbose but each sentence adds value. The examples are well-placed and clear. Could be tightened, but not excessively.
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 tool's complexity (15 parameters, cross-references, proposedEdits workflow), the description covers the key behavioral aspects: file creation, log append, proposedEdits usage, vault selection. It also explains what sibling tools handle different use cases. Missing details about error handling or edge cases, but sufficient for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, so the schema already documents parameters. The description adds value by clarifying that sourcePath and content are mutually exclusive, and explaining that relatedConcepts and relatedEntities produce createStub proposed edits. The slug override is also explained. This exceeds the baseline of 3.
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 ingests a source into the wiki by writing a markdown file, appending to a log, and returning proposedEdits. It distinguishes from siblings like wiki.summaryMerge and wiki.query with explicit alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool vs alternatives: 'Use wiki.summaryMerge instead when you want to file a follow-up section into an EXISTING concept/entity page; use wiki.query to look something up without writing.' Also provides clear constraints like providing either sourcePath or content, never both.
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 provide read-only and idempotent hints. Description adds value by explaining checkValidity behavior (valid flag) and vault context (session-active vault, vaultPath override). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is relatively concise with two sentences, but includes necessary details. Could be slightly tighter but effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all essential aspects: link extraction, validity checking, vault context, and alternative tool. Output schema handles return format, so no need for return description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is low (33%), but description compensates by elaborating on checkValidity (adds valid flag) and explaining path is a note path and vaultPath overrides. Adds meaning beyond 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?
Clearly states it extracts outgoing links from a note, specifying wiki-style and markdown-style formats. Differentiates from sibling tool 'links.backlinks' for inbound references.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool vs alternative: 'For inbound references, use links.backlinks.' Also explains vault context and vaultPath override.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotentHint=true, and the description explicitly confirms idempotence. It also details the behavior of strategy (merge vs replace), which goes beyond annotations. No contradictions detected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: purpose, parameter explanation, vault context, behavioral notes, and examples. It is front-loaded and informative. Slightly lengthy but every sentence adds value. Could be slightly more concise without losing clarity.
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 presence of an output schema, the description need not detail return values. It covers purpose, parameters, behavior, and usage context. The examples are helpful. However, it could briefly mention that the tool returns the updated note or frontmatter to round out completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema: it explains the interaction between set/unset, clarifies the required condition (at least one), and details the merge vs replace strategies. The examples demonstrate usage, compensating for the 60% 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 'Set or unset fields in a note's YAML frontmatter' with a specific verb and resource. It distinguishes this tool from siblings like notes.edit by focusing on frontmatter manipulation. The examples further reinforce the purpose.
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 guidance: at least one of set/unset is required, strategy options are explained, and vault selection context is given. However, it does not explicitly contrast with sibling tools like notes.edit or mention when to prefer this over editing the full note. Still, the guidance is sufficient for correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial context beyond annotations: idempotence, automatic stripping of leading '#', scope limited to frontmatter, return object structure, and vault fallback behavior. Annotations indicate idempotentHint=true, and description aligns with no contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections, examples, and front-loaded purpose. It is slightly lengthy due to detailed op explanations and examples, but this is justified given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all essential aspects: mutation behavior, four operations, idempotence, vault selection, return value, and constraints (max 50 tags). An output schema exists, so return values need no further explanation. Complete for agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the schema: for 'op' it explains each enum value, for 'tags' it mentions stripping '#', for 'vaultPath' it explains fallback. Schema coverage is high (75%), so baseline is 3, but extra detail earns a 4.
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 it mutates a note's frontmatter tags list, defines four specific operations (add, remove, replace, merge), and distinguishes from sibling read-only tag tools (tags.list, tags.search, tags.analyze).
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 explains when to use the tool (to modify frontmatter tags) and its scope (only frontmatter, not inline tags). It mentions idempotence and vault selection, but does not explicitly state when not to use it or provide direct alternatives, though no other tag mutation sibling exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states 'Read-only', which aligns with the readOnlyHint annotation. It adds important behavioral context: the obsidianLiveInstance note clarifies that workspace.* and commands.* tools target a different vault. This goes beyond what annotations provide and fully discloses behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single long sentence with dense information. It is concise and front-loaded, but could be slightly more readable by splitting into two sentences. Still, every part adds value with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters), rich annotations (readOnlyHint, idempotentHint), and the presence of an output schema, the description covers everything needed: purpose, output fields, edge cases (no vault configured), and cross-tool behavior (obsidianLiveInstance). It is fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description cannot add parameter-level information. Per guidelines, 0 params baseline is 4. The description does not need to elaborate on 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 that the tool returns the current vault and the precedence chain explaining why it was picked. It specifies possible values for `reason` (session-selected, env-default, none) and mentions the obsidianLiveInstance note. This is a specific verb+resource that distinguishes from siblings like vault.list or vault.select.
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 implicitly guides when to use: before calling filesystem tools to know which vault they target, and to explain the vault selection to the user. It notes that if reason is 'none', tools will fail until a vault is set. However, it lacks explicit when-not or alternative tool recommendations, which would elevate it to 5.
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 indicate readOnlyHint=false and openWorldHint=true. The description adds behavioral details: 'No-op when the stack is empty', 'Requires the Local REST API plugin', and 'Not affected by vault.select'. This provides context beyond annotations, though it could mention error behavior if plugin 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?
Three sentences, each adding essential information. First sentence states purpose, second explains parameters and no-op behavior, third clarifies external dependencies and routing. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple navigation tool with one parameter, the description covers purpose, behavior, plugin requirement, and relationship to other tools. It has an output schema (not shown), so return values are documented elsewhere. Complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has one parameter with enum and description. The description adds explicit examples: 'direction:'back' = back one step; direction:'forward' = forward one step', which clarifies the effect of each enum value beyond the schema's 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 'Navigate the Obsidian back/forward file history, like the arrow buttons in the top-left.' This is a specific verb and resource, and it distinguishes from sibling tools like workspace.openFile or vault.select by mentioning it is not affected by vault.select.
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 explains when to use the tool (to go back/forward in history), provides example parameter values, and mentions prerequisites (Local REST API plugin). However, it does not explicitly list alternatives or when not to use it, but given the unique functionality among siblings, this is sufficient.
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 read-only, non-destructive, idempotent, and closed-world properties. The description adds context about operating on session-active vault unless vaultPath overrides, which is valuable beyond 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?
Two clear, compact paragraphs with front-loaded purpose. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return values need not be detailed. Description covers vault path override, alternative tool, and data types (nodes, edges). Complete for a parse tool with good annotations and schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema describes filePath (vault-relative path to .canvas file) but vaultPath lacks schema description. The description explains vaultPath overrides active vault, adding meaning beyond schema. With 50% schema coverage, description compensates well.
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 it parses an Obsidian canvas file and returns full structure with nodes and edges. It distinguishes from sibling tool canvas.connections by specifying scope (complete graph vs neighbors).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use (need complete graph) and when not (need neighbors of a specific node), naming the alternative canvas.connections. Also explains vault selection behavior.
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 read-only, non-destructive, idempotent. Description adds that it's read-only and explains context snippet behavior (contextLength). Consistent and complementary.
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?
Three concise sentences, front-loaded with core purpose, no redundancy or filler. Efficiently conveys key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists and annotations cover safety, description adequately covers vault behavior, link types, and context snippets. No missing critical information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 3 of 4 parameters (75%). Description adds meaning by explaining that `vaultPath` overrides session vault and that `contextLength` controls snippet size. Provides value 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?
Description explicitly states finding notes linking TO a target note (inbound references), mentions both wiki and markdown link styles, and differentiates from sibling tool `links.outgoing`.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly explains when to use (inbound references), what the `includeContext` option does, and explicitly names the alternative `links.outgoing` for outbound links. Also notes vault scoping and vaultPath override.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by detailing the return structure (reachable notes and paths) and the effect of the depth parameter on result size. It also clarifies vault selection behavior. No contradiction with annotations (readOnlyHint, idempotentHint).
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 concise, using two well-structured paragraphs. It front-loads the core purpose, then provides usage warnings and vault context. Every sentence contributes meaning without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description appropriately covers the tool's purpose, return structure, parameter effects, and operational context. No gaps remain for a read-only graph traversal tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds context for noteName ('basename match is fine') and vaultPath (overrides session vault). The depth parameter guidance echoes the schema but is reinforced. With schema coverage at 67%, the description compensates by synthesizing key information and explaining the vaultPath argument's 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 clearly states the tool's purpose: 'Explore the graph neighbourhood around a seed note — direct and multi-hop connections' and specifies the return value (reachable notes and paths). This distinguishes it from sibling tools like backlinks or broken links, which focus on specific link types rather than graph traversal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Higher depth values blow up result size quickly; keep it ≤3 unless you know the graph is sparse.' It also explains vault targeting behavior (session-active vault vs. explicit vaultPath). It does not explicitly state when not to use it, but the context makes it clear.
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 (readOnlyHint, destructiveHint, idempotentHint) already convey safety. The description adds: read-only, sorting behavior, default minOutlinks, and result fields (path, title, outbound, inbound). No contradictions.
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?
Two well-structured sentences pack purpose, usage guidance, parameter details, and vault context without redundancy. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given moderate complexity, description covers purpose, parameters, vault selection, output shape, and distinguishes from siblings. Annotations and output schema exist, so no gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers minOutlinks with description and constraints. The description adds default value (10) and clarifies vaultPath overrides active vault, compensating for its missing 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 the tool returns notes with at least a specified number of outgoing links, sorted descending, and labels them as connective tissue/MOCs. It distinguishes from siblings by naming links.health and links.graph with their different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool (finding navigational anchors for links.connections) and when to use alternatives (links.health for overall score, links.graph for raw edges). Also explains vault selection and vaultPath override.
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, destructiveHint, idempotentHint. Description adds valuable context about operating on session-active vault vs. explicit vaultPath, which is beyond what annotations provide.
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?
Three succinct sentences front-loaded with purpose. No wasted words; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with output schema, description covers purpose, usage, and parameter behavior adequately.
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?
Input schema has 0% coverage for vaultPath, but description explains that vaultPath overrides the session vault. This adds necessary semantic meaning for correct 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?
Description explicitly states the tool returns notes with zero incoming and zero outgoing links, using specific verb+resource+scope. It distinguishes from siblings like links.hubs and links.broken.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage context: 'Useful for cleanup passes' and suggests pairing with sibling tools in a weekly routine. Also clarifies vault selection behavior with vaultPath.
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, destructiveHint=false, idempotentHint=true. Description adds context about vault selection and contextLength default, but no contradictions.
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?
Three concise sentences front-load purpose, then filters, then alternatives. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present, description covers query syntax, contextLength default, vault selection, and tool limitations – complete for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67% (vaultPath lacks description). Description compensates by explaining `query` supports prefix filters (`tag:foo`, `path:Journal/`) and `contextLength` default 80. VaultPath behavior 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 explicitly states 'Full-text search across every note in the vault.' It distinguishes from siblings like `tags.search` (tag-specific) and `notes.list` (listing).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit alternatives: 'For pure tag or date filtering, `tags.search` and `notes.list` are faster.' Also explains vault selection behavior.
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?
No annotations provided, so the description carries the full burden. It states side effects like bumping 'updated:' frontmatter, adding citation to sources list, and creating pages with canonical frontmatter. However, it does not clarify behavior when a heading already exists or if duplicate citation handling occurs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear first paragraph, usage guidelines, and examples. It is front-loaded but slightly lengthy; could be tightened without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (11 parameters, 2 required) and the presence of an output schema, the description covers creation, merging, citation, frontmatter updates, and vault selection completely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the 100% schema coverage. It explains default heading behavior, citation mechanics, entityKind requirement, and provides examples that illustrate parameter usage effectively.
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 adds a cited section to existing concept/entity pages or creates the page if missing. It also distinguishes from sibling 'wiki.ingest' by specifying when to use each.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use this tool (filing follow-up on known page) and when to use 'wiki.ingest' instead (new source). It also notes that 'entityKind' is required when creating a new entity page, and explains vault behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses UI-only nature (does not modify file contents), no-op condition, return format with mode, and error on plugin unreachable. Adds context beyond annotations: 'Not affected by vault.select'. No contradiction with 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?
Description is concise: a few sentences with purpose, behavior, usage guideline, and example. No redundant information. Front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, presence of output schema, and annotations, the description covers all necessary aspects: purpose, behavior, return value, error condition, and usage scenario. No missing elements.
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?
No parameters in schema (0 params, 100% coverage). Description explicitly says 'Takes no arguments' and provides example. Baseline 4 is appropriate as the description adds clarity but doesn't need to explain params.
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?
Description clearly states the verb 'Flip', the resource 'active file in Obsidian', and the specific modes 'edit (source) mode and preview (reading) mode'. It distinguishes from siblings like workspace.openFile and notes.edit by focusing on mode toggling only.
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?
Provides a specific use case: 'when an agent has finished a multi-step edit and wants the user to see the rendered result'. Also notes it's a no-op when no file is active. Does not explicitly mention alternatives, but the simple toggle nature and sibling list show no similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes behavior in detail: for notes, collision handling (error/replace/skip); for folders, idempotent creation with automatic intermediate directories. Notes returning mutation envelope. No contradictions with 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?
Well-structured with a clear opening, followed by detailed explanations for each kind, vault selection note, and concrete examples. Efficient use of sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all relevant aspects: creation behavior, collision handling, idempotency, vault selection. Has output schema for return values, so no need to describe those. Complete for the tool's intended use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite an empty input schema, the description fully documents all parameters (kind, path, content, ifExists, vaultPath) and their semantics, providing necessary meaning 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 the tool creates a note or folder in the vault, with specific behavior for each kind. It distinguishes from siblings like notes.delete, notes.edit, notes.move, etc.
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?
Provides explicit guidance on when to use each kind (note vs folder) and collision handling options. Mentions vault selection context but does not explicitly state when to use alternatives like notes.edit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds critical behavioral context: filesystem is pure text substitution, Templater requires API keys; actions have distinct effects. Does not contradict 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?
Well-structured with bullet points and three JSON examples. Every sentence adds value, no redundancy. Front-loaded with purpose and engine overview.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete coverage of two engines, multiple actions, parameters, and prerequisites (e.g., Templater API requirements). Examples cover major use cases. Output schema present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite an empty input schema, the description fully documents all parameters (engine, action, templatePath, etc.) with examples, providing far more meaning than the schema alone.
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 it renders/applies templates with two engines, distinguishing from siblings like templates.list. It specifies verbs ('Render', 'apply') and resources ('template').
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?
Explicitly explains when to use each engine (e.g., Templater for dynamic evaluation) and mentions vault context. Lacks a direct 'when not to use' statement but sufficiently guides selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint), the description adds constraints like vault-wide scanning limited to Mermaid, and passes vault context via vaultPath, enhancing 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?
Three concise sentences, front-loaded with purpose, then usage and behavior—no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all necessary context: return format ({total, items}), vault behavior, language constraints, and no required parameters—complete given existing output schema.
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?
While schema covers 100% of parameters, the description adds valuable usage guidance (e.g., omitting language lists all types, filePath required for Dataview), surpassing baseline.
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 it lists fenced code blocks of three specific languages in a note or vault-wide, which distinguishes it from sibling tools like blocks.read and blocks.update.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly advises using this tool before reading or updating blocks, and clarifies when to omit language or when filePath is required, guiding appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description states 'Read-only' aligning with annotations. Adds critical context about operating on the session-active vault unless vaultPath is provided, which annotations do not cover. No contradictions.
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?
Three concise sentences with no fluff. First sentence states core purpose, second gives usage guidance, third explains vault behavior. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists (so return format is documented elsewhere), the description fully covers purpose, usage, alternative, and behavioral nuance (vault handling). No gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67% with descriptions for filePath and nodeId. Description adds behavior of vaultPath ('always wins') but does not provide format or constraints for it, leaving some ambiguity.
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 it returns incoming and outgoing edges of a single canvas node, with a specific verb ('Return') and resource ('edges of a single canvas node'). It differentiates from sibling tool 'canvas.parse' by contrasting one-at-a-time vs full-graph.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this to walk the canvas graph one node at a time without loading the full document' and 'For full-graph parsing, use `canvas.parse`.' Also explains vault behavior with references to vault.current and vault.select.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Declares destructive nature ('file is removed from disk'), error condition (`not_found`), irreversibility ('no undo'), and vault path precedence. Adds significant context beyond annotations, which only mark destructiveHint=true.
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?
Two tight paragraphs: first covers purpose and key behaviors, second explains vault context. Every sentence adds value, no redundancy, front-loaded with most critical info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive for a delete tool with output schema and annotations. Covers error handling, irreversibility, alternative for folders, vault behavior, and references to related tools. All necessary context is present.
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?
Adds meaning beyond schema by explaining that `vaultPath` overrides the session vault and that `path` must exist (fails with `not_found`). Could be more explicit about path format, but provides useful context for both parameters given zero schema description 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?
Explicitly states 'Delete a note from the vault', clearly identifying the verb and resource. Distinguishes from siblings by noting that folder deletion is not possible and directing users to `notes.move` for folders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: when to use (for notes), when not to use (for folders), and alternative tool (`notes.move`). Also advises caution due to irreversibility and explains vault selection behavior via `vaultPath`.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that it scans every .md file (potential performance implication) and confirms read-only nature. Annotations already indicate readOnlyHint and idempotentHint, and the description adds context about vault selection and file scanning behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise paragraphs with no fluff. First paragraph states purpose and lists output items; second paragraph clarifies vault selection. Information is front-loaded and well organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, return values need not be described. The description covers what the tool does, how to use it, and relevant context (vault selection, scanning behavior). References sibling tools for related functionality.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage for the single optional parameter vaultPath. The description explains its role: override the session-active vault. This adds essential meaning beyond schema, though could specify acceptable path format.
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 it returns aggregate statistics for the whole vault, listing specific metrics (note count, word count, etc.). It distinguishes from sibling tools like notes.read for per-note stats and vault.current for vault selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use this tool for whole vault stats and provides an alternative for per-note stats using notes.read with include:['stats']. Also explains vault selection logic (session-active unless vaultPath provided), guiding when to pass the optional parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, etc.), the description adds key behaviors: leading `#` is stripped, result structure with tagLocations distinguishing frontmatter/inline, and vault selection precedence.
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?
Four sentences, each serving a purpose: purpose, behavior, result, context. No fluff, front-loaded with main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given annotations, schema, and output schema, the description is complete: explains search scope, tag syntax, result details, and vault context. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers `tag` description 50% (missing `vaultPath` desc). The description adds value by confirming `#` stripping and explaining `vaultPath` override. However, still relies on schema for basic meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: finding notes containing a given tag (frontmatter or inline). It distinguishes from the sibling `tags.analyze` by specifying vault-wide vs. per-note scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool (vault-wide tag search) and when not (use `tags.analyze` for a single note). Also explains the vault context and `vaultPath` override.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds details beyond annotations: idempotent by default, force re-seeds specific files, folders never deleted, return format. Consistent with idempotentHint=true.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with bullet points and examples. Some slight redundancy (e.g., repeated mention of force behavior in description and parameter). Still clear and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all aspects: purpose, usage, behavior, parameters, examples, output format. No gaps given the tool's complexity and presence of output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds meaning beyond schema: explains default values, resolution order for wikiRoot, that force re-seeds index.md/log.md/wiki-schema.md, and vaultPath override. Schema coverage is 100% but description enriches understanding.
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?
Clearly states the tool scaffolds the LLM-Wiki layout under the vault by creating specific folders and seed files. Distinguishes from other wiki.* tools by focusing on initialization.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this once per vault before calling any other wiki.* tool.' Also explains idempotency, force behavior, and wiki root resolution order.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false (correct, as UI opening doesn't read content), destructiveHint=false, idempotentHint=false, and openWorldHint=true. The description adds detailed behavioral context: returns { ok: true } on success, errors when file doesn't exist or API is unreachable, targets the live Obsidian vault which may differ from the filesystem vault, and is unaffected by vault.select. No contradiction with 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 well-structured with clear sections, uses bullet points and examples, and every sentence adds value. It is front-loaded with the main purpose and efficiently covers all necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool complexity (UI operation with side effects), schema richness (all parameters described), and presence of output schema, the description is complete. It explains return value, error conditions, interactive behavior, and relationship to other tools like vault.select and notes.read.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing baseline descriptions for both parameters. The description adds further meaning by explaining the effect of newPane (opens in new split vs reusing active pane) and providing examples that illustrate parameter usage. The added context is valuable but not critical given rich 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 verb 'Open' and the resource 'vault-relative note filePath in the live Obsidian UI'. It distinguishes itself from sibling tool 'notes.read' by specifying it does not create, modify, or read content. The examples further clarify the purpose, making it highly 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool (to open a note in the UI) and when not to use it (for content, use notes.read). It also clarifies that it is not affected by vault.select, which distinguishes it from vault-related operations. This provides excellent guidance for selecting the correct tool among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide destructiveHint and idempotentHint. The description adds context: the operation is destructive to hand-edits, idempotent, and operates on session-active vault unless vaultPath is given. No contradictions.
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?
Efficiently structured: core action first, then details, usage guidelines, and examples. Every sentence serves a purpose, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive coverage for a destructive, idempotent tool. Output schema exists, so return value detail is not needed. All necessary behavioral context is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%. The description adds meaning to 'includeCounts' with examples and explains precedence for vaultPath and wikiRoot, providing value 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 it regenerates 'wiki/index.md' from a fresh scan of specific directories, with grouping and sorting characteristics. This distinguishes it from siblings like wiki.ingest or wiki.lint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions when to use (after bulk-creating pages, as cleanup after wiki.lint reports indexMismatch) and when to prefer an alternative (for incremental upkeep, use wiki.ingest's proposedEdits).
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:

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

Score Badge

Copy to your README.md:

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

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/bezata/kObsidian'

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