Another bloated Obsidian MCP Server

by diegorv

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v1.3.0
Disambiguation3/5
Most tools have clear, distinct purposes, but there are overlapping pairs such as get_daily_note and create_daily_note (both create if missing), and add_tag vs add_to_array_field for managing tag arrays. The descriptions help, but with 50 tools, some ambiguity remains.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern in snake_case (e.g., list_vaults, read_note, batch_move). Prefixed batch operations and specific verbs like get/list/find/query are used predictably, making the naming highly uniform.
Tool Count2/5
With 50 tools, the server is excessively large for most use cases. The name itself suggests bloat, and while the domain is broad, many tools are redundant or could be combined (e.g., batch operations, frontmatter fields). This crosses the 25+ threshold for 'too many'.
Completeness4/5
The toolset covers a comprehensive range of Obsidian vault operations: note CRUD, frontmatter, tags, links, daily notes, templates, bases, attachments, and backups. Minor gaps exist (e.g., no explicit folder listing, but folders are implicit in paths), and some redundancies, but no critical dead ends.
Average 3.8/5 across 50 of 50 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
This repository is archived. Archived repositories automatically receive an F maintenance tier.
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While it implies destructiveness via 'Delete', it does not explicitly state that deletions are permanent or irreversible, nor does it mention the dryRun safety mechanism described in the schema. The per-note retention rule is useful but lacks cautionary context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence with no redundant wording. It leads with the action verb and delivers the core purpose concisely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations and no output schema, the description is under-specified. It lacks detail on execution behavior, safety mechanisms (beyond schema), error conditions, and relationship to backup management workflows, leaving the agent with an incomplete picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides complete descriptions and defaults for all 3 parameters (100% coverage). The description adds minimal meaning beyond a high-level reference to retention policy, which aligns with the keepLast parameter but does not explain how it works in practice.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Delete' and the resource 'old backups', with the qualifier 'keeping only the most recent ones per note'. This distinguishes it from siblings like create_note_backup, list_backups, and restore_backup, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided regarding when to use this tool or how it compares to alternatives. There is no mention of prerequisites, typical cleanup workflows, or interactions with sibling tools like list_backups or restore_backup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states that the tool removes a field, implying mutation, but does not disclose edge-case behavior such as what happens if the field does not exist, whether the operation is idempotent, or if it modifies the note file in place.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the verb and is free of fluff. Every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool is simple, the description provides only the basic action with no usage context or behavioral detail. Given the lack of annotations and the existence of closely related sibling tools, the description is insufficient for an agent to fully understand its behavior and appropriate use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes both parameters (path and field) with the schema coverage at 100%. The description adds no additional semantic value beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove') and the target ('a specific field from the frontmatter of a note'). It is specific and distinguishes from sibling tools like remove_from_array_field by focusing on a field rather than an array element.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as update_frontmatter or remove_from_array_field. The description only states what it does, not when it is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the output is 'raw content' (useful transparency), but does not mention error behavior (e.g., missing template), access permissions, or whether the operation is read-only. The lack of such context is a gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It immediately conveys the tool's core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read operation, the description is adequate but leaves gaps: it does not explain the return format beyond 'raw content', nor does it address error cases or relationship to similar tools. Given no output schema and no annotations, more detail would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter 'name', which already states it expects a template name without extension. The tool description adds no extra meaning beyond this, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get the raw content of a template file' clearly states the verb (Get), resource (template file), and scope (raw content). It distinguishes from siblings like list_templates, apply_template, and create_from_template by focusing on retrieval of raw file content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention that it should be used when you need the underlying template content before applying or editing, nor does it exclude cases handled by read_note or apply_template.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits but it does not. It does not confirm the operation is read-only, describe return data format, or mention any side effects like pagination or active vault requirements. 'Query' implies safety but is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences that are front-loaded with the action and resource. No redundant words; the second sentence adds a small but relevant detail on how filtering works.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has moderate complexity (5 parameters, nested filter object) and no output schema or annotations. The description covers the basic query capability but omits return value structure and any behavioral context, which would be needed for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all 5 parameters with clear descriptions (100% coverage), so the baseline is 3. The description's 'Filter by providing column-value pairs' merely restates the filter parameter's schema example and adds no new semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Query') and resource ('Obsidian Base'), and notes the optional capabilities (filter, sort, limit). This makes it distinct from sibling tools like get_base or search_vault, as it's specifically for querying base data with filtering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. There is no mention of excluding cases, prerequisites, or alternative tools like get_base or search_vault. The description only states capabilities, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It claims the graph is 'complete', yet the maxNodes parameter allows truncation to a default of 500 nodes, which is not mentioned. It also omits details about return structure, pagination, or performance implications for large vaults.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler, redundancy, or unnecessary clauses. Every word contributes to conveying the tool's core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema or annotations, the description leaves critical gaps: it does not explain the JSON shape of 'nodes and edges', how maxNodes affects the 'complete' claim, or how this graph tool relates to the more specific link-focused siblings. The tool likely needs more behavioral context to be used correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with maxNodes clearly documented as 'Maximum number of nodes to include (default: 500)'. The description adds no further parameter detail, meeting the baseline for complete schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get the complete link graph of the vault as nodes and edges', specifying a distinct verb and resource. It differentiates itself from sibling tools like get_outlinks and get_backlinks that focus on individual link lists rather than the full graph.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a complete vault-wide graph is needed, but provides no explicit guidance on when to prefer this over get_outlinks, get_backlinks, or find_orphans. There are no when-not-to-use or alternative tool mentions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It only mentions optional date filtering, but does not describe sorting, pagination, return format, or what constitutes a daily note. 'List' implies read-only, but lacks critical context for an agent to anticipate behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence that front-loads the primary action and optional filter. It contains no redundant words or filler, achieving high clarity in minimal space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Since there is no output schema and no annotations, the description should explain return values and behavioral details. It does not mention what the response contains, ordering, or limits beyond the schema default. For a listing tool, this leaves significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100% with each parameter already documented. The description adds only 'optionally filtered by date range', which largely duplicates schema information and provides no additional semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and a resource 'daily notes', which clearly distinguishes it from siblings like get_daily_note (singular), create_daily_note, and append_to_daily. The optional date range filter is also explicitly mentioned, 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing daily notes but provides no explicit guidance on when to use it over alternatives like list_notes or get_daily_note. Sibling names offer context, but the description itself does not state exclusions or alternatives, so guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the core operation without mentioning side effects (e.g., whether the field is deleted if empty), error handling for missing fields, or reversibility. For a mutation tool, this is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the verb and resource, with a parenthetical example. Every word is necessary, and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations, no output schema, and only basic parameter descriptions, the description is too sparse. It does not explain return behavior, error conditions, or edge cases (e.g., removing non-existent values), leaving the agent with insufficient context for robust invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all 3 parameters with descriptions, so the baseline is 3. The description adds examples ('tags', 'aliases') for the field parameter, but this merely echoes schema examples. No additional semantic value is provided beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Remove' and clearly identifies the resource: array field in frontmatter, with examples (tags, aliases). This distinguishes it from sibling tools like add_to_array_field (which adds) and remove_frontmatter_field (which removes an entire field).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case: removing specific values from array fields in frontmatter. However, it does not explicitly state when to use this tool versus alternatives like remove_tag or update_frontmatter, nor does it provide exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It does reveal one key behavior: 'Creates the field if it does not exist.' However, it omits other important behaviors such as error handling when the field is not an array, idempotency (duplicates ignored is only in schema, not description), and the impact of createIfMissing=false. The description is not misleading but is incomplete for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly written sentence that front-loads the primary action and includes a useful example. It has no redundancy or filler, earning full marks for conciseness and structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple, and the schema documents all parameters, so the description does not need to explain return values (no output schema). However, given the absence of annotations and the existence of closely related sibling tools, the description lacks essential context about edge cases (e.g., non-array fields, failed additions when createIfMissing=false) and how this tool fits with alternatives. It is minimally complete but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since schema description coverage is 100%, the baseline for this dimension is 3. The description adds little beyond the schema: it gives examples of field values (tags, aliases) and reiterates the create-if-missing behavior, both of which are already captured in the parameter descriptions. No additional parameter meaning is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Add values to an array field in frontmatter (e.g., tags, aliases).' It mentions a specific resource (frontmatter array fields) and action (add values), which distinguishes it from related tools like remove_from_array_field. However, it does not explicitly name alternatives like add_tag, so it stops short of fully differentiating from all siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by giving examples like 'tags, aliases' and mentions the behavior of creating the field if absent. However, it does not explicitly state when to use this tool versus alternatives (e.g., add_tag, update_frontmatter) or provide exclusions. The usage guidance is therefore only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Register a new Obsidian vault with a name and path,' but does not explain side effects, validation of the path, whether the vault becomes active, or return behavior. This is a significant gap for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the main verb and resource. It contains no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two fully described parameters, but the lack of annotations and output schema means the description should explain what 'register' entails and what the caller can expect as a result. It does not, leaving the behavior somewhat ambiguous. Adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with descriptions for both name and path. The description merely echoes 'name and path' without adding any additional meaning, so it does not go beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Register') and resource ('a new Obsidian vault'), including the key arguments (name and path). It distinguishes itself from sibling tools like list_vaults and set_active_vault by implying creation rather than listing or activation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when a user wants to add a new vault, but it provides no explicit guidance on when to use it versus alternatives, nor does it mention prerequisites or exclusions. No alternative tools are referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action without mentioning side effects, error conditions (e.g., nonexistent tag), idempotency, or whether the change is reversible. For a mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately conveys the core function. It is appropriately sized and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no nested objects) and full schema coverage, the description is minimally viable. However, with no annotations and no output schema, it lacks information about return values, failure behavior, and edge cases, leaving gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters (path and tag) already described in the schema. The description adds no additional meaning beyond what the schema provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove a tag') and the resource ('a note's frontmatter'), with a specific verb and target. It distinguishes itself from siblings like add_tag and remove_from_array_field by being narrowly scoped to tags in frontmatter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use this tool to remove a tag from a note's frontmatter. However, it does not explicitly mention when not to use it or alternatives such as remove_from_array_field or update_frontmatter, leaving the guidance implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it sets state but does not disclose persistence, failure modes, or whether the vault must already be registered. For a state-changing operation, this is insufficient detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, clearly front-loaded with the verb and resource. It efficiently states what the tool does and its purpose without wasting words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description omits important context such as whether the setting persists, what happens on invalid input, and how the vault name relates to list_vaults. With no output schema or annotations, more behavioral context would make it more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the 'vault' parameter, so the description does not need to add much. It does not add syntax or source details beyond the schema, but schema coverage is 100%, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the verb 'set' and the resource 'active vault', and explains its purpose for subsequent operations. This distinguishes it from sibling tools like list_vaults and register_vault, which manage vaults rather than set the current one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for subsequent operations' provides some context, implying that this tool should be used before other operations that require a vault context. However, there is no explicit guidance on when to use this tool vs alternatives, nor any mention of prerequisites like having a registered vault.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose that the tags array will be created if missing, which is useful behavioral context. However, it does not explicitly state that this mutates the file, whether duplicates are allowed, or whether other frontmatter fields are preserved.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the core action and followed by a relevant behavioral note. No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters, no annotations, and no output schema, the description adequately covers the primary behavior and parameter semantics via the schema. It lacks explicit usage guidance and duplicate handling, but these are minor gaps for this straightforward mutation operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes both parameters (tag and path) with examples. The description adds no extra meaning beyond what the schema provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action ('Add a tag') and the target ('a note's frontmatter'), and it also states the key side effect of creating the tags array if it doesn't exist. This distinguishes it from siblings like remove_tag and list_tags.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like add_to_array_field or update_frontmatter, nor any exclusions or prerequisites. The description is purely operational without contextual usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does add return-value details (paths, names, dates, sizes) and implies a read-only operation via the verb 'List,' but it does not explicitly state that it has no side effects or mention any permissions or limitations, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core action and resource, then lists capabilities and return fields. Every phrase earns its place with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with seven parameters and no output schema or annotations, the description covers the essential scope (markdown notes), return fields, and key features (sorting, filtering, pagination). It could be more explicit about default behaviors or the read-only nature, but the schema fills in parameter details, making it adequately complete for a list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for all parameters, so the baseline is 3. The description does not elaborate on parameter semantics, but the schema already provides thorough descriptions for limit, folder, offset, sortBy, recursive, sortOrder, and namePattern, so no additional meaning is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists markdown notes in the vault with sorting, filtering, and pagination, and specifies the return fields (paths, names, dates, sizes). This distinguishes it from sibling list tools like list_daily_notes or list_attachments by focusing on general notes with a specific resource scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives such as search_vault or list_daily_notes. It implies usage through its feature list but lacks any when-to-use or when-not-to-use instructions, so the agent receives no decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosure. It usefully mentions that parent directories are created automatically and that frontmatter is optional, adding behavioral context. However, it does not clarify behavior if the path already exists (e.g., overwrite or error), nor any permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the primary purpose. Every sentence adds value: the first states the core function, the second clarifies two important behaviors (auto-created directories, optional frontmatter). No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create tool with no output schema and no annotations, the description covers the essential action and key edge cases (directories, frontmatter). However, it omits what happens on duplicate paths, return values, and error conditions, leaving some ambiguity for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers 100% of parameters with descriptions, so baseline is 3. The description reiterates the optional frontmatter but does not add new semantic detail beyond the schema. It does add context about directory creation, which is slightly useful for the path parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create) and the resource (a new markdown note in the vault), with specific scope. It distinguishes from sibling tools like create_daily_note and create_from_template by specifying a general markdown note.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating a new note, but it does not provide explicit guidance on when to choose this tool over alternatives like create_from_template or create_daily_note. No exclusions or alternative recommendations are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does add useful behavior details (storage location and timestamp naming), but it does not disclose potential side effects like folder creation, overwrite behavior, or error conditions. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, perfectly concise and front-loaded. Every word earns its place, with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple backup tool, but it lacks information about return values, error handling, or what happens when the source note doesn't exist. With no output schema and no annotations, these gaps are noticeable, though the tool's simplicity mitigates the impact.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema fully documents both parameters (path and backupFolder). The description adds minimal extra meaning beyond restating the storage location, which is already implied by the backupFolder default. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: creating a backup copy of a note, with the specific detail that it stores in a .backups folder with a timestamp. This distinguishes it from sibling tools like restore_backup and list_backups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for backing up a note but does not explicitly state when to use this tool versus alternatives, nor does it mention any prerequisites or complementary tools. It is a simple tool, so the lack of explicit guidance is noticeable but not critical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It states the fundamental definition of orphan, but does not clarify what counts as a link (wiki vs markdown, self-links), whether certain notes are excluded (e.g., templates, daily notes), or what the return format is (list of IDs, paths, full note objects). This leaves substantial ambiguity for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence: action first, definition in parentheses. Every word earns its place, and the definition is integrated clearly without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (no params, no output schema), so minimal description might suffice. However, without an output schema, the description does not hint at what the response contains (e.g., list of note paths or objects). This missing detail prevents a higher score, though the core function is fully conveyed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema provides no entries. The description adds semantic value by explaining what qualifies as an orphan note, which helps an agent interpret the result set. Baseline 4 is appropriate for a zero-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Find all orphan notes') and immediately defines the key term ('notes with no incoming or outgoing links'), which distinguishes it from sibling tools like find_broken_links or get_backlinks. The verb and resource are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: call this when you need to identify notes that are completely unlinked. However, it gives no explicit guidance on when not to use it or how it compares to alternatives like find_broken_links or get_link_graph. For a zero-parameter tool, some context about expected use cases would help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The core behavior (finding unreferenced attachments) is stated, but key traits like vault-wide reference scanning, the effect of the optional folder parameter, and return format are not disclosed in the description, only partially in 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. It front-loads the action and resource, followed by a brief, useful use-case statement. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description gives the essential purpose but leaves gaps: it does not clarify what counts as 'referenced,' whether the search is vault-wide (only implied in the schema), or what the tool returns. It is adequate for a simple tool but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the 'folder' parameter is well-documented in the schema with 'references are always searched vault-wide.' The tool description itself adds no parameter-level information, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Find' with a clearly defined resource: 'attachments that are not referenced by any note.' This precise scope distinguishes it from sibling tools like list_attachments (all attachments) and find_orphans (unlinked notes), and adds the practical context of cleaning up unused files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Useful for cleaning up unused files' gives clear context for when to use this tool. However, it does not explicitly name alternative tools or state when not to use it, so it misses the top score for exclusions and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It indicates a read-only nature and includes embed/link syntax in the output, but it does not explain what other details are returned, error handling, or any prerequisites. The description adds some context beyond the tool name but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no redundant words. It efficiently states the purpose and a key output detail, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 covers the core purpose but leaves gaps: it does not specify the full set of returned information, potential edge cases, or how the attachment path is resolved. The embed/link syntax note is helpful, but the vague 'detailed information' is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the single parameter 'path' with 'Path to the attachment file,' achieving 100% schema description coverage. The description does not add further semantic meaning, such as path format or vault relationship, so it provides no extra value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get detailed information') and the resource ('an attachment'), with a specific output detail ('embed/link syntax'). This distinguishes it from sibling attachment tools like list_attachments and get_attachments_in_note.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it is used for retrieving details on a specific attachment via a path, but it does not explicitly state when to choose this tool over alternatives like list_attachments or get_attachments_in_note. No exclusions or alternative guidance are provided, making the usage context only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only adds that both link types are included, but fails to explain return format, link resolution behavior, or handling of broken/self links. No output schema exists, so this gap is significant.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the tool's action and scope without any filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter, but the absence of an output schema and any behavioral details means the description does not fully prepare the agent for what to expect. It is adequate for basic understanding but incomplete for nuanced use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the 'path' parameter already described as 'Path to the note'. The description adds no new meaning beyond the schema, so it meets the baseline but does not elevate it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('Get'), resource ('outgoing links'), and scope ('from a note'), clearly distinguishing it from siblings like get_backlinks (incoming links) and get_link_graph (graph structure). It also specifies it returns both wikilinks and markdown links, leaving no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating exactly what it retrieves, and the inclusion of both link types provides useful context. However, it does not explicitly mention when to avoid this tool in favor of alternatives like get_backlinks or find_broken_links, so it lacks explicit exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the return value (count of updated links) and the optionality of link updates, but does not mention consequences of setting updateLinks to false (e.g., broken links) or any required permissions. It adds some value but leaves key behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the core action and immediately followed by the return value. Every word earns its place; there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter tool with no output schema, the description covers the purpose, optional behavior, and return value. However, it omits caveats like the risk of broken links when updateLinks is false, and does not clarify whether the old path is fully replaced or if any validation occurs. Adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3 applies. The description adds context about wikilink updates and the returned count, but does not provide additional syntax or format details beyond the schema. It earns the baseline without exceeding it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Rename') and resource ('a note'), and highlights the distinguishing feature of optionally updating wikilinks. This clearly separates it from sibling tools like move_note or update_note.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when renaming a note while maintaining link references, but does not explicitly mention alternatives or exclusions (e.g., move_note for path changes without link updates). There is no explicit 'when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of explaining behavior. It discloses the search scope and supports regex/context lines, but does not mention read-only nature, result format, or important defaults like case sensitivity and maxResults cap. These are partially covered by the schema, but the description alone leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core purpose and two noteworthy features without waste. Every word earns its place, and it is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has six parameters and no output schema, so the description needs to clarify what the tool returns. It mentions 'context lines around matches' but does not explicitly state that the tool returns matching files or how results are structured. Schema provides parameter semantics, but behavioral outcomes remain somewhat underspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides detailed descriptions and defaults for all six parameters (100% coverage), so the baseline is 3. The description adds minimal value beyond the schema, only reinforcing regex and context line capabilities that are already documented in the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's verb ('Search'), resource ('all notes in the vault'), and key features ('regex patterns', 'context lines'). This distinguishes it from sibling tools like search_by_tag, which searches by tag rather than text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning text search across all notes and regex support, but it provides no explicit guidance on when to use this tool versus alternatives such as search_by_tag, list_notes, or other search variants. There are no 'when not to use' or alternative tool recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses confirmation and per-note results, but omits details on permanence (trash vs permanent), auth, or partial failure behavior (rollback vs partial success).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short, front-loaded sentences. Every sentence adds value: action, confirmation, and return behavior. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with no output schema, the description covers the core aspects: what it does, confirmation, and return results. It could mention permanence or error handling, but overall it's nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described ('paths' and 'confirm'). The description adds no extra semantic meaning beyond the schema, only echoing the confirmation requirement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete multiple notes at once' uses a specific verb and resource, clearly distinguishing this batch operation from the sibling delete_note tool. It also mentions confirmation and per-note results, reinforcing the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for deleting multiple notes but does not explicitly state when to prefer this over delete_note or other alternatives. No exclusions or prerequisites beyond confirmation are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds value by stating it returns per-note success/failure results, which is not in the schema. However, it does not discuss side effects such as link updates (though covered by the updateLinks param) or failure handling, leaving some transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action 'Move', and contains no redundant information. It efficiently conveys the tool's purpose and key return behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description provides the essential information: what the tool does, its bulk nature, and the per-note result format. Combined with the fully documented schema, this is adequately complete for an agent to select and invoke the tool, though it could add explicit guidance on when to use it over single-note move.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all three parameters having meaningful descriptions. The tool description mentions 'multiple notes' and 'destination folder' which loosely correspond to paths and destinationFolder, but adds no new information beyond the schema. Therefore the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Move' with the resource 'multiple notes' and destination folder, clearly distinguishing it from the singular move_note tool. It also mentions the per-note results, making the batch nature explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies batch usage through 'multiple notes' and 'at once', but does not explicitly state when to use this tool over alternatives like move_note or batch_read_notes. There is no exclusion or alternative guidance, so it remains at the 'implied usage' level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It adds the key behavioral detail of merge vs. replace, which is valuable for understanding impact. However, it does not disclose other important traits such as error handling on partial failures, atomicity, or whether the operation is reversible, which are critical for a batch mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, using two short sentences to convey the core purpose and a key behavioral toggle. Every word earns its place with no redundancy or extraneous detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite complete parameter documentation, the description omits crucial contextual information for a batch operation: what happens on partial failure, whether changes are applied atomically, and what the return value indicates. Without an output schema and given the destructive potential of 'replace', these gaps leave the description insufficient for confident use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage of parameters, including the replace boolean and 'set value to null to remove field'. The description's mention of 'merge or replace' adds minimal semantic value beyond the schema's description of the replace parameter, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update frontmatter of multiple notes at once', combining a specific verb (update), resource (frontmatter), and scope (multiple notes). This distinguishes it from the sibling tool update_frontmatter, which operates on a single note. The added 'Can merge or replace frontmatter' further clarifies the behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'multiple notes at once' clearly implies this is for batch operations, contrasting with single-note update tools. However, it does not explicitly state when to use this tool over alternatives or provide exclusions, such as 'use update_frontmatter for a single note'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It clearly indicates a read-only operation ('get') and specifies that the result is references (embeds and links), not attachment content. However, it does not disclose output format, resolution behavior, or whether references in frontmatter are included, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the main verb and object, and contains no redundant or filler words. It is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description adequately explains its core purpose and result type. However, it could have clarified the return structure (e.g., a list of paths or objects) and whether it includes all link types consistently, making it slightly incomplete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the only parameter 'path' as 'Path to the note', giving 100% coverage. The description adds no additional meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves all attachment references (embeds and links) within a specific note, using the specific verb 'get' and resource 'attachment references in a note.' This distinguishes it from sibling tools like list_attachments (vault-wide) or get_attachment_info (single attachment metadata).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'in a specific note' implies the tool is scoped to a particular note, so an agent could infer when to use it. However, there is no explicit guidance on when to choose this over alternatives like list_attachments or get_attachment_info, and no exclusions or conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the behavioral disclosure burden. It clarifies that the tool performs a read operation and returns schema and rows, but it does not mention potential performance implications, permission requirements, or return format details, leaving gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the tool's function with no superfluous words. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple one-parameter schema and clear purpose, the description is largely complete. It covers what the tool does (full content, schema, rows), though it could mention that query_base exists for filtered queries, which would make it fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with 'path' described as 'Path to the .base file', which is clear. The description adds no further parameter semantics beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get the full content of an Obsidian Base including schema and all rows', with a specific verb (Get), clear resource (Obsidian Base), and explicit scope (schema and all rows). This clearly distinguishes it from siblings like list_bases (listing) and query_base (querying).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when full base content is needed, but it does not explicitly state when to use this tool instead of alternatives like query_base or list_bases. No exclusions or alternative recommendations are provided, so guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states the tool returns a JSON object, but it does not disclose behavior for missing notes, malformed frontmatter, or error handling. The read operation is simple, but the description adds minimal behavioral context beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence that front-loads the action and resource. No filler or redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one parameter and no output schema, the description is mostly complete. It explains the return type (JSON object) but omits edge-case behavior such as missing note handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the path parameter already described. The description adds no additional parameter semantics, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') with a clear resource ('YAML frontmatter of a note') and outcome ('as a JSON object'). It distinguishes itself from sibling tools like read_note (full note content) and update_frontmatter (modification).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when frontmatter is needed, but it does not explicitly state when to use this tool over read_note or provide exclusions. No alternatives are mentioned, so the guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. 'List' inherently conveys a read-only operation, and the description specifies what qualifies as an attachment (non-markdown files). However, it omits details like recursion behavior, output format, or handling of hidden files, which an agent might need.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('List all non-markdown files') and then states the filter option. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema or annotations, the description covers the core purpose and filters, which is largely sufficient for a simple list tool. However, it does not specify the return format (e.g., full paths vs. names) or whether subfolders are included recursively, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well-documented. The description's 'Can filter by folder and type' merely restates the schema properties and adds no new meaning beyond what is already in the structured data.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all non-markdown files (images, PDFs, etc.) in the vault' with a specific verb and resource, and it mentions filtering by folder and type. This distinguishes it from sibling tools like list_notes and get_attachments_in_note.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies vault-wide listing of non-markdown files, but it does not explicitly state when to use this tool over alternatives such as get_attachments_in_note or find_unused_attachments. It provides context (vault-wide vs. per-note) but no direct comparison or exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It implies a read-only listing via 'List' and 'available', but does not explicitly state non-mutating behavior, return format, or whether backupFolder affects the listing. It is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. The main action is front-loaded, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool, the description is mostly complete: it states the purpose and filtering capability, while the schema documents both parameters. Since there is no output schema, a brief mention of what the returned list contains would improve completeness, but it is not critical for a straightforward listing operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: both notePath and backupFolder have clear descriptions. The description's 'Can filter by specific note' restates notePath but adds no new semantics beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'List available backups.' It clearly distinguishes this from sibling tools like list_vaults and list_notes, and the filtering capability ('Can filter by specific note') adds scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The described filtering option gives some usage context, but it does not explicitly state when to use this tool versus the other backup-related siblings (create_note_backup, restore_backup, delete_old_backups) or mention any exclusions. Usage guidance is only implied by the tool name and sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It mentions variable substitution, which is a key behavior, but doesn't disclose what happens if the template is missing, whether existing notes are overwritten, or how errors are handled. This is a basic level of transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence, front-loaded with the verb, directly states the purpose. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has four parameters including a nested object, but no output schema. The description doesn't mention return values or behavior on failure. However, the purpose is clear and parameters are documented, so it's adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has descriptions for all parameters (100% coverage), so the description doesn't need to add per-parameter detail. The mention of variable substitution provides context that ties the parameters together, but adds little beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: creating a new note from a template with variable substitution. The verb 'create' plus resource 'new note' and method 'from a template with variable substitution' distinguishes it from sibling tools like create_note (which likely doesn't use templates) and apply_template (which may apply to existing notes).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a new note is needed from a template with variable substitution, distinguishing from create_note. However, it doesn't explicitly name alternatives or exclusions, so it provides clear context without explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states that the note 'changes location' and that wikilinks are 'optionally' updated, which are important side effects. However, it does not mention consequences like broken links if updateLinks is false, whether the move is reversible, or permission requirements. These gaps keep it at an adequate but incomplete level.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action. The second sentence efficiently adds two key clarifications (filename retention and wikilink updates) without any wasted words. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple with only three parameters, and the description covers the main behavior. However, given no output schema and no annotations, it would benefit from stating what the function returns (e.g., success status or new path) and any error conditions (e.g., missing note or nonexistent destination folder). The description is adequate but leaves some contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage with descriptions for all parameters, so the baseline is 3. The tool description adds value by clarifying the effect of destinationFolder ('Keeps the same filename but changes location') and the purpose of updateLinks ('Optionally updates all wikilinks'). This extra context connects the parameters to real-world behavior, raising the score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a clear action: 'Move a note to a different folder.' It specifies the resource (note) and the operation (move) with a destination folder. It also adds differentiation by noting 'Keeps the same filename' and 'Optionally updates all wikilinks,' which distinguishes it from sibling tools like rename_note or batch_move.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for moving a single note to a new folder, but does not explicitly contrast with alternatives like batch_move or rename_note. There is no 'use when' or 'instead of' guidance. The singular 'a note' and the focus on folder relocation give some context, but the lack of explicit exclusions leaves room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It hints at destructiveness by mentioning the optional backup creation, implying that restoration may overwrite current content. However, it does not explicitly state overwrite semantics, targetPath behavior, or failure conditions, leaving a transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action and a key optional behavior. Every word earns its place with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core action and the optional backup feature, but it omits return values, error scenarios, and the effect of targetPath. With no output schema and no annotations, the description should provide more context to be fully complete for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% description coverage for all three parameters, so the description needs minimal param info. The phrase 'Optionally creates a backup of current content first' aligns with createBackupFirst but adds no new meaning beyond the schema defaults and descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Restore a note from a backup', a specific verb+resource that clearly identifies the action. It distinguishes itself from sibling tools like create_note_backup and list_backups, 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool, especially the optional backup-first behavior ('Optionally creates a backup of current content first'). It does not explicitly exclude alternatives or list when-not-to-use, but the restore purpose is unambiguous and distinct from the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose that the operation adds to the frontmatter tags array, but it does not mention duplicate-tag handling, partial failures, or whether existing tags are preserved.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the core action and then adding the key target detail. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple batch mutation with fully documented params, the description plus schema is mostly sufficient. It lacks caveats about edge cases, but the core invocation is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters at 100%, so baseline is 3. The description adds no parameter-specific detail beyond saying 'multiple notes' and 'frontmatter tags array' that is not already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb+resource: 'Add tags to multiple notes at once', clearly distinguishing from singular add_tag. It also names the target 'frontmatter tags array', making the operation unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'to multiple notes at once' gives clear batch-use context and indirectly contrasts with single-note add_tag, but it does not explicitly state when not to use it or name alternatives like batch_remove_tag.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the tool is a read operation, supports up to 10 notes, and returns content and frontmatter. However, it does not describe error handling for missing paths or partial failures, which is relevant for batch operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action and limit, and contains no extraneous information. Every word earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a modest complexity with three parameters and no output schema. The description explains the return payload (content and frontmatter) and the maximum batch size, which covers the core context. It does not describe the exact response structure, but for a batch read operation this is acceptable given the schema richness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter having a clear description. The description adds no additional meaning beyond the schema; it mentions returning content and frontmatter, which aligns with the includeContent and includeFrontmatter defaults, but does not elaborate on parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads multiple notes at once with a maximum of 10, and returns content and frontmatter. This distinguishes it from the sibling 'read_note' which reads a single note. Specific verb and resource are present with no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for batch reading notes ('Read multiple notes at once') and clearly sets a limit of 10. It does not explicitly mention when not to use it or point to alternatives, but the context is clear since reading multiple notes is the obvious scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It specifies that removal happens in the 'frontmatter tags array,' which is valuable precision. However, it does not disclose error handling, idempotency, or permission requirements, leaving room for more transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action, and no redundant wording. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple batch operation with complete schema coverage and no output schema, the description is mostly sufficient. It clarifies scope and target. It could mention return values or partial-failure behavior, but the low complexity keeps gaps minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptions for both parameters (paths and tags). The description adds no further parameter-level details beyond indicating the operation targets frontmatter tags, so the schema carries the semantic load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Remove tags from multiple notes at once.' This clearly distinguishes it from sibling tools like remove_tag (single note) and batch_add_tag (opposite operation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'from multiple notes at once' clearly signals batch usage, providing clear context. However, it does not explicitly mention alternatives like remove_tag for single-note use or state exclusions, so it stops short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the important behavioral trait of not overwriting existing notes ('if it does not exist'), but does not mention what happens when the note exists, permissions, or return behavior. It adds some value but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action, and contains no fluff. Every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description covers the essential purpose and the key conditional behavior. It lacks explicit return value info, but the operation is straightforward enough that this is not a major gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the date parameter with description and default, so the baseline is 3. The description does not add additional meaning beyond the schema, only reinforcing the 'specific date' aspect.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create), the resource (daily note), the scope (for a specific date), and the idempotency condition (if it does not exist). This distinguishes it from siblings like create_note and get_daily_note.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (creating daily notes for specific dates) but does not explicitly name alternatives or exclusion criteria. The 'daily note' qualifier differentiates it from generic note creation tools, but more explicit guidance would be better.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explicitly discloses that the deletion is permanent and cannot be undone, which is a critical behavioral trait. It does not cover permissions or side effects on linked references, but the key destructive nature is clearly flagged.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short, front-loaded sentences that convey the action, the resource, and the key irreversible consequence. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter delete tool with no output schema and no annotations, the description sufficiently covers purpose and irreversibility, while the schema covers the parameter. It could explicitly note single-note vs. batch, but this is implied and not a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning about the 'path' parameter beyond what the schema already provides ('Path to the note to delete'), so no extra value is added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete) and the resource (note from the vault), with 'permanently' distinguishing it from reversible operations. It implies a single-note scope via 'a note' and the path parameter, which differentiates it from batch_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The irreversibility warning ('This action cannot be undone') implies use only when permanent deletion is intended. However, it does not explicitly mention alternatives like batch_delete for multiple notes or suggest creating a backup first, so guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It adds the clarifying definition of broken links, which is a behavioral trait beyond the name. However, it does not explicitly state read-only behavior, return format, or scope, though these are largely inferable for a simple query tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence: 'Find all broken links' followed by a concise parenthetical definition. Every word earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 parameters, no output schema), this description is sufficient for an agent to understand its purpose and select it appropriately. It might benefit from stating that it scans the active vault, but the current level is adequate for a simple finder.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty. Baseline is 4 for 0-parameter tools, and the description correctly omits parameter details. No further elucidation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('find') and resource ('broken links'), and the parenthetical defines the exact criterion: 'links pointing to non-existent notes'. This clearly differentiates it from siblings like get_outlinks (all links) and find_orphans (unlinked notes).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you want to identify links to missing notes) but provides no explicit guidance on alternatives or exclusions. It doesn't mention when not to use it or how it relates to similar tools like get_outlinks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the core operation (get backlinks) but does not add context such as whether the result includes note metadata, ordering, or behavior for missing paths. It is not misleading, but it is minimal for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly communicates the tool's purpose. There is no unnecessary verbosity or repetition, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter read tool without an output schema, the description adequately conveys what the tool does and what it returns (a list of notes). It does not specify the exact return format, but given the simplicity and lack of output schema, the description is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage for the only parameter ('path' is described as 'Path to the note'). The description does not add any extra meaning beyond the schema, such as whether the path is relative or absolute, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('all notes that link to a specific note'), and explicitly names the concept 'backlinks'. This clearly distinguishes it from siblings like 'get_outlinks' (which returns outbound links) and 'get_link_graph' (which returns the full graph).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly conveys the usage context: use this when you need to find inbound links to a specific note. However, it does not explicitly mention alternatives or when not to use it, so it falls short of full guidance. The intent is clear, but no exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It indicates a read-only listing operation but does not disclose return format, ordering, pagination, or any potential pitfalls (e.g., hidden bases, performance with large vaults). It adds basic context but lacks richer behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action and resource, and contains zero filler or repetition. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters and no output schema, the description is mostly complete. It explains exactly what is listed and the scope. It could optionally describe the output format (e.g., base names vs. paths), but that is not critical for a first-time invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool accepts zero parameters, so the schema provides full coverage (100%). The description reinforces the scope but adds no parameter-specific details, which is acceptable given there are no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' with a clear resource 'Obsidian Bases (database files)' and scope 'in the vault'. It clearly distinguishes this tool from siblings like list_vaults and list_notes by naming a unique resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating what it does, but offers no explicit guidance on when to prefer this tool over alternatives such as list_vaults or search_vault. There are no exclusions, prerequisites, or context about when this listing is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It clearly implies a read-only operation ('List'), but does not explicitly state side effects, permissions, or behavior for edge cases like an empty vault or sorting order. The occurrence count is mentioned, which adds some transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that conveys the tool's purpose and return value without any superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description is sufficient: it states what is returned (unique tags with counts) and the optional filter. It could be enhanced by explicitly stating read-only behavior, but this is not critical for a list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the optional 'folder' parameter, which is clearly described as 'Limit tag search to a specific folder'. The description adds no additional meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') with a clear resource ('unique tags') and scope ('in the vault with their occurrence count'). It distinguishes itself from sibling tools like add_tag, remove_tag, and search_by_tag by focusing on enumeration with counts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it lists all unique tags and optionally filters by folder. It does not explicitly name alternatives or state when not to use it, but the implied use case is evident from the verb and resource.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the burden of behavioral disclosure. It implies a read-only operation through 'List' and 'show', and adds useful context about the active vault. However, it does not explicitly confirm non-destructiveness, mention prerequisites, or describe edge cases, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, 'List all configured Obsidian vaults and show which one is currently active', with no redundant words. It is front-loaded with the primary action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters and no output schema. The description covers the core behavior (listing all vaults) and an additional useful detail (the active vault). It is adequate but could be slightly more explicit about return format or behavior when no vaults are configured.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema fully documents the input. The baseline for 0 parameters is 4, and the description adds no parameter-specific information because none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and clearly identifies the resource 'all configured Obsidian vaults', and adds that it shows the active one. This distinguishes it from sibling tools like list_bases, which likely operate on a different resource. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives such as list_bases or other list tools. However, the resource name and verb make the use case intuitive, so usage is implied rather than explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that both frontmatter and inline tags are searched, which is a useful behavioral detail beyond the schema. However, it does not mention return format, sorting, case sensitivity, or behavior when no notes match.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the core purpose and an important behavioral nuance. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity, the description is adequate for an agent to select and invoke it. The optional folder param is clear from the schema, and sibling tools provide context. It lacks explicit return value description, but this is not critical for a simple search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%—each parameter (tag, folder) has a clear description. The tool description adds no additional parameter context, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds notes by a specific tag and explicitly notes it works for both frontmatter and inline tags. This distinguishes it from sibling tools like list_tags (which lists tags) and search_vault (which does full-text search).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use when you need to find notes with a specific tag. It does not explicitly mention alternatives or exclusions, but the context is clear enough for a well-named tool with obvious sibling differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It states the operation is listing templates but does not disclose whether it returns template names, metadata, or full content, nor whether subfolders are included recursively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence with no filler; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple list operation but lacks explicit return value information. With no output schema, the AI agent does not know whether 'available templates' means names, objects, or full content.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline is 4. The description appropriately adds no parameter information since none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'list' with resource 'available templates' and location 'vault's templates folder', clearly differentiating from sibling tools like get_template or apply_template.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use (to see all available templates) but does not explicitly mention when not to use or name alternatives like get_template for a single template.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It does reveal a specific edge case: 'Prepend mode will error if content starts with "---" to prevent frontmatter conflicts,' which is valuable. However, it does not disclose the destructive nature of overwrite mode, what happens if the note path doesn't exist, or return value/error format. This is partial disclosure, not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the primary action ('Update an existing note'), and then efficiently summarizes the modes and a critical edge case. Every sentence adds value with zero redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter mutation tool with no output schema and no annotations, the description covers the core functionality and one important error condition. However, it omits mention of the 'ignoreFrontmatterConflict' parameter that directly addresses the stated error, and gives no information about return values, success/failure behavior, or the default mode. This is a noticeable gap for an agent selecting and invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds contextual meaning to the prepend mode by explaining the frontmatter conflict error, which is not fully captured in the schema. This enriches understanding of both the 'mode' and 'ignoreFrontmatterConflict' parameters, though it doesn't mention the escape hatch parameter directly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Update an existing note,' which is a clear verb+resource statement that distinguishes it from sibling tools like create_note, read_note, and delete_note. It further clarifies the different modes (overwrite, append, prepend, replace), making the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'existing note' implies this is for updating notes that already exist, contrasting with create_note. The modes themselves serve as usage guidance (e.g., append to add to end, replace for find-and-replace), but there is no explicit 'when-not-to-use' or named alternative. This is clear context but not fully explicit about exclusions or sibling alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description takes on full responsibility and reveals a key side-effect (creates the note if not exists) and how it uses the vault's daily notes configuration. It stops short of stating the return format or permissions, but the critical mutation behavior is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise, front-loaded sentences deliver the primary purpose first, followed by essential side-effect and configuration details. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-or-create tool with no output schema, the description covers the main behavior, creation side-effect, and configuration. It could mention the return value or prerequisites like an active vault, but these are fairly inferable from the tool's name and sibling context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the single 'date' parameter with format and default, achieving 100% coverage. The description's mention of 'specific date' adds no new meaning, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'daily note for a specific date,' while also revealing the create-if-not-exists behavior and configuration usage. This distinguishes it from sibling tools like create_daily_note and list_daily_notes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly specifies when to use this tool by noting it can create the note if missing, which guides the agent to retrieve-or-create. However, it does not explicitly name alternative tools or provide exclusions, missing the higher bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It explicitly states the return behavior (markdown content and parsed YAML frontmatter if present), conveying the read-only nature. It does not detail error handling, but for a simple read operation 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that immediately states the operation and return value. Every word earns its place, with no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one well-documented parameter, the description is complete. It covers what the tool does, what it returns, and the presence of frontmatter. It lacks only edge-case behavior (e.g., missing files), but this is not essential for such a straightforward operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with the path parameter fully described as 'relative to vault root' with an example. The description adds no additional parameter semantics beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: reading the content and frontmatter of a specific note. This distinguishes it from siblings like list_notes (which lists notes) and get_frontmatter (which only reads frontmatter), making it unambiguous which tool to use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you need both content and frontmatter of a specific note), providing clear context. However, it does not explicitly contrast with alternatives or state when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses key behaviors (merge, replace, null-removal) which are central to the tool's operation. It does not mention return values or error handling, but provides substantial context beyond a bare mutation statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose and followed by concise behavioral modifiers. Every sentence contributes meaningful information with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core functionality (merge/replace/remove) adequately for a tool of this complexity. However, it does not specify return value or failure behaviors, and with no output schema or annotations, these gaps leave some uncertainty. Overall, it is largely complete for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds the semantics that setting a value to null removes the field, which is not present in the schema's description for the 'updates' parameter. This enriches parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (update), the resource (YAML frontmatter of a note), and adds behavioral nuance (merge vs replace). It distinguishes from siblings like update_note and remove_frontmatter_field by specifying frontmatter-specific operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on merge/replace behavior and null-removal, but does not explicitly guide when to use this tool over specialized siblings like remove_frontmatter_field or update_note. The usage is implied rather than explicitly contrasted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. It explicitly states the key side effect that the note is created if needed, which is non-obvious and important. It also implies an append (not overwrite) behavior. It does not detail formatting or error handling, but for a simple append 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action and a key side effect. There is no redundant information or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with only two parameters and no output schema, the description fully conveys the core behavior and creation side effect. It is complete enough for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptions for both parameters ('Date in YYYY-MM-DD format (defaults to today)' and 'Content to append'). The tool description adds no additional semantic value beyond restating 'today' and 'date', so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Append content to today's daily note (or a specific date). Creates the note if needed.' It uses a specific verb ('Append') and resource ('daily note'), and the clarification that it creates the note if needed distinguishes it from simple read/write tools like get_daily_note or update_note.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning 'today's daily note' and 'a specific date', and the side effect 'Creates the note if needed' guides when to expect creation behavior. However, it does not explicitly name alternative tools or state when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behavioral traits: no file creation, returns processed content, and supports specific placeholder syntax. Since no annotations are provided, these details carry the full burden and are well covered, though error handling is not mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the main action and outcome, with no wasted words. Efficiently conveys purpose, behavior, and placeholder support.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a template processing tool, the description is complete: defines inputs, output, and side effects (none). The 'without creating a file' note differentiates it from sibling create_from_template, covering the needed context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already covers all parameters with descriptions, and the description adds meaningful context about placeholder transformation (e.g., {{title}}, {{date:FORMAT}}, custom {{variable}}), enriching the semantic understanding of the 'variables' parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States 'Apply a template with variables' with a specific verb and resource, and explicitly says it returns processed content without creating a file, distinguishing it from siblings like create_from_template.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context via 'without creating a file', implying it is for processing/previewing rather than file creation, but does not explicitly name alternative tools or conditions for non-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

another-bloated-obsidian-mcp-server MCP server

Copy to your README.md:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/diegorv/another-bloated-obsidian-mcp-server'

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