Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the behavioral burden. It discloses that the command string is passed exactly as written (minus the binary name), that leading `vault=NAME` overrides and caches the vault, and it maps cut-and-paste verbs to operations. It does not explicitly warn about destructive side effects, but the inclusion of delete/move verbs and the phrase 'Run any Obsidian CLI command' imply full capabilities.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Although the description is long, it is highly structured and front-loaded. The opening sentence states the purpose, the cheat sheet is organized by intent (PUT/GET/MOVE/DELETE/DISCOVER) with concise syntax, and each section earns its place. Nothing seems redundant or wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter tool with no output schema, the description covers all necessary context: the supported verb families, example command constructions, vault override mechanics, and a fallback to the `help` verb. It gives an agent enough to invoke the tool for nearly any intended Obsidian operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema defines a single `command` property with a minimal description. The tool description enriches this by specifying the exact string format (full CLI command minus the binary name), the `vault=NAME` prefix behavior, and a cheatsheet that maps common intents to concrete command strings. This adds significant meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a clear, specific verb+resource: 'Run any Obsidian CLI command.' It explicitly distinguishes itself from sibling convenience tools by stating that 'the convenience tools (`obsidian_*`) wrap the same verbs with typed args,' clarifying the scope and relationship.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use this tool versus the typed wrappers: use it for full CLI commands, and use the wrappers for typed arguments. It also directs users to the CLI's `help` verb as the source of truth for any unlisted intent, giving a clear fallback.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It explains that 'file' uses wikilink resolution and 'path' requires an exact path, but does not disclose behavior when both are provided, case sensitivity, or return format. This is partial transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and well-structured, leading with a one-sentence purpose, followed by a clear parameter list and two practical examples. No unnecessary content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter optional tool, the description covers the primary usage well. It does not mention precedence when both parameters are supplied or output details, but the absence is acceptable given the tool's simplicity and the presence of examples.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema only says 'File name' and 'File path', but the description adds meaningful semantics: 'note name (wikilink resolution)' vs 'exact file path'. This clarifies how each parameter is interpreted, going beyond the schema's basic labels.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'List backlinks to a note' with a specific verb and resource. This distinguishes it from sibling tools like obsidian_read or obsidian_search, which handle different operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context on how to use the tool with two optional parameters and examples. It does not explicitly mention when not to use it or alternatives, but the purpose is straightforward enough that guidance is implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full responsibility for disclosing behavioral traits. It mentions that it triggers commands 'exactly as the user would from the command palette,' but it does not warn that commands can have destructive or irreversible side effects (e.g., deleting files, modifying settings). This is a significant omission for a tool that executes arbitrary commands, as the agent may unknowingly perform harmful actions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and front-loaded, starting with the core purpose and then providing supplementary details. It is concise, with no unnecessary fluff. The inclusion of a 'Parameters' section is somewhat redundant with the schema, but it is brief and helps reinforce the example. Overall, every sentence contributes value, earning a 4.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the main usage aspects: what it does, how to find command IDs, and includes examples. However, it lacks information about the tool's return value or output (whether it returns anything after executing the command), and it does not discuss potential failure modes or side effects. Given the tool's complexity and lack of an output schema, these gaps make it incomplete for an agent to fully understand the tool's behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already describes the `id` parameter with 100% coverage, providing a baseline of 3. The description adds meaningful context beyond the schema: it introduces the concept of a 'canonical command ID', gives concrete examples (e.g., 'editor:toggle-bold'), and explains how to discover valid IDs using the `obsidian` tool's `commands` verb. This enriches the parameter semantics substantially.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific, action-oriented statement: 'Execute an Obsidian command by its canonical command ID.' It clearly identifies the resource (Obsidian commands) and the operation (execute), and distinguishes itself from sibling tools like obsidian_read or obsidian_search by focusing on command execution. Examples of command IDs further solidify the purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context on when to use the tool: to trigger any core or plugin command exactly as from the command palette. It also explicitly directs users to the generic `obsidian` tool with the `commands` verb for discovering IDs, which is an effective alternative. However, it does not explicitly state when not to use it or mention other alternatives, which is a minor gap.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of disclosing behavior. It clearly states that Templater placeholders are NOT expanded and routes to the alternative tool. However, it does not mention behavior on file conflicts (e.g., overwrite) or how name and path interact when both are provided, leaving some behavioral ambiguity.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: purpose, key caveat, parameter list, and examples. It is efficient, but the parameter list partially duplicates information already in the schema. The examples earn their place, and there is no superfluous fluff, but a tighter version could omit the redundant parameter details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simplicity of a create tool, the description covers the essential nuance (no placeholder expansion), provides examples, and names the alternative. It does not explain conflict handling or return values, but no output schema exists and the behavior is relatively straightforward. The description is nearly complete for an agent to use correctly, with minor gaps when both name and path are supplied.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description enriches this by adding 'optional' to each parameter and specifying 'vault-relative path' for path, which is more precise than the schema's 'File path'. The examples also demonstrate typical usage, providing practical semantic context beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Create a new PLAIN note (no Templater expansion)', giving a specific verb and resource. It distinguishes itself from the sibling tool obsidian_create_from_template by explicitly naming the alternative for templater placeholders. This clearly differentiates it from other note-related tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly advises 'if your template contains placeholders, use obsidian_create_from_template instead'. This directly specifies when to use this tool versus the alternative. The word 'PLAIN' further implies using this when literal content is intended, providing clear context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 explains the key behavior of expanding Templater placeholders and mentions the underlying CLI verb. However, it does not disclose potential edge cases like whether existing files are overwritten, what happens if the template path is invalid, or if parent directories are auto-created. Some behavioral context is added, but not exhaustive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: opening purpose sentence, a brief explanation of when to use it, a parameters section, and examples. Every sentence contributes useful information, and the structure makes it easy to scan. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter tool with high schema coverage and no output schema, the description fully covers usage context: what it does, when to use it, why it exists (placeholder expansion), differentiation from an alternative, and concrete invocations. The agent has enough context to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with both parameters described in the schema. The description repeats the parameter definitions and adds concrete examples (e.g., 'Templates/daily.md'). The examples are illustrative but do not add substantial semantic meaning beyond what the schema already provides. Baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Create a new note from a Templater template, expanding placeholders.' It explicitly distinguishes this tool from sibling `obsidian_create` by stating that plain notes without placeholder expansion should use `obsidian_create`. This fully differentiates it from nearby tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit guidance: 'Use this whenever the template contains Templater placeholders such as `<% tp.date.now() %>`...' and then names the alternative for plain notes: 'For plain notes with no placeholder expansion, use `obsidian_create`.' This is clear when-to-use and when-not-to-use guidance with a specific alternative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description mentions appending 'at the end of today's daily note' and shows markdown content, providing some behavioral context. However, with no annotations, it doesn't disclose whether the note is created if missing, whether it adds newlines, or what happens on failure. The main action is clear, but edge-case behavior is undisclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is highly concise: a one-sentence purpose, a clean parameter list, and two illustrative examples. No redundant information, well-structured, and front-loaded with the core action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter tool, the description covers the essential purpose, parameter meaning, and usage through examples. It lacks edge-case information (e.g., missing note behavior) and return value, but these are non-critical for a simple append operation. Overall, it's adequately complete for the simplicity level.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already describes the parameter as 'Content to append' (100% coverage), but the description adds 'markdown text' and shows examples with formatting. This enriches the parameter semantics beyond the schema, clarifying expected content type and usage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states 'Append content to today's daily note' with a specific verb ('append') and resource ('today's daily note'), clearly distinguishing it from sibling tools like obsidian_daily_read or obsidian_create. The purpose is unambiguous and precise.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied through the verb 'append' and examples, but there is no explicit guidance about when to use this tool vs alternatives (e.g., obsidian_create for new notes) or what happens if the daily note doesn't exist. The examples show use cases, but no when-not-to-use or alternative references.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 the return format and example, but doesn't state whether the tool is read-only, whether it creates a note if missing, or what happens if no daily note is configured. It's minimally adequate but lacks explicit behavioral details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise at two sentences, with no wasted words. The first sentence states the action, the second gives the return format and a use case. The structure is efficient and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple zero-parameter tool with no output schema, the description covers the result format, provides an example, and explains a common use case. It could mention timezone configuration or whether the note path exists, but these are not essential for a path-construction helper, making this sufficiently complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the description doesn't need to explain parameters. The baseline for 0-param tools is 4, and the description adds meaning by explaining the output and use case, which is more than just repeating the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: getting the file path of today's daily note, with a concrete example. The verb 'Get' and the resource 'file path' are specific, and the tool is distinct from siblings like obsidian_daily_read and obsidian_daily_append, which operate on content rather than just paths.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description indicates the tool is useful for constructing paths for other tools, giving a clear context for when to use it. It doesn't explicitly exclude alternatives, but the use case is sufficiently defined. It doesn't name alternatives, so it doesn't fully reach the level of 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full responsibility. It discloses that the tool returns the full markdown content and importantly, returns an error if no daily note exists, clarifying that it does not create a note. This is useful behavioral context, though it does not mention read-only side effects or permissions, which are less critical for a read operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no verbose language. The first sentence states the action, the second clarifies output and error behavior. Perfectly front-loaded and concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter read tool, the description sufficiently covers the return value (full markdown content) and the error condition. No output schema is present, but the description explicitly explains what is returned. It could elaborate on the daily note naming convention, but that is likely domain knowledge and not necessary for a minimal viable description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the schema coverage is 100%. With no parameters, the baseline is 4, and the description adds no extra parameter meaning needed. It implicitly clarifies that no arguments are required.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool reads today's daily note contents, using a specific verb ('read') and resource ('today's daily note'). This distinguishes it from siblings like obsidian_daily_path (which likely returns a path) and obsidian_read (which likely reads arbitrary notes).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the usage context: use it when you need the contents of today's daily note. However, it does not explicitly mention alternatives or when not to use it, so the guidance remains implicit rather than explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It explicitly warns that the operation is DESTRUCTIVE, explains the default trash behavior (recoverable), and clearly states that permanent deletes are irreversible. This is exemplary transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-organized with a clear purpose statement, destructive warning, parameter list, and examples. It is slightly longer than necessary due to duplicating schema details, but every sentence adds value and the structure is easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a delete tool with three parameters and no output schema, the description covers the essential usage, safety implications, and parameter semantics. It is complete enough for an agent to invoke correctly without additional context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already covers all three parameters, but the description adds meaning by explaining the mutual exclusivity of file/path, providing examples, and clarifying the irreversible nature of permanent. This exceeds the schema baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool deletes a note, with specific selection methods (file name or exact path). It distinguishes from sibling tools like create, move, and rename by focusing solely on deletion.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use the tool (to delete notes) and the key requirement that one of file or path is needed. It does not explicitly name alternative tools or exclusions, but the purpose is unambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. The action 'List' implies a non-destructive read operation, but the description does not disclose whether the listing is recursive, the output format, or any pagination behavior. It is minimally transparent but lacks deeper behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: a one-sentence purpose, a parameter list, and examples. It is concise with no redundant information, and the most important information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple list tool with two optional parameters, it covers the purpose and parameters well. However, it omits return value details and does not mention whether folder filtering is recursive. The lack of an output schema increases the need to describe the return format, which is absent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already describes both parameters (folder, ext) with 100% coverage. The description adds value by clarifying the extension format with examples ('md', 'canvas') and showing usage through examples, which helps the agent know how to pass the parameters. This goes beyond the schema's bare descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'List' with a clear resource ('files in the vault or a specific folder'). It clearly distinguishes from siblings like obsidian_read (read a file) and obsidian_search (search content), making the tool's purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It clearly states when to use the tool ('List files in the vault or a specific folder') and provides examples with optional filters. It does not explicitly mention alternatives or exclusions, but the context is clear enough for an agent to know it's for enumeration, not content search.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden and does an excellent job. It discloses exact behaviors for each input case: no topic returns a group verb index, verb name returns description and flags, doc slug returns reference prompt, and a collision rule is documented. This goes far beyond a typical tool description and covers edge cases, making it highly transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and appropriately sized. It front-loads the core purpose, then uses compact sections for Parameters and Behavior, and closes with practical examples. Every sentence contributes information; there is no redundancy or filler, making it both concise and easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having no output schema and only one optional parameter, the tool has multiple modes and a nontrivial collision rule. The description fully covers all behaviors, provides examples for each mode, and explains the edge case with reserved doc slugs. It is complete enough for an agent to select and invoke the tool correctly in any scenario.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% (the 'topic' property is described as 'Verb name or reference-doc slug'), so baseline is 3. The description adds significant extra meaning: it explains that topic can be either a verb or slug, lists the reserved doc slugs, and clarifies collision handling. This enriches the parameter semantics beyond the schema, justifying a 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb+resource: 'Get Obsidian help: a live verb index from the CLI, or reference docs by slug.' This clearly distinguishes the tool from sibling tools like obsidian_read or obsidian_command, as it is the meta/help tool. The two modes (verb index vs. reference docs) are explicitly named.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly implies when to use the tool (browse verbs, get help on a verb, or fetch a reference doc) but does not explicitly contrast it with alternatives. It states no-arg usage for browsing and gives examples, but lacks an explicit 'use this instead of X' statement. Context is clear, exclusions are absent—hence a 4 rather than a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains that the tool returns version history (snapshots/sync revisions) and clarifies it is not a list of recent modifications. It also discloses the selection behavior (file or path). However, it does not describe what happens if both parameters are provided or if neither is provided, nor does it mention any error handling or permission requirements. These are minor omissions for a read-only listing tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and appropriately sized. It opens with a clear one-sentence summary, followed by a brief explanatory paragraph, then lists parameters with concise descriptions, and ends with practical examples. Every sentence adds useful information without redundancy. The format is front-loaded and easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (2 parameters, no output schema), the description is largely complete. It explains the tool's purpose, what it returns, how to select the note, and provides examples. The main gap is that it does not describe the structure or content of the returned version history (e.g., timestamps, list of versions), but it does give a high-level indication ('snapshots/sync revisions'). The distinction from recently-modified notes is crucial and well addressed. Overall, it is sufficiently complete for an agent to use correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with both parameters having descriptions, so the baseline is 3. The description adds value beyond the schema by explicitly stating the requirement that one of file or path must be provided, clarifying that they are mutually exclusive options. It also provides illustrative examples showing exact usage, which help disambiguate parameter format beyond the schema's brief descriptors.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool 'List the saved file-history versions of a note' with specific verb and resource. It distinguishes itself from sibling tools by explicitly noting it is 'not a list of recently-modified notes', which separates it from obsidian_recents. The scope (single note selected by file or path) is well defined.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides usage context by stating what the tool does (returns version history) and what it does not do (recently-modified notes), implying when to use it over alternatives like obsidian_recents. It also gives explicit usage constraints: 'Provide one of file or path to select the note' and notes that one is required. However, it does not explicitly name alternative tools or provide 'when-to-use vs. when-not-to-use' guidance beyond the contrast.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose behavior. It covers key behaviors: moving vs renaming, selection by file or path, and the requirement that one of file/path be provided. However, it does not disclose overwrite behavior or return values.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a concise summary, parameter explanations, and examples. It is appropriately sized for the tool's complexity, though the 'One of file or path is required' line is slightly redundant with the parameter descriptions.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has no output schema and no annotations, so the description is the primary source of context. It covers purpose, parameters, and examples, but lacks information about return values, error conditions, or overwrite behavior. For a file-moving tool, this is a moderate gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema provides full descriptions for all 3 parameters, giving baseline coverage. The description adds clarity on how to choose between file and path, and what the 'to' parameter represents, including the renaming case. This exceeds the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states 'Move or rename a note, selecting it by file name or exact path.' This is a specific verb with a clear resource and scope. It distinguishes from other tools by specifying the selection method, though it does not explicitly differentiate from the sibling obsidian_rename.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains how to invoke the tool and gives examples, but it does not provide guidance on when to use this tool versus alternatives like obsidian_rename. It implies usage through examples but lacks explicit exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Since no annotations are provided, the description carries the full burden of behavioral disclosure. It explains that wraps 'the CLI's outline Verb,' describes the selection methods, and notes that 'total' returns a count. However, it does not cover edge cases like missing notes, conflict resolution when both file and path are provided, or error behavior. For a read operation, the transparency 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: it opens with a clear purpose, then a brief note about the CLI wrapper, followed by a parameter summary, and ends with three illustrative examples. The parameter list is somewhat redundant with the schema, but it includes a key requirement (one of file/path) and the examples are concise and helpful. No unnecessary fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the moderate complexity and absence of an output schema, the description does a good job of conveying expected outputs: it mentions the outline format choices (tree, md, json) and the total count variant. It also addresses the selection ambiguity with a required either/or note. It lacks details on error behavior, but for a read-only outline tool, the essential context is present.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already has 100% description coverage for all four parameters, so the baseline is 3. The description adds value beyond the schema by explicitly stating that one of file or path is required, clarifying the format options ('tree', 'md', 'json') with a default, and providing concrete examples. This additional guidance justifies a score above baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'List the heading outline of a note, selecting it by file name or exact path.' It uses a specific verb and resource, and the selection criteria (file name or path) distinguishes it from sibling tools like obsidian_read (full content) and obsidian_tags (tags).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use this tool: to get a heading outline of a single note. It also specifies the usage requirement that 'One of file or path is required' and explains the optional parameters (format, total). It does not explicitly contrast with alternatives, but the unique purpose and selection methods imply appropriate usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 empty args list all properties with counts, and that name requires file/path. It explains 'file' is for wikilink resolution, adding context beyond the schema. It does not mention error cases or return format, but for a read-only tool this is sufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is efficiently structured: a one-line summary, compact parameter explanations, and concrete examples. No wasted words; every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple, but the description covers the main behaviors (list all, read one) and parameter interactions. Without an output schema, it doesn't detail the return structure, but the examples imply the shape. Adequate for an agent to invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds substantial meaning beyond the schema: it distinguishes 'file' (wikilink resolution) from 'path' (exact path), and clarifies the dependency for 'name'. Examples demonstrate valid parameter combinations, making the usage highly actionable.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'List or read frontmatter properties.' This clearly distinguishes it from siblings like obsidian_property_set (which mutates) and obsidian_tags. The two modes (list all vs. read one) are explicitly described with examples.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context for when to use the tool: to list all properties or read a specific one. It does not explicitly name alternatives, but the parameter descriptions and examples imply the boundaries (e.g., use obsidian_property_set for changes). The dependency 'name requires file or path' provides usage guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It explains critical behavior: without type="list", multi-valued values are written as scalar strings, comma-separated values are not split, and bracketed wikilinks are never split. It also clarifies the JSON-array requirement, but does not mention overwrite semantics or auth requirements, so it is not fully comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: a one-sentence purpose, a clean parameter list, a focused note on multi-valued behavior, and examples. Every section earns its place and the front-loaded opening gives immediate clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having no output schema, the description covers all parameter semantics, addresses edge cases (wikilinks, list splitting), and provides examples. It is fully sufficient for an agent to invoke the tool correctly in most scenarios.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds significant meaning: it clarifies the relationship between type and value, specifies that one of file/path is required (an extra constraint beyond schema), and provides three concrete examples showing correct usage for both scalar and list properties.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Set a frontmatter property on a note', using a specific verb and resource. It clearly distinguishes itself from sibling tools like obsidian_properties or obsidian_read by focusing on writing/updating a property.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use the tool (setting a property) and detailed guidance on file/path resolution and multi-valued properties. However, it does not explicitly mention alternatives or when not to use it, so it lacks explicit exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 clearly conveys that the tool is a read operation, and the parameter constraints are disclosed. However, it does not mention the return format, error handling (e.g., note not found), or explicitly confirm non-mutating behavior, leaving some room for inference.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured: a one-line purpose, parameter details, and two examples. Every sentence adds value with no redundancy. The use of headings and examples improves readability for an agent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read tool with two optional-but-one-required parameters, the description fully covers how to invoke it. There is no output schema, so the return value is not explicitly described, but the read operation's purpose implies the note content. Minor edge cases like both parameters being provided are not addressed, which is a small gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already describes both parameters (100% coverage), but the description adds essential meaning by explaining 'wikilink resolution', 'vault-relative path', and the constraint that one of the two is required. Examples further clarify usage beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states 'Read a note by file name (wikilink-style) or exact path.' This is a specific verb+resource combination that clearly distinguishes it from sibling tools like obsidian_search or obsidian_daily_read, which have different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly explains the two mutually exclusive parameters (file vs path) and states that exactly one is required, with examples. It does not explicitly mention alternative sibling tools, but the context of when to use each parameter is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden of explaining behavior. It discloses that the tool returns files ordered by last access time and scoped to the vault, which implies a read-only operation. It does not specify maximum count or return format, but for a zero-parameter list tool this is adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the primary action ('List recently opened files') and adds a concise clarification about ordering. Every word contributes, with no redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with no parameters and no output schema, the description provides the essential return information: a list of recently opened files in the vault, ordered by last access time. It lacks an explicit limit on the number of items returned, but this is a minor gap given the tool's simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has no parameters, so the description cannot add parameter-level semantics beyond the schema. The baseline for zero-parameter tools is 4, and the description appropriately focuses on the resource and output rather than parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with a specific verb ('List') and resource ('recently opened files' in the vault), and specifies the ordering by last access time. This sufficiently distinguishes it from sibling tools like obsidian_files (list all files) and obsidian_read (read a specific file).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for retrieving recently opened files but offers no explicit guidance on when to use this tool versus alternatives like obsidian_history or obsidian_files. It provides clear context but no exclusions or comparison with sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the transparency burden. It discloses that renaming only changes the name within the same folder and provides examples, but it does not cover edge cases such as overwriting existing notes or how the rename affects backlinks or references.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a clear summary, a list of parameters, and two practical examples. Every sentence contributes meaningful information, and there is no redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that there is no output schema and no annotations, the description covers all essential aspects: selection mechanisms, required parameter, same-folder behavior, and an explicit alternative tool. This is sufficient for an agent to invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

While the schema already covers all three parameters with descriptions, the description adds the crucial constraint that 'one of file or path is required' and clarifies the distinction between wikilink resolution and exact paths. The concrete examples further enhance parameter understanding beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence 'Rename a note, selecting it by file name or exact path' clearly states the action and resource. It also distinguishes itself from sibling obsidian_move by explicitly noting that renaming only changes the name within the same folder, which is a key differentiator.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use this tool versus obsidian_move: 'use obsidian_move to relocate a note to a different folder.' It also specifies the selection criteria and the required constraint that one of file or path must be provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose behavior; it does by explaining search behavior (full-text, line context) and the limit parameter ('max number of files to return'). This implies a read-only operation and gives the agent expectations about output scale. It doesn't detail the exact response structure, but the low-risk nature makes this sufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is tight and well-organized: one purpose line, a short parameter list, and two examples. No redundant content; every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple three-parameter search tool, the description covers the key aspects: what it does, how to invoke it, and example usage. It lacks an explicit return schema, but the phrase 'line context' and 'files to return' gives enough for an agent to predict the output. Overall, it's complete for its complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already describes all three parameters, but the tool description adds essential semantics: query 'supports Obsidian query syntax' and path 'restrict results to a folder path' clarifies the schema's terse 'Limit to folder.' Including worked examples also demonstrates usage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Full-text search across the vault with line context,' clearly stating the tool's verb (search), resource (vault), and a distinguishing detail (line context). This sets it apart from other Obsidian read tools like obsidian_read or obsidian_files.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context: this is the full-text search tool, so it's obvious when to use it. Examples show typical invocations. It doesn't explicitly name alternatives or exclusions, but the purpose is unambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses that the tool returns structured JSON content (array of { tag, count }) alongside a text form, which is a meaningful behavioral detail given the lack of annotations. It also mentions the default sorting behavior. However, it does not clarify the semantics of counts (e.g., number of notes vs occurrences) or explicitly state that it is read-only, leaving some behavioral ambiguity.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is tightly written with no wasted words: a one-sentence purpose, a brief note on the output structure, and a clearly formatted parameters/examples section. The most important information appears first.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one optional parameter, no output schema), the description covers the essential aspects: purpose, output format, sorting behavior, and examples. It leaves a few minor details unstated (exact text representation, count semantics), but these do not hinder understanding for the typical use case.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already describes the sort parameter with an enum and a single-line description. The tool description adds the default value ('name') and provides two concrete examples (obsidian_tags({}) and obsidian_tags({ sort: "count" })), enriching the parameter documentation beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description begins with 'List tags in the vault with counts,' which clearly identifies the action (list), the resource (tags in the vault), and the distinguishing feature (counts). This sets it apart from sibling tools like obsidian_properties, which lists properties, and obsidian_search, which searches content.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is for retrieving tag counts, but it does not explicitly state when to use it over alternatives, nor does it provide any exclusions or prerequisites. It lacks guidance such as 'for a plain listing without counts, use obsidian_search instead,' making the usage context inferred rather than stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full responsibility for disclosing behavior. It explicitly explains that the tool returns structured JSON (array of task objects with status, text, file, line) alongside a text form, which goes beyond a simple 'list' statement. This gives clients confidence in the return format, though it does not cover potential edge cases like empty results or 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a clear one-sentence purpose, a brief note on return format, a concise parameter list, and illustrative examples. Every section earns its place; there is no fluff or redundancy, making it easy for an agent to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite lacking an output schema, the description explicitly defines the return structure and includes examples. It covers the tool's purpose, all optional parameters, and the JSON/text dual format. It does not mention default behavior when no filters are applied or what happens with no matching tasks, but for a simple listing tool this is sufficient. The inclusion of examples greatly aids completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already provides descriptions for all four parameters (100% coverage). The description restates these with slightly more context (e.g., 'today's daily note tasks') and adds examples showing how to combine parameters. This adds marginal value over the schema, aligning with the baseline for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with the specific action 'List tasks from vault notes', clearly identifying the resource (vault notes) and the operation (listing tasks). It also notes the structured JSON output, which distinguishes it from sibling tools like obsidian_search or obsidian_read. This is a clear, non-tautological purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides examples and filter parameters (daily, todo, done, path) that imply typical use cases, but it does not explicitly state when to use this tool over alternatives or mention any exclusions. The usage context is evident from the name and examples, but not explicitly contrasted with siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the behavioral disclosure burden. It states the output ('Returns the raw template text'), explains the `resolve` variable-expansion behavior, and notes the `title` role. It does not explicitly mention side-effect safety or edge cases, but the read-oriented wording and return-value detail provide solid transparency for this simple operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and front-loaded: a clear one-sentence purpose, a brief behavioral explanation, a parameter summary, and two illustrative examples. Every sentence contributes meaningful information without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, so the description must convey return behavior. It does so ('Returns the raw template text'). It also sufficiently explains the parameters and includes examples. Minor omissions such as default values for `resolve`/`title` and error-handling behavior are not critical for a simple read tool, making this fairly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds value beyond the schema by clarifying `name` ('as it appears in the templates folder'), explaining the relationship between `resolve` and `title`, and providing concrete usage examples. This boosts the score above baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Read the content of a template by name from the vault's templates folder.' This clearly differentiates it from sibling tools like obsidian_read (notes) and obsidian_daily_read (daily notes), and it references the CLI verb `template:read` for additional precision.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use this tool (reading templates) and explains the optional `resolve`/`title` modes, but it does not explicitly contrast it with alternatives such as obsidian_read or obsidian_create_from_template. The template-specific wording makes the intended use obvious enough.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.