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

With no annotations, the description carries the full behavioral burden, yet it omits everything beyond the basic action: whether a newline or separator is inserted, what happens if no note is active, whether the note is created when missing, and what the operation returns. For a mutation tool with zero annotation coverage this is a substantial 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 front-loaded sentence with no filler or repetition. It is efficient, though the brevity edges into under-specification rather than optimal conciseness.

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

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

For a mutation tool with no annotations and no output schema, the description is too thin: it does not describe the return value, error behavior when no note is active, or how appended content is delimited. An agent can guess the basic call but not the 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 description coverage is 100% and the single parameter is fully documented ('Markdown content to append'), so the schema does the heavy lifting. The description adds no format or placement detail beyond what the schema already provides, making 3 the correct 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 (append) and resource (content to the currently active/open note), and the qualifier 'active/open' distinguishes it from the sibling append_to_note, which presumably targets an explicitly named note. The distinction is implied rather than spelled out, keeping it below 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?

It never says when to use this instead of append_to_note, patch_active_note, or update_active_note. The phrase 'currently active/open note' hints at the context, but no alternative is named and no prerequisite (e.g., a note must already be open) is 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 burden, and it discloses only that content lands at the end rather than overwriting. It says nothing about what happens if the note does not exist, whether the write is atomic/reversible, permission requirements, or error behavior for a mutation tool.

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

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

Two short sentences, front-loaded with the core action, no filler, and the embedding hint is a genuinely useful aside rather than padding.

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 low-complexity two-parameter tool with a fully documented schema and no output schema, the description is minimally sufficient. The gap is the absence of any failure-mode or precondition statement, which matters more here because there are no annotations to cover mutation 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 100%, so both parameters are already fully documented in the schema, and the description merely echoes the embedding syntax already present in the 'content' schema description. Baseline 3 is appropriate when the schema does the heavy lifting.

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 ('Append content to the end of an existing note') and the 'existing note' phrasing implies required pre-existence. However, it does nothing to distinguish itself from siblings like append_to_active_note or patch_note, which target a different note source and a different edit style respectively.

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 alternatives named. An agent choosing among append_to_note, append_to_active_note, patch_note, and update_active_note gets no routing signal from the description; it must infer the distinction (explicit path vs active note) from the tool names 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 behavioral burden for a write operation. It states 'append,' which hints at additive, non-destructive behavior, but says nothing about what happens if the periodic note does not yet exist, where in the note content lands, or whether the call is idempotent.

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 core action front-loaded and the parenthetical example earning its place by disambiguating 'periodic note.' It is efficient, though arguably terse given the tool's open behavioral questions.

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 a write action, the definition leaves an agent unable to determine key preconditions: whether the target note must be created first, whether content is appended at the end, and what the result looks like. The sibling set (create_periodic_note, get_periodic_note) suggests relevant context that is never addressed.

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

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

Schema description coverage is 100% and the period parameter is an enum, so the schema already documents both parameters fully. The description only illustrates 'daily' via the example and adds no syntax or format detail beyond the schema, which makes the baseline 3 appropriate.

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

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

The description gives a specific verb (append) and resource (periodic note) and clarifies 'periodic note' with a concrete example, 'add an entry to today's daily note.' It implicitly separates this from the generic sibling append_to_note, though it never names an alternative 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?

Usage is only implied by the example; there is no statement of when to prefer this over append_to_note, append_to_active_note, or create_periodic_note, nor any precondition (e.g. whether the periodic note must already exist). A sibling named create_periodic_note makes that omission meaningful.

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 the tool can overwrite an existing note, which is an important destructive behavior, but it omits permissions, confirmation behavior, and consequences of overwriting (e.g., data loss).

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

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

Two sentences, front-loaded with the primary action, with no wasted wording. The second sentence on attachment syntax is relevant but slightly redundant with the schema's content description.

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 tool with no output schema, the description covers the core action and attachment syntax. However, it does not explain overwrite consequences, side effects, or return behavior, which would be needed for fuller completeness without annotations.

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

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

Schema description coverage is 100%, so the schema already fully documents both parameters, establishing a baseline of 3. The description's note about ![[filename.png]] syntax duplicates the content parameter's schema description and adds little beyond it.

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 (create) and resource (note), and adds scope: 'Create a new note or overwrite an existing one in the vault.' It implicitly distinguishes itself from append/patch siblings by using 'overwrite,' but 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?

There is no explicit guidance on when to use this tool versus siblings like append_to_note, patch_note, or update_active_note. Usage is only implied by the word 'overwrite,' leaving the agent to infer when creation is preferred over other mutation tools.

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

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

No annotations are provided, so the description carries the full disclosure burden. It usefully reveals that an existing note is overwritten (implying data loss), which is the key trait for a destructive write, but says nothing about required permissions, where the note lands, or what the call returns.

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 zero waste, front-loading the verb and resource and appending the period scope. Nothing is extraneous.

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 write with full schema coverage and no output schema, the description is adequate on purpose. It leaves the overwrite semantics underspecified (what is lost, what happens on success) and gives no return information.

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

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

Schema description coverage is 100% and both parameters are documented in the schema, so the baseline is 3. The description only repeats the period enum values already defined in the schema and adds no syntax, format, or defaulting detail.

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 pair ("Create or overwrite") and resource ("periodic note") plus the scope of period types, which lets an agent separate it from get_periodic_note and append_to_periodic_note. It does not, however, explicitly contrast with the generic create_note 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?

No guidance on when to choose this over create_note, append_to_periodic_note, or get_periodic_note, and no preconditions (e.g., whether the period must map to an existing vault config). The only hint is the implicit 'create/overwrite' behavior.

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 names a destructive action but does not disclose irreversibility, trash/undo behavior, permission requirements, or what happens if no note is active.

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?

It is a single front-loaded sentence with no wasted words. The action and target are clear immediately.

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 no-argument destructive tool, the purpose is clear enough to invoke. However, it omits guidance relative to delete_note and lacks behavioral caveats that matter for a deletion operation.

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

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

The tool takes zero parameters, so the baseline is 4 per the rubric. The description correctly adds no parameter details, and the empty schema is already fully covered.

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 ('Delete' + 'currently active/open note') and the 'active/open' qualifier distinguishes it from the sibling delete_note. An agent can identify the operation without opening any schema.

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, when-not-to-use, or alternative guidance. The sibling delete_note is not mentioned, so the agent must infer that this tool is for the active note only.

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

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

No annotations are provided, so the description must carry the full behavioral burden. 'Delete' implies a destructive mutation, but the description doesn't state whether deletion is permanent, whether it requires confirmation, or what happens to linked references. This is a significant gap for a destructive tool with zero annotation coverage.

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 no waste. It is appropriately sized for a simple tool, though it could benefit from additional routing 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 single-parameter deletion tool with full schema coverage, the core information is present. However, the absence of annotations, behavioral context, and sibling differentiation makes it incomplete enough to be ambiguous in a toolset with multiple delete variants.

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

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

Schema description coverage is 100%, with the sole parameter 'path' fully documented in the schema. The description adds no parameter details beyond what the schema provides. Per the rules, when coverage is high, baseline is 3 even with no param info in the description.

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

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

The description states a clear verb+resource ('Delete a note') and specifies scope ('from the vault'). However, it doesn't distinguish this from the closely named sibling 'delete_active_note', leaving ambiguity about which deletion tool to use.

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

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

No guidance is provided on when to use this tool versus 'delete_active_note' or other deletion-related siblings. The agent receives no context about the difference between deleting a specific note by path and deleting the currently active 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 disclosure burden. It never says whether executing a command is destructive or irreversible, whether it can modify or delete vault content, or what a failed/unknown command ID returns — significant omissions for a tool that runs arbitrary application commands.

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

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

Two short sentences, zero filler, with the core action front-loaded and the prerequisite follow-up second. Every sentence earns its place.

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

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

For a single-parameter tool with no output schema it covers the essentials: the action and how to obtain a valid ID. It leaves the agent without any sense of side effects, failure modes, or whether the call returns a result, which matters for executing an arbitrary command.

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

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

Schema description coverage is 100% and the schema already documents commandId with a concrete example ('editor:toggle-bold'). The description adds 'by its ID' and points to list_commands for discovery, but no format or validation detail beyond the schema, so the baseline 3 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 ('Execute') and resource ('an Obsidian command') and specifies the keying parameter ('by its ID'). It implicitly distinguishes itself from the sibling list_commands, so an agent can tell execute vs. enumerate apart without opening either schema.

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

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

Explicitly routes the agent to list_commands to discover valid command IDs, which is the critical prerequisite. It stops short of stating when not to use it or what conditions make execution unsafe, so it is clear context without exclusions.

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

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

No annotations are provided, so the description carries the disclosure burden. 'Read the content' clearly signals a non-mutating, safe operation, which is the key trait here, but it says nothing about failure modes (no active note open) or what is returned.

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; every word contributes to identifying the resource.

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 of a simple tool with no output schema, the description is nearly sufficient. It could mention the no-active-note edge case, but nothing required to call it correctly is missing.

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 no parameter syntax the description could usefully add.

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

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

States a specific verb (read) and resource (the currently active/open note in Obsidian), which distinguishes it from read_note (path-based) and the active-note mutators. It does not explicitly name a sibling, but the 'active/open' scoping is precise enough for an agent to disambiguate.

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 'currently active/open note' qualifier implies the when-to-use condition without stating it outright, and no alternatives (e.g., read_note for a known path) are mentioned. Adequate but relies on 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 behavioral burden. 'Get' implies a read, but it does not disclose read-only safety, missing-note behavior, required permissions, or return characteristics.

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 tightly written sentence with the main action and scope front-loaded. Every clause earns its place.

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

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

For a one-parameter getter the definition is minimally adequate, but with no output schema and no annotations it omits return-content details and missing-note behavior. Clear gaps remain despite low tool complexity.

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

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

Schema description coverage is 100%, and the period enum is fully documented in the schema. The description restates the period types but adds no format or meaning beyond the schema, so the baseline 3 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 and resource ('Get the content of a periodic note') and enumerates valid period types. It does not explicitly distinguish itself from siblings like read_note or get_active_note, but the resource scope is clear.

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 are named. The name implies retrieval for periodic notes, but the description provides no comparative routing against read_note, get_active_note, or create_periodic_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. It discloses that status and version are returned, but says nothing about authentication needs, error/timeout behavior when the server is down, or whether the call has any side effects — modest but not deep disclosure for a no-arg diagnostic.

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 conveys the target and the returned information with no wasted words.

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

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

For a zero-parameter diagnostic with no output schema or annotations, the description adequately covers what the tool targets and roughly what it returns. The shape of the response (version format, status values) is left unspecified, which is a minor gap.

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

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

The tool takes zero parameters, so there is no parameter semantics to convey; 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?

The description gives a specific verb ('Check') and resource ('Obsidian Local REST API server'), plus a secondary output ('version info'). It clearly distinguishes itself from the note-mutation siblings, though it does not explicitly name 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?

Usage is only implied: an agent can infer this is a connectivity/health probe, but the description never states when to reach for it (e.g., before other calls to verify the server is reachable) or what to do on failure.

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 conveys that the result is unconditional ('all available'), which implies no filtering or pagination, but says nothing about the shape of the return (names? IDs?), whether listing is read-only, or whether the catalog is cached/static.

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 preamble or filler. The trailing clause 'that can be executed' is mildly redundant but also scopes the result usefully, so it mostly earns its place.

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

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

With no output schema and no annotations, the description should explain what the list contains and how it is consumed (e.g., that entries carry identifiers accepted by execute_command). For a tool whose entire value is the returned catalog, that omission leaves the agent guessing about the 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 schema has zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. No parameter-related claims are made that could mislead.

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 ('List') and resource ('all available Obsidian commands'), so the agent immediately knows this is a discovery/enumeration tool. It does not explicitly name the sibling it complements (execute_command) or say the output feeds into it, so differentiation is only implicit via the 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 explicit when-to-use or when-not-to-use statement. The pairing with execute_command is implied by the name and by the phrase 'that can be executed', but the description never tells the agent to call this first to obtain a valid command identifier.

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 behavioral burden. 'List' strongly implies a non-destructive read, but the description never states whether listing is recursive, predictable ordering, or how deep the contents go. For a simple read-only enumeration tool this is minimally viable, not rich.

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

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

Two short sentences, zero filler, and the scoping behavior (path vs root) is front-loaded immediately after the purpose. Nothing to trim.

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

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

For a single-optional-parameter listing tool with no output schema and no annotations, the description covers the purpose and argument semantics adequately. It stops short of describing the shape or depth of the listing, which is the only meaningful remaining gap.

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

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

Schema coverage is 100% with a well-described 'path' parameter, so the schema already carries the semantic load. The description restates the same folder/root behavior without adding format, separator, or path-syntax detail beyond the schema example.

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 ('List') and resource ('files and directories in the Obsidian vault'), making clear it enumerates vault contents rather than reading or searching them. Sibling tools like search_vault and read_note are clearly distinct in kind, though the description does not name them explicitly to sharpen the routing.

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

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

It explains how to use the path argument (provide a folder to list contents, omit for root), which is usage of the parameter rather than when-to-use-vs-alternatives guidance. There is no statement about when to prefer this over search_vault or read_note, leaving the choice implied.

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

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

With no annotations, the description carries the full behavioral burden, and it discloses very little. It does not say whether this changes the active note/focus, whether Obsidian must be running, or what happens if the path is invalid. Only the vague UI side effect 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 wasted words. It is efficient, though its brevity edges toward under-specification rather than pure conciseness.

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

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

For a tool that mutates UI state, the absence of annotations and output schema means the description should explain the side effects and failure modes, and it does not. An agent cannot tell what 'open in UI' changes or requires.

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

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

Schema description coverage is 100% and the single 'path' parameter is fully documented in the schema, so the baseline 3 applies. The description adds no format or path-resolution detail beyond what the schema already provides.

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

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

States a specific verb ('Open') and resource ('a note') plus the destination context ('in the Obsidian UI'), which distinguishes it from content-reading siblings like read_note in spirit. However, it never names or contrasts with those siblings explicitly, so an agent must infer the difference.

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 open a note in the UI versus reading it with read_note or checking get_active_note, and no prerequisites are stated. Usage is only implied by the phrase 'in the Obsidian UI'.

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. 'Insert or replace' hints at overwrite potential, but it omits permissions, what happens if the heading is missing, whether the operation is reversible or idempotent, and what the tool returns.

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 core action and target come first. It is efficient, though so terse that it hedges heavily on guidance.

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 and no output schema, the description is too thin: it explains neither sibling selection nor failure/overwrite semantics that an agent needs to invoke it safely.

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

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

Schema description coverage is 100%, so the schema already documents content, heading, insertPosition, and headingBoundary. The description adds nothing about parameter meaning beyond what the schema provides, so baseline 3 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 clear verb pair ('Insert or replace') and resource ('content relative to a heading'), and the phrase 'currently active note' scopes it apart from the sibling patch_note, which presumably targets a named note. An agent can infer the target without opening the schema, though the relationship to patch_note is only implicit.

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 or when-not-to-use guidance. The description never mentions alternatives such as patch_note, update_active_note, or append_to_active_note, so the agent must guess which of several active-note mutation tools applies.

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 says 'insert or replace' but never states what is destroyed by a replace, how the heading is matched, what happens if the heading is absent, or whether the operation requires the file to be open. For a mutation tool this is a significant gap.

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

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

Two short sentences, front-loaded with the action and scope, with no filler. Every sentence earns its place.

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

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

A five-parameter mutation tool with no annotations and no output schema needs more than one clause: the heading-matching rule, replace-vs-insert consequences, and failure behavior are all unaddressed. The schema covers parameter formats but not the operation's 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 100%, so all five parameters are already documented in the schema and the baseline is 3. The description adds no extra meaning about heading matching or boundary semantics beyond what the schema fields state.

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 ('insert or replace content relative to a heading in a note') that an agent can act on. It implicitly separates itself from append_to_note by being heading-relative, but it never names the near-identical sibling patch_active_note or explains that this one targets an explicit 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?

'Useful for updating specific sections' implies the usage context but gives no when-to-use/when-not guidance and no alternatives. With siblings like append_to_note and patch_active_note, the agent must infer which to pick from the schema 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. The word 'read' implies a safe, non-mutating operation on the vault, which is meaningful, but there is no disclosure of error behavior (nonexistent path, unreadable file), path resolution rules, or size/encoding limits.

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 front-loaded sentence with no wasted words. It is efficient, though it sits near the edge of under-specification rather than being a model of tight, informative phrasing.

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 output schema and no annotations, stating that it returns the note's markdown content covers the essential return-value question. Missing error and path-resolution context keeps it from being fully complete.

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

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

Schema description coverage is 100% and the single path parameter is documented with a concrete example ('Notes/my-note.md'). The description adds no further meaning about path format, relative vs. absolute resolution, or extension handling, so the baseline 3 is appropriate.

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

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

States a specific verb (read) and resource (markdown content of a note in the vault), which is clearer than a name-only restatement. It does not, however, distinguish itself from close siblings such as get_active_note or open_note, so the 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?

There is no guidance about when to use this tool versus alternatives. With siblings like get_active_note, open_note, search_vault, and list_vault_files available, the agent is left to guess whether read_note requires an explicit path, whether the note can be unopened, or when a search tool is preferable.

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 only adds the plugin dependency and does not disclose whether the operation is read-only, what happens if the plugin is missing, or any side effects or execution limits.

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

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

Three tight sentences with no waste. The core purpose is front-loaded, followed by the prerequisite and a useful example.

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 query tool with no annotations and no output schema, the description covers the plugin prerequisite and parameter example. It still omits return behavior, error handling, and routing guidance versus sibling search 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 coverage is 100%, so the baseline is 3. The description adds a concrete DQL example, which meaningfully helps an agent construct the dql parameter beyond the schema's minimal text.

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: run a Dataview DQL query against the vault. It clearly identifies the specialized query language, but does not explicitly distinguish itself from sibling tools like search_vault or search_jsonlogic.

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

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

It gives a prerequisite (Dataview plugin must be installed) and implies usage when a Dataview DQL query is needed, but never states when to choose this over search_vault or search_jsonlogic.

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 state that this is a read-only operation, whether results are limited or paginated, which JsonLogic operators are supported, or how errors in the query string are surfaced — all meaningful for a DSL-driven 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?

Two short, front-loaded sentences with no filler: the first states the action and pattern, the second states the use case. Nothing could be removed without losing information.

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

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

For a one-parameter tool with no output schema, the definition covers the minimum: what it does and the intended query domain. It leaves real gaps for a JsonLogic DSL tool — supported operator set, result shape, and result limits — which 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 100% for the single 'query' parameter, so the schema already documents that a JsonLogic query is expected as a JSON string. The description adds only the domain hint that queries are meant to filter notes by metadata fields, which is mild added value over the schema.

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

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

States a specific verb and resource ('Run a JsonLogic query against the vault') and adds a scope qualifier ('structured/programmatic searches'), which distinguishes it from the plain-text 'search_vault' and the 'search_dataview' siblings. It stops short of naming those alternatives, but an agent can infer the distinction from the wording.

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?

'Useful for filtering notes by metadata fields' implies the usage context, so the agent knows this targets metadata rather than free text. However, it never explicitly states when to prefer this over search_vault or search_dataview, nor any prerequisites, so the routing guidance is only implied.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose two useful traits — the search is fuzzy (not exact-match) and the return shape is 'matching filenames and context' — but it says nothing about whether this is a read-only operation, how the limit behaves, or pagination/ordering of results.

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

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

Two short sentences, front-loaded with purpose then return shape, with no wasted words.

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

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

For a simple two-parameter search tool with no annotations and no output schema, the description covers purpose and the shape of returned data (filenames plus context). It stops short of clarifying relationship to the other search tools, which is the main remaining gap.

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

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

Schema description coverage is 100%, so both 'query' and 'limit' are already documented in the schema; the description adds no syntax, format, or fuzzy-matching semantics for the query string. Baseline 3 is appropriate when the schema does the heavy lifting.

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 ('Search for notes in the vault') plus the technique ('full-text fuzzy search'), so the agent knows exactly what the tool does. It does not, however, distinguish itself from the sibling search tools (search_dataview, search_jsonlogic), which an agent must infer from names alone.

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 mention of the alternative search tools in the sibling list (search_dataview, search_jsonlogic). The agent is left to infer from tool names whether this is the right search entry point.

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. "Overwrite" usefully signals full replacement (destructive, unlike patch/append), but it omits what happens to prior content, reversibility, permission requirements, and the failure mode when no note is active.

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 the destructive verb leading and zero wasted words. Appropriately sized for a one-parameter 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 simple one-parameter mutation with no output schema, the description is minimally adequate, but it leaves the destructive/irreversible nature and sibling distinctions implicit. Given the dense sibling set of *_active_note variants, a bit more routing context would help.

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?

Only one parameter with 100% schema description coverage ("New markdown content for the active note"), so the schema already documents it. The description adds nothing beyond the schema, making the baseline 3 appropriate.

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

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

States a specific verb ("Overwrite") and resource ("currently active/open note in Obsidian"), which distinguishes it from generic note tools. However, it doesn't differentiate itself from close siblings like patch_active_note or append_to_active_note, which share the same target resource.

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 patch_active_note or append_to_active_note, nor any prerequisite such as an active note being open. The agent must infer the distinction from the verb 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 clearly indicates a write operation to the vault and suggests a downstream embed action, but omits critical mutation details such as whether existing files are overwritten, required permissions, size limits, or error behavior. Minimum viable but with clear 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?

Two short sentences, zero waste, and the core action is front-loaded. The embed syntax tip is a useful secondary sentence that earns its place.

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

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

For a two-parameter write tool with no output schema, the description covers purpose, source/destination, and the post-upload embed workflow. But with no annotations and no disclosure about overwrite behavior, permissions, or side effects, an agent cannot fully predict behavior before invocation.

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

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

Schema description coverage is 100%, so both localPath and vaultPath are already documented with examples in the schema. The description restates source and destination without adding format, constraint, or behavior details beyond what the schema provides. Baseline 3 applies.

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

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

The description states a specific verb (upload) and resource (attachment) and explicitly scopes the source as a local file path and destination as the vault. It also lists supported file types, which helps an agent distinguish this from note-creation or search siblings.

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

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

It implies usage by explaining the post-upload step (embedding via ![[filename]]), which is helpful workflow context. However, it does not say when to use this tool versus alternatives like create_note or append_to_note, nor does it state any prerequisites or exclusions.

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