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

No annotations are provided, so the description carries the full behavioral burden and mostly fails it. 'Revision check' gestures at optimistic concurrency but never says what a mismatch does (error? overwrite?), whether the daily note is created if absent, or whether the append is atomic. For a mutation tool with zero annotation coverage this is a notable gap.

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?

One short, front-loaded sentence with no filler; the verb and the distinguishing revision behavior come first. It is efficient, though the terseness is part of why so much is left unsaid.

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?

A three-parameter mutation tool with no annotations, no output schema, and no parameter documentation needs far more than this single clause. The agent cannot tell how to obtain expectedRevision, how date defaults, or what a failed revision check looks like.

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

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

Schema description coverage is 0%, so the description must compensate, but it only vaguely maps to two of three parameters: 'work item or note' hints at content and 'revision check' hints at expectedRevision. The date parameter is never mentioned, and no format, default (today?), or expectedRevision semantics are given.

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 gives a specific verb ('appends') and a specific resource ('the daily note'), plus a distinguishing behavioral detail ('revision check'). It implicitly separates this from the sibling obsidian_append_note (general note) and obsidian_prepend_daily_note, though it never names them.

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?

There is no statement of when to choose this over obsidian_append_note, obsidian_prepend_daily_note, or obsidian_update_note. The 'revision check' phrase hints at a concurrency-sensitive use case but never explains when that matters or what to do about it.

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 phrase 'with revision check' gestures at optimistic-concurrency behavior but never states what happens on a revision mismatch, whether the write is atomic, or what the tool returns; the newline behavior of ensureNewline is likewise 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?

A single front-loaded sentence with no filler; the operation and its main caveat are stated immediately. It is under-specified rather than padded.

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?

With no annotations, no output schema, and 0% parameter documentation, this thin one-liner leaves the agent without enough to invoke the tool confidently — especially around revision-check failure behavior and newline handling.

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

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

Schema description coverage is 0% across 4 parameters, so the description must compensate and largely does not. It hints at 'content' and 'revision check' (expectedRevision) but says nothing about path semantics or the ensureNewline default that governs whether a line break is inserted.

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?

Specific verb (appends) plus resource (note) with the qualifier 'existing', which separates it from obsidian_create_note. The verb also implicitly distinguishes it from the sibling obsidian_prepend_note, though no sibling is named explicitly.

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?

'Existing note' is the only usage constraint offered, and it is not framed as when-to-use guidance. Nothing tells the agent when to choose this over obsidian_update_note, obsidian_prepend_note, or obsidian_create_note.

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 behavioral burden, yet it discloses nothing about what happens when the target path already exists, what the overwrite flag does, whether templating merges or replaces content, or what permissions are needed. It only conveys the baseline fact that this is a write operation, leaving the destructive-adjacent overwrite behavior entirely unexplained.

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

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

A single short, front-loaded sentence with no wasted words, but its brevity reflects under-specification rather than efficient communication given the tool's four parameters and mutation semantics.

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 four-parameter write tool with no annotations, no output schema, and 0% schema description coverage, the description is far too thin. It omits collision/overwrite behavior, template resolution semantics, and any routing guidance among the many sibling note tools.

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

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

Schema description coverage is 0%, so the description must compensate, but it only alludes to one of four parameters ('template'). Path, content, and especially the overwrite flag and its default-false semantics are undocumented anywhere.

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

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

States a specific verb and resource ('Creates a new note') and adds the template capability, so the agent knows this is a creation operation distinct from update/append by the word 'new'. However, it does not explicitly name or contrast with the many sibling note-mutation tools (obsidian_update_note, obsidian_append_note, obsidian_prepend_note).

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

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

No indication of when to use this versus obsidian_update_note, obsidian_append_note, or obsidian_find_notes, and no prerequisites or failure conditions. The only hint is the implicit 'new' in the purpose, which the agent must infer.

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, and it does disclose two real behavioral traits: default destination is the vault trash (a recoverable soft delete) and a revision check guards the operation. However, it omits what happens on a revision mismatch, that permanent deletion is likely irreversible, and 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.

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

A single front-loaded sentence with no padding. The phrasing 'Deletes or moves a note to the vault trash' is slightly muddy since trash-as-destination already implies a move, but it wastes no 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?

A destructive tool with no annotations, no output schema, and 0% schema description coverage needs more than one clause. Missing irreversibility semantics, error behavior on revision mismatch, and confirmation requirements leave the agent under-informed before an irreversible-feeling 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?

Schema description coverage is 0%, so the description must compensate, and it only partly does. 'Revision check' clearly maps to expectedRevision and 'trash' implies the permanent flag's default, but the critical meaning of permanent (bypass the trash / irreversible) and the path format are never explained.

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

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

States a specific verb (deletes) plus resource (note) and adds meaningful scope detail: trash destination and a revision check. The only ambiguity is versus the sibling obsidian_move_note, since 'moves a note to the vault trash' overlaps lexically with a move operation, but the delete framing distinguishes it adequately.

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

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

No when-to-use guidance, no prerequisites, and no mention of alternatives. An agent cannot tell from this text when deletion is appropriate versus obsidian_move_note for relocation or obsidian_update_note for content changes.

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 behavioral burden. It implies a read-only lookup but never states read-only safety, pagination/limit behavior (default 20, cap 100 exists only in schema), or what the response contains, so an agent gets no behavioral disclosure beyond the bare purpose.

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

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

A single front-loaded phrase with no filler and the core criteria surfaced immediately. It is arguably too terse for a five-parameter tool, but nothing is 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 tool with five parameters, a nested object, no required fields, no annotations and no output schema, the description omits how filters combine, default/cap behavior, and return shape. An agent can guess the intent but lacks enough to invoke it confidently in edge cases.

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

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

Schema coverage is 0%, so the description must compensate. It does map loosely onto tag, folder, property and query, but mentions 'title' for which no parameter exists and omits limit entirely, and it never explains the nested property object's name/value pair.

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

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

States a specific verb (discovery/find) and resource (notes), plus the dimensions it can filter on. That distinguishes it reasonably from obsidian_list_files and obsidian_search, though it never names a sibling or clarifies how it differs from obsidian_search_context.

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

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

No when-to-use guidance at all: nothing says whether criteria combine (AND/OR), whether tag/folder/property/query can be mixed, or when to prefer this over obsidian_search or obsidian_get_tag_notes. The phrase 'multi-criteria' implies some combining but leaves the mechanics to inference.

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, and it discloses almost nothing: no result ordering, no handling of unresolved/ambiguous targets, no permission or vault-scope requirements, and no indication of what a result entry looks like. Only the read-only nature is inferable from 'Lists'.

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

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

A single front-loaded sentence with no filler or redundancy. It is efficient, though the extreme brevity is part of why other dimensions are thin.

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 one-parameter read tool with no output schema, the description is the minimum viable: it tells the agent what it returns but not the result shape, path format, or how to disambiguate among the crowded link-related siblings.

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

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

Schema description coverage is 0% for the single required 'path' parameter, so the description must compensate. Saying the path refers to 'a target note' does clarify that the argument identifies the note whose backlinks are wanted, but it omits format details (vault-relative vs. absolute, whether an extension is expected).

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

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

States a specific verb (Lists) and resource (incoming links) plus the scope (a target note). 'Incoming' implicitly distinguishes it from obsidian_get_links, but the description never names or contrasts with the many link-related siblings (get_links, get_orphans, get_unresolved_links, get_deadends), so an agent must infer the boundary.

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 only implied: an agent can infer it should call this to find what links to a note, but there is no explicit when-to-use, no prerequisites, and no routing to the sibling tools that cover outgoing links or orphans.

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 behavioral burden. It discloses the filtering criterion, but omits read-only confirmation (implied by 'Lists'), vault scope, return format, and whether the scan is expensive.

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

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

A single front-loaded sentence with no filler. Every word contributes to the definition.

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 0-parameter query tool, the description states the returned set clearly enough to invoke. However, with no annotations and no output schema, it should indicate return shape and vault scope; those gaps leave it only minimally 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 takes zero parameters, so the rubric baseline is 4. No parameter semantics are needed, and the description adds none.

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?

Uses a specific verb ('Lists') and resource ('notes') plus the exact graph condition 'incoming links but zero outgoing links'. This distinguishes it from graph-analysis siblings like get_orphans (no incoming links) and get_links (outgoing links of a given note), though it does not explicitly name alternatives.

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

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

Provides no when-to-use, when-not-to-use, or alternative-tool guidance. It defines the returned set but never says when an agent should choose this over obsidian_get_orphans or obsidian_get_links.

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, and it does disclose the returned fields (size, timestamp, metadata), which is real behavioral content. But it says nothing about whether the path must exist, error behavior for missing paths or directories, or how 'metadata' relates to note frontmatter — notable gaps for an unannotated 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?

A single front-loaded sentence with zero filler, immediately paired with the concrete returned fields. Nothing in it is redundant.

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 1-param read tool with no annotations and no output schema, the description covers the return fields but omits the path semantics and existence/error behavior, and 'metadata' remains undefined relative to obsidian_get_properties. It is minimally usable but leaves real gaps.

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

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

The single required parameter has 0% schema description coverage and the description never mentions it, so the agent gets no guidance on path format (vault-relative vs absolute, note vs directory, extension requirements). With one undocumented param, this falls below the adequate 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 ('Retrieves ... of a file') and enumerates the returned fields (size, modification timestamp, metadata), so the agent knows what it does. However, 'metadata' is ambiguous and could overlap with the sibling obsidian_get_properties, and the description never distinguishes itself from that sibling.

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?

There is no when-to-use guidance and no alternatives named, even though obsidian_get_properties, obsidian_read_note, and obsidian_list_files are nearby siblings an agent could easily confuse with this one. Usage must be inferred entirely from the name.

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 behavioral burden. It does not disclose the return format (link targets vs display text vs both), whether unresolved links are included, or any ordering/normalization behavior. For a read-only listing tool this leaves meaningful gaps.

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

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

A single front-loaded sentence with no wasted words. Appropriately sized, though it is short to the point of under-covering behavior.

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?

With no annotations, no output schema, and no parameter descriptions, the description is too thin for a tool whose output shape and link-resolution semantics an agent needs to interpret results 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?

With one parameter at 0% schema description coverage, the description must compensate. It adds that 'path' identifies a note (rather than a folder or vault), which is modest value, but says nothing about path format, extension handling, or vault-relative vs absolute expectations.

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

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

States a specific verb ('Lists') and resource ('outgoing internal links'), plus the scope ('within a note'). The word 'outgoing' implicitly separates it from the sibling obsidian_get_backlinks, though that sibling is never 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?

No statement of when to use this vs alternatives such as obsidian_get_backlinks, obsidian_get_unresolved_links, or obsidian_get_deadends. Usage is only weakly implied by 'outgoing' and 'within a note'.

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 never states that this is a read-only, non-destructive operation, nor does it disclose cost/performance characteristics (this aggregates several data sources), depth of backlink/related-note resolution, or what 'budget options' actually control. Only the aggregation scope is conveyed.

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

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

A single, front-loaded sentence with no filler or repetition. It is efficiently sized, though the trailing 'with budget options' clause is too compressed to be actionable.

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

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

For a tool with a nested include object, a numeric cap, no output schema, and no annotations, the description leaves major gaps: it does not clarify the returned payload shape or the semantics of its budget controls. An agent could pass a path, but could not tune or interpret the response confidently.

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

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

Schema description coverage is 0% across three parameters, one of which is a nested object with six boolean flags, so the description must compensate. It names five content types that loosely map to include flags but omits outgoingLinks entirely and never explains the include object structure or what maxRelatedNotes (default 10, max 50) bounds; 'budget options' is unexplained jargon.

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

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

States a specific verb (Retrieves) and resource (note context) and enumerates the aggregate contents (content, frontmatter, headings, backlinks, related notes), which distinguishes it from the narrower obsidian_read_note and obsidian_get_backlinks. It does not explicitly name those siblings, so the differentiation is implicit rather than stated.

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?

There is no when-to-use guidance at all: nothing says to prefer this over obsidian_read_note, obsidian_get_backlinks, or obsidian_search_context, and no conditions or exclusions are given. The phrase 'with budget options' gestures at a use case without explaining it.

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 does not state that this is a read-only operation, whether it scans the whole vault or a subfolder, or whether results are paginated or bounded. It only defines the filter criterion.

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

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

A single efficient sentence with the core concept front-loaded and zero waste. It is appropriately sized, though very short for a discovery tool.

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 with no output schema, the description is minimally adequate, but it omits the scope of the scan and the shape of the returned results, which an agent would benefit from knowing before invoking.

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 takes zero parameters, so there is nothing for the description to document; the baseline of 4 applies.

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

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

States a specific verb ('Discovers') and resource ('orphaned notes') and defines the concept as notes with no internal links. However, it does not differentiate from the conceptually adjacent sibling obsidian_get_deadends (notes with no outgoing links), and 'no internal links' is slightly ambiguous about incoming vs outgoing direction.

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

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

No when-to-use guidance, no exclusions, and no alternatives named. Given close siblings like obsidian_get_deadends and obsidian_get_unresolved_links, an agent gets no help deciding between them.

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 provided, so description carries the burden. It states it's a retrieval (read-only) but doesn't disclose what happens with notes that have no frontmatter, the return format, error behavior for missing paths, or performance/auth needs.

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

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

Single, front-loaded sentence with zero waste. Fully appropriate size for a one-parameter retrieval tool.

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?

Adequate for a simple read tool, but with zero annotation coverage, no output schema, and no param guidance, an agent lacks details on return shape and error handling for missing notes or empty frontmatter.

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

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

Schema coverage is 0% (no description on 'path'), but the baseline for a single path param with an obvious meaning is 3. The description adds nothing about path syntax (vault-relative? extension?), so it doesn't compensate for the schema gap.

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

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

Specific verb (Retrieves) plus precise resource (all frontmatter properties of a note). Distinguished from obsidian_get_property (singular, likely a single property) and obsidian_read_note (full content) by emphasizing 'all frontmatter properties'.

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

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

Usage is implied: use this to get the frontmatter/property metadata of a note. No explicit when-to-use vs alternatives (get_property, read_note), and no exclusions or prerequisites 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?

No annotations are provided, so the description carries the full disclosure burden. 'Retrieves' implies a read-only operation, but the description does not cover behavior when the property is missing, the return format or typing of the value, required permissions, or whether the path is vault-relative. These are meaningful gaps for a retrieval 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 a single, front-loaded sentence with no wasted words. It is appropriately terse for a simple getter, though the extreme brevity contributes to gaps documented in other dimensions.

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

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

Given no annotations, no output schema, and 0% schema description coverage for two required parameters, the description is not complete enough for reliable invocation. It omits path semantics, missing-property behavior, and return value details, which an agent would need for correct use.

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

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

Schema description coverage is 0% and the description adds almost no parameter meaning. It does not explain that 'path' identifies a note or file and 'name' identifies the frontmatter key, nor does it clarify expected formats or edge cases. The agent must infer both required parameters' semantics.

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: 'Retrieves a specific frontmatter property value.' It implicitly distinguishes itself from the plural obsidian_get_properties by saying 'a specific' property, but it does not explicitly name or compare against any sibling tool.

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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as obsidian_get_properties or obsidian_set_property. The description only states what the tool does, leaving the agent to infer appropriate usage contexts.

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 of behavioral disclosure. It only states that notes are retrieved and does not describe matching semantics, tag format, permissions, ordering, or result shape.

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

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

The description is a single front-loaded sentence with no wasted words. It is efficient, though its brevity comes at the cost of missing useful detail.

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

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

Given the absence of annotations, an output schema, and any parameter description, the description is too thin. It omits tag syntax, matching behavior, and any differentiation from overlapping sibling tools.

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

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

Schema description coverage is 0% for the single required 'tag' parameter, and the description adds no format details such as whether the tag should include '#' or support nested tags. It merely restates that a specific tag is used.

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

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

States a specific verb ('Retrieves') and resource ('all notes tagged with a specific tag'), so the purpose is clear. However, it does not differentiate this tool from siblings like obsidian_search or obsidian_find_notes, which could presumably also locate notes by tag.

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?

There is no explicit guidance on when to use this tool versus alternatives such as obsidian_search, obsidian_find_notes, or obsidian_get_tags. Usage is only implied by the tool name and description.

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 behavioral burden, and it gives only one clause. It discloses the return content (tags plus counts) but says nothing about scope (vault-wide vs. folder), cost/performance, or side effects. For a no-annotation tool this is a thin disclosure.

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

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

A single front-loaded sentence with no filler; for a simple zero-parameter query this is exactly the right size and every word (tags, occurrence counts) carries meaning.

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?

With no output schema, the description usefully explains the return value (tags and their counts), which is the key thing an agent needs. The remaining gap is scope/behavioral context, but for a tool this simple the description is largely 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 takes zero parameters, so the baseline is 4; there is nothing for the description to clarify beyond what the empty schema already shows.

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

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

States a specific verb and resource ('Returns all tags') plus the payload shape ('occurrence counts'), so an agent knows this is a tag-enumeration tool rather than a note lookup. It does not explicitly contrast itself with the close sibling obsidian_get_tag_notes, which returns notes for a tag, so it falls short of full sibling differentiation.

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?

There is no when-to-use guidance, no mention of prerequisites (e.g., whether it scans the whole vault), and no named alternative such as obsidian_get_tag_notes. The intended use is only implied by the verb 'Returns'.

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 disclosure burden. 'Lists' implies a read-only operation with no side effects, but the description says nothing about scope (whole vault vs. folder), what the returned entries contain, or whether the output is grouped by source note.

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

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

A single sentence with no filler, and the defining characteristic (broken links pointing nowhere) is front-loaded. Nothing could be trimmed without losing meaning.

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 parameterless read tool this covers the core purpose, but with no output schema the description should say a bit more about what the result looks like (source notes, target text, counts). It is adequate but leaves a gap around return format.

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 takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies.

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

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

States a specific verb (Lists) and a precise resource (broken internal wikilinks pointing to non-existent notes), which is clearly different from sibling link tools like get_links or get_backlinks. It does not, however, explicitly name or contrast itself with those siblings, so the differentiation is inferential rather than stated.

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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives. The agent must infer that this is the tool for dead-link auditing rather than, say, get_deadends or get_links.

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 supplied, so the description carries the full burden. It does disclose the return contents (metadata, file counts, connectivity status), which implies a read-only probe, but it never states explicitly that it is non-mutating, nor does it cover auth requirements or any failure modes.

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

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

A single front-loaded sentence with zero padding. Every clause names a distinct thing the caller gets back, so nothing is 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?

With no output schema and no annotations, the description is the only source of return information, and 'vault metadata' stays vague about what fields come back. For a trivial no-arg tool it is close to sufficient, but it leaves the response shape underspecified.

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 takes zero parameters, so there is no parameter semantics to convey and the baseline of 4 applies. The description correctly adds no argument detail because none exists.

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 gives a specific verb (returns) and resource (vault) plus the concrete payload: metadata, file counts, connectivity status. It is clearly distinct from file-level siblings like obsidian_list_files and obsidian_get_file_info, but it never names or contrasts with an alternative, so it stops short of a 5.

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?

There is no when-to-use guidance at all: nothing says whether to call this first to verify connectivity, when to prefer it over obsidian_list_files, or what preconditions apply. The agent must infer intent purely from the tool name.

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 states the scope ('all ... in the vault'), which hints at no filtering, but omits whether the operation is read-only, what permissions are required, and what the return format looks like.

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

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

A single, front-loaded sentence that contains no filler or redundancy. It is appropriately sized for a simple listing tool and immediately states the core action and scope.

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 with no output schema, the description adequately conveys what is listed and the scope. However, it does not describe the return value (e.g., file paths, names, or metadata), which would be helpful since no output schema exists to define it.

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 accepts zero parameters, so there is no parameter semantics to convey. Per the rubric, zero parameters establish a baseline score of 4, and the description adds nothing that would contradict this.

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 ('Lists') and resource ('.base database schema files'), clearly identifying the file type and vault-wide scope. It distinguishes itself from generic listing tools by naming the '.base' extension, but does not explicitly contrast with the sibling obsidian_list_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?

No when-to-use guidance, prerequisites, or alternative tools are mentioned. The description merely states what the tool does; an agent must infer that it is used to discover base files, and there is no mention of when not to use it versus obsidian_list_files or obsidian_query_base.

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 of behavioral disclosure. It does not state that this is a read-only operation, whether the default (recursive=false) only returns one level, whether results are sorted, or whether large folders are paginated.

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

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

A single efficient sentence with the key resource front-loaded and no filler. It is appropriately sized for a simple listing tool, though it is arguably under-specified rather than 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?

With no annotations and no output schema, the description should explain return shape, the meaning of recursive, and whether the operation is safe/read-only. None of that is present, leaving the agent guessing about core behavior.

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

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

Schema description coverage is 0% for two parameters. The description implies the folder argument but never explains it (absolute vs. relative path, vault root behavior), and it completely omits the recursive flag, which materially changes the result set.

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

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

States a specific verb (lists) and resource (files and subdirectories under a vault folder), which is clear. However, it does not distinguish itself from adjacent siblings like obsidian_find_notes or obsidian_search, which an agent might reasonably consider for the same discovery need.

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

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

No guidance on when to use this versus obsidian_find_notes, obsidian_search, or obsidian_get_file_info. There is no mention of prerequisites, default behavior, or context for choosing a plain directory listing over a 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?

No annotations are provided, so the description carries the full burden. 'Lists' implies a read-only operation, but nothing states pagination, result limits, permissions, or output shape for what could be a large vault-wide scan.

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

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

A single tight sentence with the scope qualifier front-loaded and zero filler. Brevity comes at some cost to completeness but nothing is 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 2-param read tool with no output schema and no annotations, the description covers the conceptual meaning of both parameters but leaves behavioral gaps (defaults, result size, ordering) that neither annotations nor schema fill in.

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

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

Schema description coverage is 0%, so the description must compensate. It does map meaningfully onto both params: 'pending or completed' corresponds to the status enum and 'vault-wide or in a note' corresponds to path. However it doesn't state that status defaults to 'all' or that omitting path scans the whole vault.

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

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

States a specific verb (Lists) and resource (tasks) plus the two scoping modes (vault-wide or in a note), which separates it from the mutation sibling obsidian_toggle_task. It does not explicitly name an alternative tool, so it stops short of 5.

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

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

The phrase 'vault-wide or in a note' hints at the two operating modes but gives no explicit when-to-use guidance, no exclusions, and never mentions obsidian_toggle_task or obsidian_search as alternatives. The agent must infer usage entirely.

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. The phrase 'with revision check' hints at optimistic concurrency, which is valuable, but it does not explain what happens on a revision mismatch, whether an existing target is overwritten, or what permissions are required for a mutation.

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

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

A single front-loaded clause with zero filler. It is efficient, though arguably terse given the amount of missing behavioral context.

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 mutation tool with no annotations, no output schema, and 0% schema description coverage, the description leaves critical gaps: conflict handling, target-overwrite semantics, and permission requirements are all 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?

Schema coverage is 0%, so the description must compensate. 'Moves or renames' maps to sourcePath/targetPath and 'revision check' maps to expectedRevision, giving each of the 3 params a rough role, but no format or validation details are provided and the required/optional distinction is unstated.

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 pair (moves/renames) and resource (a note) scoped to the vault, and adds a behavioral detail (revision check). It is clearly distinguishable from create/update/delete siblings, though it does not explicitly name which sibling to prefer.

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?

There is no guidance on when to use this over obsidian_update_note (which could also alter a note) or when a move/rename is appropriate. No prerequisites or conditions are 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?

No annotations, so the description carries the full behavioral burden. 'With revision check' is a useful hint at optimistic concurrency, but it never says what happens on a revision mismatch (error? overwrite? no-op?), whether the note is created if missing, or what permissions are needed for a write 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?

A single compact sentence with the verb and resource front-loaded and no wasted words. Brevity comes at the cost of substance, but nothing is padded.

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 mutation tool with no annotations, no output schema, and zero schema description coverage, far too little is specified. An agent cannot tell where in the note text lands, whether the daily note is auto-created, or how the revision check affects retries.

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

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

Schema description coverage is 0% and the description is silent on all three parameters. 'Daily note' weakly implies the date parameter, and 'revision check' gestures at expectedRevision, but neither the date format nor the meaning/source of the revision string is explained beyond what the schema's pattern already shows.

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?

Specific verb (prepends) plus resource (the daily note), which distinguishes it from obsidian_append_daily_note and obsidian_prepend_note. It does not explicitly say it targets the date-stamped daily note versus a named note, but the resource is clear enough to route by name.

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

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

No guidance on when to choose this over obsidian_append_daily_note, obsidian_prepend_note, or obsidian_update_note. The only contextual cue is the word 'daily', leaving the append-vs-prepend-vs-update decision to inference.

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 usefully discloses the 'revision check' behavior, signalling a concurrency/optimistic-locking concern, which is real value beyond structured fields. However it does not say what happens on a revision mismatch, whether the write is atomic, or what permissions are needed, so the mutation's failure semantics remain opaque.

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

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

A single, front-loaded sentence with no filler; the most important fact (prepend, below frontmatter, existing note) comes first and the qualifier (revision check) trails it.

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 3-parameter mutation tool with no annotations and no output schema, the description covers the operation and the revision guard but omits error behavior on revision mismatch, return value, and any frontmatter-preservation caveats. Adequate but with clear gaps.

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

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

Schema description coverage is 0%, so the description must compensate. It loosely maps all three parameters ('text content', 'existing note', 'revision check'), which is better than nothing, but it gives no format for expectedRevision (hash? integer?) or any content constraints such as frontmatter handling or newline insertion, so the gap is only partially closed.

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 gives a specific verb (prepends), resource (note), and a precise insertion point ('below frontmatter'), which distinguishes it from the sibling obsidian_append_note purely by the verb semantics. It does not explicitly name append_note as the counterpart, but the verb pair is self-evident to an agent reading the sibling list.

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?

There is no statement of when to use prepend versus append_note, update_note, or create_note, and no prerequisites are given. The only implied constraint is 'existing note', which rules out creation but leaves the choice among the four writing tools to inference.

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 of behavioral disclosure, yet it says nothing about read-only semantics, required permissions, pagination, or output shape. "Queries" weakly implies a read operation, which is the only behavioral signal present.

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 single sentence is short, but it is under-specified rather than concise — it spends its few words without conveying the information an agent needs, so brevity does not earn its place here.

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?

With no annotations, no output schema, and 0% parameter description coverage, the description leaves the agent without enough information to invoke the tool correctly. A two-parameter query tool needs at least an explanation of path and view semantics.

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

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

Schema description coverage is 0% and both parameters (path, view) are undocumented in the schema. The description only faintly gestures at them via ".base" and "view", adding essentially no meaning about formats, defaults, or what the view string selects.

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 names a verb ("Queries") and a resource ("a .base database view"), so it is more than a tautology, but it never explains what a .base view is, what a query returns, or how it differs from the sibling obsidian_list_bases. An agent gets a rough idea but cannot confidently distinguish it from adjacent 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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as obsidian_list_bases or obsidian_read_note. The agent must infer usage entirely from the tool name.

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 behavioral burden. It implies a read-only operation but never states what happens if the daily note for the requested date does not exist, whether a note is created, or what the returned content looks like.

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

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

A single short sentence with the key temporal distinction front-loaded and no filler. It is efficient, though so terse that it leaves real gaps rather than being optimally sized.

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 one-parameter read tool with no annotations and no output schema, the description is minimally adequate. It omits the missing-note behavior and the distinction from the generic read_note sibling, which are the two things an agent most needs to route 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 description coverage is 0%, so the description must compensate. It does partially: 'today's or a specific date's' conveys that the date parameter is optional and defaults to today, which the schema does not say in prose. However, it adds no format guidance (the YYYY-MM-DD constraint lives only in the schema pattern) and no timezone semantics.

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

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

States a specific verb (reads) and a specific resource (daily note), and clarifies the temporal scope ('today's or a specific date's'). It does not, however, differentiate itself from the sibling obsidian_read_note, which also reads notes; an agent must infer that this one auto-resolves the daily-note path.

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

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

Usage is implied by the 'daily note' framing, but there is no explicit when-to-use guidance, no mention of when to prefer this over obsidian_read_note, and no mention of the related obsidian_append_daily_note/obsidian_prepend_daily_note 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 full burden. It usefully discloses that both content and frontmatter are returned, but says nothing about error behavior for a missing path, permission/vault-connection prerequisites, or whether the read is path-scoped. For a no-annotation tool this is a notable gap.

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

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

A single well-formed sentence with the verb and resource front-loaded and no filler. It is appropriately sized, though its brevity is partly the cause of the missing usage and parameter detail.

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 one-parameter read tool with no output schema, revealing that content and frontmatter are returned is close to sufficient. Still missing are path format/semantics and behavior on a nonexistent note, which an agent would need before invoking.

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

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

Schema description coverage is 0% and the single 'path' parameter has no description in either place. The description never clarifies whether the path is vault-relative, absolute, includes the .md extension, or may use folder separators — the one detail an agent most needs to call this correctly.

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

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

States a specific verb (Reads) and resource (vault note) and even names the returned parts (full content and frontmatter), which distinguishes it from metadata tools like obsidian_get_file_info. However, it never explicitly differentiates itself from the closest siblings (obsidian_read_daily_note, obsidian_get_note_context), so it stops short of a 5.

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

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

No statement of when to use this tool versus obsidian_read_daily_note, obsidian_get_note_context, or obsidian_get_file_info. Usage must be inferred purely from the name and the one-line purpose; there are no exclusions or prerequisites.

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 behavioral burden and under-delivers: it implies a read-only listing but never states sort order, default recency window, whether the result is capped, or that it is safe/non-mutating. Only the vague purpose sentence is offered.

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

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

A single efficient sentence with the core purpose front-loaded and no filler. It is concise, though conciseness is partly achieved by omitting necessary detail.

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 three-parameter tool with 0% schema coverage, no annotations, and no output schema, the description is far too thin. An agent cannot know how to filter, cap, or interpret results from this text alone.

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

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

Schema description coverage is 0% and the description mentions none of the three parameters (limit, folder, sinceDays). The agent gets no explanation of what folder scoping does, what the default/limit behavior is, or how sinceDays interacts with the 'recently' claim.

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?

Clear verb ('Lists') plus resource ('notes') and scope ('recently modified or created within the vault'), which hints at a recency-filtered listing. It does not explicitly differentiate itself from siblings like obsidian_search or obsidian_list_files, so an agent must infer the distinction.

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

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

The phrase 'for change awareness' gestures at when it is useful, but there is no explicit when-to-use guidance, no exclusions, and no named alternative (e.g., obsidian_search or obsidian_find_notes) for broader lookups.

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 only that a revision check occurs, but does not state what happens on revision mismatch, whether removal is reversible, whether permissions are required, or what response to expect after a mutation.

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

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

A single, front-loaded sentence with no wasted words. It conveys the core action immediately and adds the revision-check qualifier without unnecessary explanation.

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

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

For a mutation tool with no annotations, no output schema, and 0% parameter coverage, the description is too thin. It omits error behavior, confirmation semantics, reversibility, and any operational context an agent needs before deleting frontmatter data.

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

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

Schema description coverage is 0%, so the description must compensate. 'Note' loosely implies the path parameter and 'frontmatter property' loosely implies the name parameter, but no formats, constraints, or detailed meaning are given. The revision check hints at expectedRevision but remains vague.

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

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

States a specific verb and resource: 'Removes a frontmatter property from a note.' This clearly distinguishes it from sibling tools such as obsidian_set_property and obsidian_get_property. The added 'with revision check' further narrows its behavior.

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

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

Provides no guidance about when to use this tool versus alternatives like obsidian_set_property or obsidian_update_note. There are no prerequisites or exclusions stated, leaving the agent to infer usage from the name alone.

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 shape (file matches with line numbers), which is genuinely useful, but says nothing about read-only safety, case sensitivity, match semantics, or whether the limit caps matches per file or overall.

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

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

A single efficient sentence with the action front-loaded and no filler. It is under-informative rather than bloated, so brevity here is only partly a virtue.

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 read tool with no output schema, the description at least declares the return values, which is the main gap it fills. However, with zero schema description coverage it should also clarify query syntax and limit behavior to be fully actionable.

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

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

Schema description coverage is 0% for both parameters, so the description must compensate and does not. 'query' and 'limit' are never explained — no guidance on syntax, escaping, or what the limit applies to (files vs. lines).

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

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

States a specific verb (search), resource (vault), and method (full-text), plus what is returned (file matches and line numbers). It distinguishes itself reasonably from siblings like obsidian_find_notes or obsidian_search_context, though it never names or contrasts them.

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

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

No when-to-use guidance, no prerequisites, and no mention of alternatives such as obsidian_search_context or obsidian_find_notes, which an agent must choose between. The agent is left to infer the selection criteria.

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 hints at return shape ('contextual lines around matches') but says nothing about read-only semantics, result truncation (limit defaults to 30, max 100), or ordering — all relevant behavior for a search 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?

A single tight sentence with the core action front-loaded and no filler. It is efficient, though so terse that information density is low rather than high.

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?

With no annotations, no output schema, 0% parameter documentation, and several near-duplicate siblings, the definition leaves too much for the agent to infer. A search tool with pagination limits and a context-window parameter needs more than one clause.

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

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

Schema description coverage is 0% and all three parameters (query, limit, contextLines) are undocumented in both schema and description. The phrase 'contextual lines' loosely gestures at contextLines, but the query semantics and the limit/truncation behavior are entirely unexplained.

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

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

States a specific verb and resource ('full-text vault search') plus a distinguishing output trait ('contextual lines around matches'). However, it does nothing to separate itself from the sibling obsidian_search or obsidian_find_notes, which an agent will likely confuse it with.

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

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

No when-to-use guidance and no mention of alternatives, despite three plausible sibling competitors (obsidian_search, obsidian_find_notes, obsidian_get_note_context). The agent must guess which search variant to pick.

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 does disclose two meaningful behavioral traits: that values are typed ('structured types') and that an optimistic-concurrency guard exists ('revision check'). It stops short of saying what happens on a revision mismatch, whether a missing property is created, or how errors/mutation effects surface.

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

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

A single compact sentence that front-loads the core action and appends the two distinguishing features. It is appropriately sized, though it sacrifices completeness for brevity.

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

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

For a 4-parameter mutation tool with no annotations, no output schema, and 0% parameter coverage, the description is thin. It omits revision-mismatch behavior, property-creation semantics, and per-parameter meaning, leaving meaningful gaps an agent would need to call 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 description coverage is 0% across 4 parameters. The description only loosely gestures at parameters via 'structured types' (value) and 'revision check' (expectedRevision), leaving path and name undocumented and giving no format or constraint detail, so it does not compensate for the schema gap.

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

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

The description states a specific verb ('Sets or updates') and resource ('a frontmatter property'), clearly distinguishing it as the write-side counterpart to the get_property/remove_property siblings. However, it does not explicitly name or contrast with those siblings, so differentiation is inferred rather than stated.

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?

There is no explicit when-to-use guidance, no mention of prerequisites, and no reference to alternatives such as remove_property or when to prefer updating a whole note. Usage is only weakly implied by the presence of sibling read/remove property 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?

With no annotations, the description carries the full behavioral burden. It states the operation is a mutation ('Toggles') and mentions 'verification', but does not say what happens when expectedText/expectedRevision mismatch, whether the change is reversible, or what permissions are needed. The verification hint is the only real behavioral disclosure.

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

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

A single efficient sentence with the action front-loaded and no filler. It is well-sized, though the trailing 'with verification' clause is vague rather than informative.

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 4-parameter mutation tool with no annotations, no output schema, and 0% schema coverage, the description is under-specified. It omits the meaning of the verification parameters, failure behavior, and any return information an agent would need to call it confidently.

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

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

Schema description coverage is 0% across 4 parameters. The description implies 'path' (a note) and 'line' but never explains the semantics of expectedText or expectedRevision, nor why 'line' is 1-based. It does not compensate for the total lack of schema documentation.

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 names a specific verb ('Toggles') and resource ('completion checkbox on a specific line of a note'), making the action clear and distinct from siblings like obsidian_update_note or obsidian_list_tasks. It does not explicitly differentiate itself from those siblings, but the toggling action is 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?

There is no guidance on when to use this versus alternatives such as obsidian_update_note or obsidian_list_tasks, nor any statement of prerequisites. 'with verification' hints at a precondition but is never explained as a when-to-use rule.

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 behavioral-disclosure burden. It usefully introduces 'optimistic revision control,' signaling concurrency behavior around expectedRevision, but it does not explain overwrite semantics, whether omitted expectedRevision allows last-write-wins, what permissions are needed, or how conflicts are reported. This is meaningfully better than a bare mutation description but still incomplete for a write 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 definition is a single front-loaded sentence with no filler. It is efficient and every phrase carries some meaning. It could be slightly more informative without becoming bloated, but as written it is appropriately 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 mutation tool with three parameters, no annotations, no parameter descriptions, and no output schema, the description is too thin. It omits critical context such as overwrite behavior, expectedRevision semantics, error handling, and when to choose this tool over append/prepend/create siblings. The agent is left with major unknowns before invoking a destructive write 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?

Schema description coverage is 0%, so the description must explain the parameters. It indirectly covers content and expectedRevision through 'note content' and 'optimistic revision control,' but it does not define expectedRevision's format or behavior, and it says nothing about path. The schema names the parameters, but the description adds little semantic clarity beyond those names.

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

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

The description gives a clear verb and resource: 'Updates note content.' It also names a specific mechanism, 'optimistic revision control,' which helps distinguish it from sibling read operations and append/prepend tools. However, it does not explicitly contrast itself with siblings like obsidian_append_note or obsidian_create_note, so sibling differentiation is left to inference.

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 offers no when-to-use guidance, no prerequisites, and no alternatives. An agent must infer from the tool name and sibling list that this is for replacing note content rather than appending or creating a note. There is no explicit instruction about when this tool is appropriate versus other write tools.

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