Headless Obsidian MCP Server gives AI assistants full, structure-aware access to an Obsidian vault for searching, browsing, traversing, querying, auditing, and optionally editing notes—without needing Obsidian running.
Search: search_notes for literal/regex ripgrep searches with scoping, pagination, and context; search_notes_ranked for BM25 relevance-ranked full-text; resolve_note and resolve_daily_note for human-friendly name resolution.
Browse & Read: read_notes, list_notes, list_files, list_folders; get_outline, read_section; get_frontmatter, get_property; list_templates, list_tasks.
Traverse: get_links (outbound wikilinks, unresolved links, backlinks); get_related_notes (ranked by shared tags, links, co-citations).
Query & Filter: query_notes with frontmatter operators (eq, ne, gt, contains, etc.); find_by_tag; list_recent_notes; list_tags, list_properties, list_property_values.
Audit: get_vault_stats (overall health); list_vault_issues (orphans, broken wikilinks, dead anchors, conflicts).
Editing (opt-in): Create, append, prepend, move, delete notes; surgical tag/frontmatter/section edits; bulk edit; folder management. Moving/renaming auto‑updates inbound links; deletions go to .trash; write operations report any broken links they introduce.
Tasks: List checkbox tasks and toggle their state.
Templates: List and apply Obsidian core templates with variable expansion.
Git Sync (opt-in): Auto‑commits after writes; pull/push; non‑destructive merge conflict resolution.
Safety & Config: Read‑only by default; writes are opt‑in and per‑tool group restrictable; get_config always available to report tool policy, git sync status, and template settings.
Provides tools for interacting with an Obsidian vault, enabling full-text search, link graph navigation, tag management, structure-aware editing, and vault hygiene operations.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Headless Obsidian MCP search my vault for meeting notes"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that gives AI assistants full access to an Obsidian vault — search, the link graph, tags, and structure-aware editing — without needing a running copy of Obsidian. Ideal for a headless server running your Hermes or OpenClaw agents.
It reduces token cost and removes the need for your agent to understand Obsidian vault conventions, so your agent can read your vault as a knowledge base rather than a folder of text files: [[wikilinks]] resolve the way Obsidian resolves them, tags unify inline #tags with frontmatter, and edits are surgical (change one section or one tag without rewriting the note).
Read-only by default. Out of the box the server exposes only read tools; writing is opt-in through a single environment variable.
Status: 0.x. The server is tested and in daily use, but the tool surface is still settling — tool names, parameters, and return shapes may change between releases. Following semver's 0.x convention, breaking changes bump the minor version (0.2.0) and fixes bump the patch (0.1.1). Pin a version if you depend on a specific tool contract.
Literal/regex search via ripgrep ( | |
List notes, folders, attachments, tags, and frontmatter properties. Read a note's outline or one section without loading the whole thing. | |
Resolve | |
Filter notes by frontmatter conditions ( | |
Whole-vault stats, then drill into the actual orphaned notes, broken wikilinks, and dead heading anchors. | |
Edit (opt-in) | Create, append, prepend, move, and delete notes. Change a tag, a frontmatter field, or one section without rewriting the note. Bulk-edit many notes in one call. Create, move, and delete folders too. See Enabling writes. |
Moving a note rewrites the wikilinks that point to it; renaming a heading rewrites inbound anchors. Every write reports any broken links it introduced. Deletes go to | |
Sync (opt-in) | If the vault is a git repo, snapshot every write as a commit — optionally pulling and pushing a remote per write or on a background timer. Merge conflicts are resolved non-destructively: your version is always preserved. See Git safety net. |
Templates from Obsidian's core Templates plugin are supported ({{title}}, {{date:FORMAT}}, …); Templater scripting is not.
→ Full tool reference — all 49 tools with parameters and return shapes.
Related MCP server: Obsidian MCP Tool Server
Requires Node.js 20+, ripgrep, and an Obsidian vault.
git clone <this-repo> && cd headless-obsidian-mcp
npm install && npm run build
export OBSIDIAN_VAULT_PATH="/path/to/your/vault"
npm startThen point an MCP client at it. For Claude Desktop (~/.config/claude/claude_desktop_config.json on macOS/Linux, %APPDATA%\Claude\claude_desktop_config.json on Windows):
{
"mcpServers": {
"obsidian": {
"command": "node",
"args": ["/absolute/path/to/headless-obsidian-mcp/dist/index.js"],
"env": {
"OBSIDIAN_VAULT_PATH": "/absolute/path/to/your/vault"
}
}
}
}Restart the client and the server appears as obsidian. To let the agent edit the vault, add "OBSIDIAN_TOOLS": "all" to that env block — see Enabling writes.
Ready-to-copy configs for Claude Desktop, Claude Code, and Docker are in examples/.
Only OBSIDIAN_VAULT_PATH is required. .env.example documents all eight variables the server reads.
Nothing here loads a
.envfile — an MCP server inherits its environment from the client that spawns it. Set variables in your client'senvblock (or pass--env-fileto Docker).
OBSIDIAN_TOOLS selects exactly which tools the server exposes. Unset, it means reads: the 24 write tools are hidden from the tool list, and calling one is rejected.
OBSIDIAN_TOOLS="all" # everything
OBSIDIAN_TOOLS="reads,tasks.write,sections.write" # read all; write only tasks and sections
OBSIDIAN_TOOLS="all,-bulk,-delete_note" # everything except the destructive ones
OBSIDIAN_TOOLS="-templates,-tasks" # reads, minus two groups
OBSIDIAN_TOOLS="search,notes.read" # minimal search-and-read agentSelectors are case-insensitive and applied left to right — a plain token adds, a - prefix subtracts. Valid tokens are the meta-groups all / reads / writes, a domain group, a mode slice like notes.write, or an individual tool name. Evaluation starts from nothing, unless the first token subtracts, in which case it starts from reads — so -templates trims the read surface and can never accidentally expose writes.
The eleven domain groups:
Group | Read | Write |
| search_notes, search_notes_ranked | — |
| read_notes, list_notes, list_recent_notes, resolve_note, resolve_daily_note | write_note, append_note, prepend_note, patch_note, delete_note, move_note |
| get_outline, read_section | add_section, append_to_section, replace_section, rename_section |
| get_links, get_related_notes | — |
| list_tags, find_by_tag | add_tag, remove_tag |
| get_frontmatter, list_properties, list_property_values, query_notes, get_property | set_frontmatter, add_property_values, remove_property_values, rename_property |
| list_tasks | set_task_state |
| list_templates | apply_template, insert_template |
| list_files, list_folders | move_file, create_folder, move_folder, delete_folder |
| get_vault_stats, list_vault_issues | — |
| — | bulk_edit |
get_config sits in no group and is always exposed — its tools section reports the active policy, so an agent can discover why a tool is missing.
Excluding tools also saves tokens: an excluded tool is a schema the client never carries in context.
An unknown selector, or a policy that selects nothing, aborts startup with the valid vocabulary listed. The policy gates the MCP server only; the query CLI is the operator's own tool and ignores it.
OBSIDIAN_GIT_SYNC)If your vault is a git repository, the server can snapshot every write:
Mode | Behavior |
| No git involvement. |
| Commits after every write, with a message naming the tool. No remote. |
| Commits, then pulls and pushes the remote after each write. |
| Commits per write; pulls and pushes on a background interval instead. |
OBSIDIAN_GIT_SYNC_INTERVAL sets the timer cadence in seconds (default 300); OBSIDIAN_GIT_REMOTE names the remote (default origin).
The guard is fail-closed: in any mode but off, a write is refused before touching disk if the vault isn't a usable git repo, and a failed post-write commit throws — a write never lands without its snapshot. The lone exception is the background timer tick, whose failures are recorded in get_config's sync.last_error rather than thrown, since no write is in flight to fail.
Conflicts are never blocking or destructive. On a real merge conflict, per file: if both sides changed the note, your version is preserved as a <note> (conflicted YYYY-MM-DD HHMMSS) copy and the canonical path takes the remote's; if the remote deleted a note you'd modified, the same copy preserves your version; if you deleted a note the remote modified, the remote version is restored. Find unreconciled copies with list_vault_issues kind:"conflicts".
The Dockerfile builds a multi-stage node:20-alpine image with ripgrep and git installed — both are hard runtime dependencies, not conveniences.
docker build -t headless-obsidian-mcp .
docker run -i --rm -v "$HOME/vault:/vault:ro" headless-obsidian-mcp-i is load-bearing: this is a stdio server, and without an open stdin the transport never comes up. The vault mounts at /vault and the container runs as the unprivileged node user. For writes, drop :ro and add --user "$(id -u):$(id -g)" so new files land owned by you. Client config: examples/mcp.docker.json.
There's no docker-compose.yml by design — an MCP stdio server is spawned per client, not supervised as a service.
npm run dev # watch mode via tsx, no build step
npm run build # compile to dist/
npm test # node:test via tsx
npm run query # query CLI — see docs/CLI.mdmise run <task> works for each if you use mise.
The query CLI calls the tools directly and prints raw JSON, which makes it the fastest way to try something without wiring up a client.
Tests build a throwaway fixture vault in a temp directory and cover link resolution, tag aggregation, listing and recency, index cache invalidation, and the security guards (path traversal, symlink escapes, frontmatter hardening). CI runs build and tests on Node 20 and 22 for every PR and push to main, installing real ripgrep and a git identity — the suite drives the actual rg binary and real repositories rather than stubs.
Design rationale, tool-naming taxonomy, and the invariants that keep the tool surface coherent live in CLAUDE.md.
skills/obsidian-vault/SKILL.md is a copyable Agent Skill — drop it in ~/.claude/skills/obsidian-vault/ to give an agent workflow guidance for this server: which tool answers which intent, anti-patterns worth avoiding, and multi-step recipes for fixing broken links, processing the daily note, and restructuring without breaking the graph.
This project began as a Node.js port of notes-mcp by Boaz Yaniv, and has since been substantially extended with knowledge-base, structure-aware editing, and vault-management tools. The original is MIT licensed; that license and copyright are retained in LICENSE.
Thanks also to mcpvault by bitbonsai, whose Obsidian MCP server was a useful reference while shaping this project's tool surface.
Released under the MIT License.
Find notes matching one or more tags, as note headers. High-precision retrieval based on human curation. Narrow further with folder and a frontmatter where filter (all conditions apply); match governs the tag set only.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | Yes | Tags to match (with or without leading #) | |
| limit | No | Maximum number of notes to return (default 100; 0 = unbounded) | |
| match | No | Require "any" (default) or "all" of the tags (governs the tag set only) | |
| where | No | Additional frontmatter conditions (query_notes syntax); all must hold. | |
| folder | No | Restrict to notes under this folder. | |
| offset | No | Rows to skip, for pagination (default 0). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses that retrieval is 'high-precision based on human curation' and clarifies that 'match governs the tag set only', which explains parameter behavior. It does not mention rate limits or authorization, but for a read tool, the description is sufficiently transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose, second adds narrowing options and clarifies match scope. No redundant words; front-loaded with key information. Excellent conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite covering purpose and parameter interactions, the description lacks explanation of the output format ('note headers') and does not discuss pagination or return structure. For a tool with 6 parameters and no output schema, this is a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining that match only applies to tags and how folder/where narrow the search. This contextualizes parameters beyond the schema's descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Find notes matching one or more tags, as note headers', specifying the verb, resource, and key criterion. It adds context about 'high-precision retrieval based on human curation', which helps differentiate from full-text search tools like search_notes. However, it does not fully define what 'note headers' entails compared to full note content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for tag-based retrieval and mentions narrowing with folder and frontmatter filters. However, it lacks explicit direction on when to use this tool versus alternatives (e.g., search_notes, query_notes) and does not provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report the server's own configuration (not vault contents). Returns { template: { folder, date_format, time_format }, daily: { folder, format, template }, writes: { writes_enabled, git_sync }, sync: { mode, interval, remote, last_sync, last_error }, vault: { path }, tools: { policy, exposed, excluded } }. Optional section narrows the result to one unwrapped section. template.folder and daily.folder are null when unconfigured (does not error). writes_enabled means at least one write tool is exposed. sync section reports the active git-sync mode and current state. Read-only; never excluded by OBSIDIAN_TOOLS — this is how you discover the active tool policy.
| Name | Required | Description | Default |
|---|---|---|---|
| section | No | Return just this section, unwrapped. Omit for the whole config object. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses behavior: return structure, null values for unconfigured fields, interpretation of writes_enabled, and the read-only nature. It is comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured, front-loading the main purpose and then detailing the return object. It is dense but each sentence adds value; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description fully specifies the return shape and handles edge cases (null values, interpretation of flags). It 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one enumerated parameter. The description adds that omitting the parameter returns the whole config and that the section is 'unwrapped', adding clarity beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reports the server's own configuration, not vault contents, with a specific verb and resource. It distinguishes from siblings like get_vault_stats and other tools that deal with notes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clarifies that the tool is read-only and never excluded by OBSIDIAN_TOOLS, implying it's always available. It does not explicitly state when not to use it, but the context of discovery for tool policy is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read just a note's parsed frontmatter (YAML metadata), without its body. A cheap way to inspect a note's status, aliases, dates, or custom fields before reading or editing the whole note.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Note path (.md optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it reads only frontmatter (not body) and is cheap, but does not disclose potential issues like missing frontmatter behavior, error handling, auth requirements, or rate limits. More behavioral context would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no waste. First sentence states core functionality, second sentence adds valuable use case context. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description could clarify the return format (e.g., parsed YAML object). However, the tool's narrow scope and clear input minimize ambiguity. The description adequately covers the essential context for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% documentation coverage for the single parameter 'path' ('Note path (.md optional)'). The description does not add additional semantic meaning beyond what the schema already provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it reads parsed frontmatter (YAML metadata) without the body. It specifies the verb 'Read' and resource 'frontmatter', and distinguishes from siblings like 'read_notes' by focusing only on metadata. The use case of inspecting status, aliases, dates, or custom fields is explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use: when you want a cheap inspection of metadata before reading or editing the whole note. It does not explicitly exclude alternatives or provide when-not-to-use scenarios, but the use case is clearly stated and aids agent decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve the Obsidian link graph for a note: outbound [[wikilinks]] resolved to real notes, links that resolve to nothing, and backlinks (other notes that link to this one). Use it to traverse related knowledge. With include_context: true, every row gains the linking line(s) — 'who references this note, and why' in one call (see the link-context convention).
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Note path (.md optional) | |
| include_context | No | Decorate every link row with the source line(s) containing it, as { line, text }. Call-time file reads — leave off (default) when only the paths are needed. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the output components (outbound resolved, broken, backlinks) and explains the include_context parameter behavior (adds linking lines, call-time file reads). It does not mention side effects or permissions, but for a read-only operation this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the core purpose, and no superfluous words. Every sentence adds value: action, use case, and optional parameter explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the output categories (outbound, broken, backlinks) and the effect of include_context. It references a 'link-context convention' without elaboration, which is a minor gap, but overall it provides enough context for the agent to understand what the tool returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters well. The description adds only a brief rephrasing for include_context ('who references this note, and why'), which provides some added context but not substantial new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool resolves the Obsidian link graph for a note, including outbound wikilinks, broken links, and backlinks. This is a specific verb+resource that distinguishes it from sibling tools like search_notes or get_related_notes, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use it to traverse related knowledge,' providing a clear context for when to use the tool. However, it does not offer alternatives or when-not conditions, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a note's heading structure (outline) without reading its body: each heading with its level, 1-based line number, full " > "-joined heading-path, and an ambiguity flag. Use it to see what sections exist before reading or editing one.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Note path (.md optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the read-only behavior and the specific data returned (headings with level, line number, path, ambiguity flag). It does not mention error handling, but the behavior is well-described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff: the first details what is returned, the second gives usage context. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description provides sufficient behavioral context and usage guidance. It covers the key aspects needed for an agent to decide and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage with a single parameter 'path' described as 'Note path (.md optional)'. The description does not add additional meaning beyond that, so baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a note's heading structure (outline) without reading its body, listing specific return fields (level, line number, heading-path, ambiguity flag). It distinguishes from siblings that read the body or sections.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use it to see what sections exist before reading or editing one', providing clear when-to-use guidance. It implies alternatives (read_notes, read_section) but does not explicitly state exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a single frontmatter property value from one note. Returns { path, key, value, present }; present distinguishes an absent key from a key explicitly set to null.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | The frontmatter property key to read | |
| path | Yes | Note path (.md optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden and discloses important behavioral traits: it returns a specific tuple ({path, key, value, present}) and explains that 'present' distinguishes between an absent key and a key set to null. This adds value beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the action and purpose. Every sentence adds value, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with a well-defined output shape (explicitly documented), the description is mostly complete. It omits error handling or non-existence cases, but the core functionality and return value are clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add any additional meaning or details about the parameters beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Read'), a specific resource ('single frontmatter property value'), and clarifies the scope ('from one note'). It also distinguishes from siblings like get_frontmatter (which presumably returns all frontmatter) and read_notes (full note content).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for reading a single property and notes the distinction between absent and null values, but it does not explicitly state when to use this tool versus alternatives like get_frontmatter, or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Summarize the whole vault: note and tag counts, link-graph health (resolved vs unresolved links, orphan notes), total size, and modification-time bounds. Use it to get a quick sense of the vault's scale and health.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral traits. It implies a read-only query but does not explicitly state safety, performance implications, or any potential side effects. This is adequate but leaves some uncertainty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loading the specific outputs and ending with a clear usage context. Every sentence earns its place with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers the main output components (counts, health, size, time bounds). It does not detail exact return format but is complete enough for an agent to understand the tool's purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters (0 params), so the baseline score is 4. The description adds value by explaining what the output contains, which is sufficient for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies exactly what the tool summarizes: note and tag counts, link-graph health, total size, and modification-time bounds. This clearly distinguishes it from sibling tools focused on reading individual notes, searching, or listing specific items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Use it to get a quick sense of the vault's scale and health' provides clear guidance on when to use it. However, it does not explicitly state situations when it should not be used or mention alternatives, which would improve differentiation among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List non-markdown files in the vault (attachments, images, PDFs) as { path, size, modified, extension } rows, e.g. to find a file to move. Never includes notes (use list_notes).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of files to return (default 100; 0 = unbounded) | |
| folder | No | Restrict to files under this folder. | |
| offset | No | Rows to skip, for pagination (default 0). | |
| extension | No | Filter by extension; leading dot optional, case-insensitive (e.g. 'png'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description does not disclose read-only status, authorization needs, or side effects. It adds that the tool never includes notes, which is behavioral context, but more transparency could be added.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. Key information is front-loaded: purpose, output format, and sibling distinction.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description lists output fields, so no output schema is needed. Covers 4 parameters with minimal ambiguity. Could mention recursion behavior (e.g., recursive listing) but overall sufficient for a simple listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good descriptions for all 4 parameters. Description adds no new parameter-level detail beyond the schema, earning baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'List non-markdown files in the vault (attachments, images, PDFs)' and specifies output fields. It explicitly distinguishes from list_notes, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a concrete example use case ('e.g. to find a file to move') and explicitly states when not to use it ('Never includes notes (use list_notes)'). This effectively guides tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enumerate the vault's folders as { path, notes (direct), total_notes (recursive), subfolders } rows sorted by path — the folder-level counterpart to list_notes, for seeing the vault's shape before searching or reading. Notes-only: attachment-only folders do not appear (use list_files), and root-level notes contribute no folder.
| Name | Required | Description | Default |
|---|---|---|---|
| depth | No | Relative depth cap: 1 = immediate children of the scope (or top-level folders when no folder is given) | |
| limit | No | Maximum number of folders to return (default 100; 0 = unbounded) | |
| folder | No | Restrict to folders under this folder. | |
| offset | No | Rows to skip, for pagination (default 0). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses sorting by path, exclusion of attachment-only folders, and that root-level notes contribute no folder. It could mention pagination behavior, but the schema covers limit/offset.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose in first sentence. Second sentence packs exclusions and alternatives but is slightly long. No wasted words, but could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no output schema, and many siblings, description explains return fields, sorting, exclusions, and contrasts with two sibling tools. Missing explicit return structure but fields are listed. Adequate for complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already covers all 4 parameters with descriptions. Description adds minimal context (e.g., depth cap, immediate children), but does not significantly augment schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it enumerates vault's folders with specific fields ({path, notes, total_notes, subfolders}) and contrasts itself with list_notes, making the purpose and resource explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explicitly says it's the 'folder-level counterpart to list_notes, for seeing the vault's shape before searching or reading,' and notes when to use list_files instead for attachment-only folders.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List notes in the vault as lightweight headers (path, title, tags, first heading, size, modified time) without full contents. Use it to discover what exists and orient before searching or reading. Scope with folder/tags/where/match (match governs tags; where conditions all apply).
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Restrict to notes carrying these tags (leading '#' optional). | |
| limit | No | Maximum number of notes to return (default 100; 0 = unbounded) | |
| match | No | Semantics of tags: 'any' (default) or 'all'. | |
| where | No | Restrict to notes whose frontmatter satisfies these conditions (query_notes syntax). | |
| folder | No | Restrict to notes under this folder. | |
| offset | No | Rows to skip, for pagination (default 0). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses return format (lightweight headers) and clarifies scoping behavior (match governs tags, where conditions all apply); no contradictions with missing annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two focused sentences covering purpose and usage scope with no wordiness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 6 parameters, the description sufficiently explains the lightweight header output and scoping options, enabling correct tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds value by explaining interaction between match and where conditions, going beyond schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'List notes in the vault as lightweight headers' with specific output fields, distinguishing from sibling tools like read_notes (full contents) and search_notes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises using it to 'discover what exists and orient before searching or reading', implying when-to-use context; could be improved by naming alternative tools for other scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every frontmatter property key used across the vault with the number of notes using it and the distinct value types observed (string/number/boolean/array/null/date, plus object for nested YAML written by hand on disk — frontmatter writes reject nesting, reads do not), sorted by frequency. The vault's property schema; like list_tags but for arbitrary properties. No limit: the full set is returned (offset still pages; truncated is always false).
| Name | Required | Description | Default |
|---|---|---|---|
| offset | No | Rows to skip, for pagination (default 0). | |
| include_tags | No | Include the tags key (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses behavior such as sorting by frequency, no limit, pagination offset, and important edge cases about nested YAML handling (rejecting writes but allowing reads). It also states 'truncated is always false'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main purpose and key details. Every sentence adds essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 2 params and no output schema, the description fully explains what is returned (keys, counts, types, sorted), the pagination mechanism, and edge cases like nested YAML. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, providing baseline 3. The description adds value by explaining offset behavior ('offset still pages; truncated is always false') and implying the effect of include_tags, which are not in schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all frontmatter property keys with counts and value types, sorted by frequency. It explicitly distinguishes itself from siblings by comparing to list_tags and mentioning arbitrary properties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: 'the vault's property schema' and mentions pagination and no limit. It implicitly differentiates from tools like list_tags and get_property, but lacks an explicit when-to-use vs alternatives statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the distinct values of one frontmatter property as { value, count } rows, most frequent first. Array-valued properties count each element. A faceted index for a single key.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | The frontmatter property key to facet | |
| limit | No | Maximum number of distinct values to return (default 100; 0 = unbounded) | |
| offset | No | Rows to skip, for pagination (default 0). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals key behaviors: array-valued properties count each element, results are ordered by frequency, and pagination via limit/offset. However, it does not mention scope (e.g., vault-wide) or any side effects, though the tool appears read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: three short sentences that front-load the purpose and add essential detail on array handling and ordering. Every sentence serves a purpose with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool with 3 parameters, no output schema, and no annotations, the description reasonably covers purpose, output format, ordering, and counting behavior. It is complete enough for an agent to use correctly, though it could mention what happens if the property does not exist (likely empty list).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing baseline at 3. The description adds value by explaining that 'Array-valued properties count each element' for the 'key' parameter, and implicitly links 'most frequent first' to ordering related to the key. This extra context exceeds the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'distinct values of one frontmatter property' with output format '{value, count} rows, most frequent first'. It also adds 'A faceted index for a single key', distinguishing it from siblings like list_properties and get_property.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (to list distinct values of a property with counts), but does not explicitly mention when not to use it or present alternatives among the sibling tools. The context is sufficient for an agent to decide, but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List notes ordered by recency (newest first), as lightweight headers. Sort by filesystem mtime or a frontmatter date field, with an optional since cutoff. Scope with folder/tags/where/match (match governs tags; where conditions all apply). Use it to find current material.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Restrict to notes carrying these tags (leading '#' optional). | |
| limit | No | Maximum number of notes to return (default 100; 0 = unbounded) | |
| match | No | Semantics of tags: 'any' (default) or 'all'. | |
| since | No | Only include notes on or after this ISO date | |
| where | No | Frontmatter conditions (query_notes syntax), e.g. { "status": "active" } or { "priority": { "gt": 3 } }. | |
| folder | No | Restrict to notes under this folder. | |
| offset | No | Rows to skip, for pagination (default 0). | |
| date_field | No | Frontmatter field to sort by instead of filesystem mtime (e.g. 'updated') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses sorting behavior (by mtime or date field), scoping (folder/tags/where/match), and result type ('lightweight headers'). It does not mention destructive actions (unnecessary for read) but could clarify pagination details. Overall, it sufficiently describes behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the main action. Every sentence adds value: first states what, second details sorting/scoping, third gives use case. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters and no output schema, the description covers the core functionality: ordering, scoping, and use case. 'Lightweight headers' hints at output format. It might need more on pagination or default behavior, but it's sufficient for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds some value by explaining the relationship between 'match' and 'tags' and that 'where' conditions all apply. However, it does not elaborate on 'limit', 'offset', or 'date_field', which are left to the schema. This is adequate but not exceptional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List', resource 'notes', ordering 'by recency', and result format 'lightweight headers'. It differentiates from siblings like 'list_notes' (no recency) and 'search_notes' (full text). The phrase 'find current material' further reinforces the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear use case: 'Use it to find current material.' It implies when to use (recent notes) by specifying recency sorting and optional cutoff. However, it lacks explicit exclusions or alternatives, e.g., when to use 'list_notes' or 'search_notes' instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every tag used across the vault with the number of notes using it, sorted by frequency. Unifies inline #tags and frontmatter tags:. Use it to see the vault's topic index. No limit: the full set is returned (offset still pages; truncated is always false).
| Name | Required | Description | Default |
|---|---|---|---|
| offset | No | Rows to skip, for pagination (default 0). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses pagination behavior ('offset still pages; truncated is always false') and states there is no limit. However, it does not explicitly state that it is a read-only operation or any authorization requirements, though 'list' implies read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences. The first sentence covers the core functionality, and the second adds important behavioral context. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema), the description adequately explains what it does, what it returns (count of notes per tag), and pagination behavior. It feels complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'offset' is fully covered by the schema (100%). The description adds value by clarifying that there is no limit to results and that pagination works with offset, which is not in the schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list), the resource (tags), and additional details (count of notes, sorted by frequency, unification of inline and frontmatter tags). It distinguishes itself from siblings like 'find_by_tag' by focusing on listing all tags rather than searching for a specific one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Use it to see the vault's topic index', providing clear context for when to use the tool. It does not explicitly mention when not to use it or compare with alternatives, but the purpose is sufficiently clear for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List checkbox tasks (- [ ] ...) across the vault as structured rows (path, text, status, raw marker, 1-based line, enclosing heading-path). status is a named state: open|done|in_progress|cancelled|forwarded|other. Index-backed. Scope with folder/tags/where/match and an optional status filter (any of the listed statuses).
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Restrict to notes carrying these tags (leading '#' optional). | |
| limit | No | Maximum number of tasks to return (default 100; 0 = unbounded). | |
| match | No | Semantics of tags: 'any' (default) or 'all'. | |
| where | No | Restrict to notes whose frontmatter satisfies these conditions (query_notes syntax). | |
| folder | No | Restrict to notes under this folder. | |
| offset | No | Rows to skip, for pagination (default 0). | |
| status | No | Restrict to tasks in any of these statuses; omitted = all. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses index-backed for performance, lists return fields, and implies read-only nature. Lacks explicit statement about side effects, but no annotations to contradict. Solid for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently convey purpose, output format, and scoping. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Explains return structure, status values, and scoping well. Could mention pagination parameters (limit, offset) more explicitly, but overall sufficient given complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with adequate descriptions. Description adds slight context (status values listed, scoping phrasing) but does not significantly enhance understanding beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool lists checkbox tasks as structured rows with specific fields (path, text, status, etc.). Distinguishes from siblings by focusing on tasks rather than general notes or files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes scoping options (folder, tags, where, match, status) and implies use for filtered task listing. Does not explicitly say when not to use or compare to siblings like search_notes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enumerate the vault's core Templates-plugin template folder as { path, name, size, modified } headers. Folder resolved from .obsidian/templates.json (or the OBSIDIAN_TEMPLATE_FOLDER override); errors if neither is configured. Read-only. Core Templates only — Templater scripting is not supported.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of templates to return (default 100; 0 = unbounded) | |
| offset | No | Rows to skip, for pagination (default 0). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully covers behavioral traits: it is read-only, resolves the folder from .obsidian/templates.json or an override, errors if not configured, and excludes Templater scripting. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences that front-load the action and output format, with 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, it specifies the output headers. It explains error conditions and plugin limitations. A minor gap: it doesn't explicitly state the return type (array of objects), but this is implied by the listed headers.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both parameters (limit and offset). The description does not add extra meaning beyond the schema, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool enumerates the vault's core Templates-plugin template folder and specifies the output format as { path, name, size, modified } headers. It distinguishes itself from Templater scripting, ensuring no confusion with sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions read-only behavior, that it errors if no template folder is configured, and that it only supports core Templates (not Templater). However, it does not explicitly state when to use this tool over siblings like list_files or when not to use it (e.g., for Templater templates).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the vault-hygiene issues get_vault_stats only counts. kind:'orphans' returns note headers for notes with no inbound or outbound resolved links; kind:'unresolved_links' returns, grouped by source note, the wikilink targets that resolve to nothing (the notes with broken links); kind:'broken_anchors' returns, grouped by source note, the [[note#heading]] anchors that resolve to a note but not to any heading in it; kind:'conflicts' returns the unreconciled conflict copies (notes named "… (conflicted YYYY-MM-DD HHMMSS)") each paired with the original note they diverged from. Index-backed. For the grouped kinds, limit/offset count groups (source notes), not individual targets.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | Which issue list to return. | |
| limit | No | Maximum number of rows/groups to return (default 100; 0 = unbounded). For unresolved_links, this counts groups (source notes), not individual targets. | |
| offset | No | Rows/groups to skip, for pagination (default 0). | |
| include_context | No | For kinds unresolved_links/broken_anchors: decorate each target with the source line(s) containing it, as { line, text } (call-time reads over the returned window only). Errors on kinds orphans and conflicts (neither has links to contextualize). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It does so by noting that the tool is index-backed, describing limit/offset semantics per kind, and specifying that include_context errors on certain kinds. However, it does not explicitly state that the operation is read-only or mention authorization needs, leaving minor gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise yet thorough, with every sentence contributing essential information. It is well-organized: first a general statement, then enumeration of kinds, then pagination details. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description covers what each kind returns and how parameters interact. It addresses all four parameters and their nuances, leaving no obvious gaps for an agent to misinterpret the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds substantial value: it explains each enum value of 'kind' in detail, clarifies that limit/offset count groups for grouped kinds, and details the behavior and error conditions of 'include_context'. This goes well beyond the schema's minimal descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'list' and specifies the resource as 'vault-hygiene issues', clearly distinguishing four kinds. It contrasts with sibling 'get_vault_stats' by stating that the latter only counts, while this tool returns the actual issues. The purpose is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use each kind and how pagination works differently for grouped kinds. It implicitly distinguishes from 'get_vault_stats' but does not explicitly state when not to use this tool or list alternatives beyond that one sibling. The guidance is clear but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find notes whose frontmatter satisfies a set of conditions, as note headers. Each condition is a bare scalar (equality / array-membership) or an operator object { eq, ne, gt, gte, lt, lte, exists, contains }. Comparisons are type-aware (numbers, ISO dates, strings). match: all (default) or any (governs the where conditions only). Narrow further with folder and tags (any of them).
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Additionally restrict to notes carrying these tags (leading '#' optional); any of them. | |
| limit | No | Maximum number of notes to return (default 100; 0 = unbounded) | |
| match | No | Require all (default) or any of the where conditions (governs the where conditions only) | |
| where | Yes | Map of property key to condition (scalar or { eq/ne/gt/gte/lt/lte/exists/contains }) | |
| folder | No | Restrict to notes under this folder. | |
| offset | No | Rows to skip, for pagination (default 0). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It reveals that results are 'note headers' (not full content), comparisons are type-aware, and the 'match' mode only affects 'where' conditions. It does not explicitly state read-only status, but the query nature implies no side effects. Overall, it provides sufficient behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the purpose, and then details the condition format. It is efficient but slightly ambiguous with 'as note headers' – could be clearer about what that means. Still, no wasted words and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the query mechanism well but lacks details on the return format (what fields are in 'note headers') and pagination behavior (limit/offset defaults). Given no output schema, these gaps reduce completeness. It adequately explains condition syntax and filters but misses output structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds significant value by detailing condition formats (scalar vs. operator objects), the list of operators, and type-awareness. It also clarifies semantics of 'match' and how additional filters work, enhancing understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds notes based on frontmatter conditions and returns note headers. It distinguishes from sibling tools like search_notes (full-text) and list_notes (simple listing) by specifying the frontmatter query capability and the types of conditions supported.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: for structured frontmatter queries. It does not explicitly state when not to use it or compare to alternatives, but the sibling tool list implies its niche. It offers guidance on the 'match' parameter and additional filters, which helps in decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one or more Obsidian notes by their relative paths. Returns { notes, errors }: notes is the array of parsed notes (path, contents, frontmatter, tags); errors lists any paths that could not be read (missing/too large), so one bad path never fails the batch. Path traversal still errors the whole call.
| Name | Required | Description | Default |
|---|---|---|---|
| paths | Yes | Note paths (.md optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses return format (notes, errors), behavior for missing/too large files, and that path traversal errors fail the whole call. It doesn't mention auth or rate limits, but for a read tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the main purpose and efficiently add critical behavioral details. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single parameter, no output schema, and no annotations, the description is nearly complete. It covers input format, return structure, and error modes. Missing potential limit on number of paths, but otherwise thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter description 'Note paths (.md optional)'. The description adds that paths are relative and explains error handling per path, providing valuable context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads notes by path, using a specific verb and resource. It distinguishes from siblings like search_notes and get_frontmatter by focusing on reading by relative path.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use this tool (to read notes by path) and provides nuanced guidance on error handling: one bad path doesn't fail the batch but path traversal does. It implicitly suggests alternatives like search_notes for content search, though not explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a single section of a note without loading the whole note. Address the section by bare heading (when unique) or by a " > "-joined heading-path (e.g. "Projects > Log") when the heading repeats. Returns the heading plus its own body; set include_subsections to include nested subsections.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Note path (.md optional) | |
| section | Yes | Heading text, or a " > "-joined heading-path when the heading is ambiguous | |
| include_subsections | No | Include nested subsections in the returned content (default false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must bear full weight. It explains what is returned (heading + body) and the effect of include_subsections, but does not mention error behavior (e.g., missing section) or confirm read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with purpose, no fluff. Every sentence adds useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main usage and return content for a simple read tool, but lacks details on error handling and output format, which would be helpful given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds significant value beyond schema: explains how to interpret the 'section' parameter (bare heading vs. heading-path) and the role of 'include_subsections', while schema already describes types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Read') and resource ('a single section of a note'), and distinguishes from siblings like 'read_notes' and 'get_outline' by emphasizing partial loading.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on addressing sections (bare heading vs. path) and the include_subsections option, but does not explicitly contrast with sibling tools or state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Map a calendar date to its canonical daily-note path, using the Daily Notes core plugin's own configuration (.obsidian/daily-notes.json: folder, format, template; OBSIDIAN_DAILY_FOLDER overrides the folder). Returns { date, path, exists, template }: date is the resolved ISO day, path the canonical note path (no .md; slashes in the configured format nest folders, as in Obsidian), exists whether the note is on disk, template the configured daily template path or null. Read-only — existing tools do the rest: apply_template (which accepts the returned template path) or write_note to create it, append_note/append_to_section to log into it, read_notes/read_section to read it. Errors when daily notes are not configured. Note: {{date}}/{{time}} in an applied template expand with the current moment, not the resolved day — exact Obsidian parity for today, a known caveat when creating past/future notes.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | "YYYY-MM-DD", or "today" (default) | "yesterday" | "tomorrow" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses behavioral traits: read-only operation, error conditions (when daily notes not configured), path format (no .md, slashes nest folders), and the template expansion caveat. This is comprehensive beyond what annotations would typically provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured, starting with the main purpose, followed by return details, usage guidance, and a caveat. While slightly long, every sentence contributes meaning; a minor trim could improve conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is fully complete for this tool: it explains output fields, error scenarios, and how it fits with sibling tools. No output schema is needed given the detailed return description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'date' is fully described in the schema (100% coverage). The description adds value by listing accepted string values ('today', 'yesterday', 'tomorrow', 'YYYY-MM-DD') and the default behavior, enhancing the schema's meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool maps a calendar date to a canonical daily-note path using the Daily Notes plugin configuration. It specifies the verb 'map' and resource 'daily-note path', and distinguishes it from sibling tools like note resolution or file search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool (to get the path) and what to do next: 'existing tools do the rest: apply_template, write_note, append_note, etc.' It also mentions the caveat about template expansion for past/future dates, which guides appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve a human-facing note name (frontmatter title, an alias, or the file basename) to its canonical note path — an exact, case-insensitive, index-backed lookup that removes the search-then-guess round trip for "what's the path of the note called X?". Matching is exact, never fuzzy (use search_notes_ranked for approximate matching). Returns { query, matches, resolved }: matches is the array of { path, title, matched_on } (matched_on is "title"|"alias"|"basename"; a note matching on several fields appears once, labeled with its strongest field, title > alias > basename), sorted by path; resolved is the single path when exactly one note matches, else null (ambiguous or no match — it never guesses).
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The human-facing name to resolve (title, alias, or basename) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses exact, case-insensitive, index-backed lookup; no destructive actions; details return structure (matches array with path, title, matched_on; resolved field). Completely transparent given no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise yet comprehensive; all sentences add value, but could be slightly tighter. Front-loaded with core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Thorough coverage of return values, edge cases, and behavioral details despite no output schema. Fully equips agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema describes query parameter; description adds context about name types and matching semantics, exceeding baseline for 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool resolves note names to canonical paths, lists valid name types (title, alias, basename), and distinguishes from siblings by emphasizing exact, not fuzzy, matching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use (known name, need exact path) and when not to (approximate matching, use search_notes_ranked). Explains behavior for ambiguous or no matches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search notes with ripgrep, optionally scoped by folder, tags, or a frontmatter where filter (index-resolved candidates, then rg over just those notes). Paginates over matching files: returns { results, truncated, files_returned, files_skipped, files_omitted, matches_capped_in }. Each match carries line_number (file-absolute, ripgrep's) and body_line (1-based body-relative with frontmatter stripped — the same line convention as get_outline/list_tasks/set_task_state, so a hit can be handed straight to those tools; null for hits inside the frontmatter block or in a file the index does not track).
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Restrict to notes carrying these tags (leading '#' optional). | |
| limit | No | Max number of files (result entries) to return (default: 20, 0 = unlimited) | |
| match | No | Semantics of tags: 'any' (default) or 'all'. | |
| where | No | Restrict to notes whose frontmatter satisfies these conditions (query_notes syntax). | |
| folder | No | Restrict to notes under this folder. | |
| offset | No | Matching files to skip, for pagination (default 0). | |
| pattern | Yes | The search pattern to use with ripgrep | |
| multiline | No | Enable multiline matching | |
| whole_word | No | Match whole words only | |
| context_lines | No | Number of context lines to show (default: 5) | |
| case_sensitive | No | Case sensitive search (default: false) | |
| max_matches_per_file | No | Max matches to return per file (default: 20, 0 = unlimited) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses pagination behavior with returned fields, explains line_number and body_line conventions, and notes special cases (null for frontmatter hits or untracked files). No annotations provided, so description carries burden well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single paragraph with front-loaded core action. Dense but efficient; no unnecessary words. Could be slightly more structured for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 12 parameters, no output schema, and no annotations, description covers pagination output, match fields, and nuance of body_line. Lacks details on performance bounds or error conditions, but sufficient for selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds context on return structure and index-resolved approach, but does not significantly enhance parameter meanings beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Search notes with ripgrep' and describes scoping by folder, tags, or frontmatter filters. Distinguishes from sibling search_notes_ranked by not mentioning ranking, but does not explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like search_notes_ranked or query_notes. Does not mention when-not-to-use or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full-text search ranked by BM25 relevance, optionally scoped by folder, tags, or a frontmatter where filter. Returns the most relevant notes first (title/heading/tag matches boosted) as note headers with score and snippet. Complements search_notes (which is literal/regex, unranked). A positive limit is capped at 100; offset pages past the cap.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Restrict to notes carrying these tags (leading '#' optional). | |
| limit | No | Maximum number of results (default 100; 0 = unbounded; a positive limit is capped at 100). | |
| match | No | Semantics of tags: 'any' (default) or 'all'. | |
| query | Yes | Free-text query (max 1000 chars). Multi-word queries are ranked by relevance. | |
| where | No | Restrict to notes whose frontmatter satisfies these conditions (query_notes syntax). | |
| folder | No | Restrict to notes under this folder. | |
| offset | No | Ranked hits to skip, for pagination (default 0). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the ranking algorithm, result format (headers with score and snippet), boost for title/heading/tag matches, and pagination cap. It does not explicitly state read-only nature or error conditions, but for a search tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three well-structured sentences. First sentence gives core purpose and scoping, second explains results and boosting, third contrasts with sibling and adds cap detail. Every sentence earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 parameters, no output schema, no annotations), the description covers the main behavioral aspects: ranking, scoping, result structure, and pagination. It lacks explicit details on error handling or the exact return format fields, but overall is sufficient for selecting and using the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaningful context beyond schema by mentioning 'title/heading/tag matches boosted' (ranking behavior) and 'offset pages past the cap' (pagination nuance). This extra information justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs 'full-text search ranked by BM25 relevance' and lists scoping options. It distinguishes itself from the sibling 'search_notes' by contrasting relevance ranking vs literal/regex unranked search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Complements search_notes (which is literal/regex, unranked),' guiding when to use this tool vs the alternative. It also notes the positive limit cap at 100 and offset pagination, providing clear usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0find_by_tagget_configget_frontmatterget_linksget_outlineget_propertyget_related_notesget_vault_statslist_fileslist_folderslist_noteslist_propertieslist_property_valueslist_recent_noteslist_tagslist_taskslist_templateslist_vault_issuesquery_notesread_notesread_sectionresolve_daily_noteresolve_notesearch_notessearch_notes_rankedEach tool has a clearly distinct purpose. For example, search_notes vs search_notes_ranked serve different search paradigms, and frontmatter tools (get_frontmatter, get_property, list_properties, list_property_values, query_notes) each target a different aspect. No two tools overlap significantly.
All tools follow a consistent `verb_noun` pattern (e.g., get_frontmatter, list_notes, search_notes_ranked). The verbs vary (get, read, search, list, find, resolve, query) but the structure is uniform and predictable, making navigation easy.
25 tools is well-scoped for a feature-rich Obsidian server. The number covers reading, searching, listing, metadata, vault analysis, and more without being excessive. Each tool earns its place, and the count aligns with the complexity of the domain.
The tool set is heavily read-focused, with no write operations (create, update, delete notes) present. While read coverage is thorough, the lack of write tools is a significant gap for an Obsidian server, limiting agent actions to inspection only.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Markdown-based note-taking with a hosted MCP server. Your notes serve you and your AI.
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
Google Keep-style notes app with an MCP server for AI agents to read/write notes.
Driflyte MCP server which lets AI assistants query topic-specific knowledge from web and GitHub.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/emguide/headless-obsidian-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
