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 that aliases are added to frontmatter but does not mention whether existing aliases are preserved, how conflicts are handled, or what happens if the note does not exist. For a mutation tool, this lack of detail 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?

The description is two sentences, front-loaded with the action, and contains no filler. Every sentence contributes meaning: the first defines the operation, the second explains its utility.

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, the description provides the core function and rationale, and the schema covers the parameters. However, it lacks behavioral details such as whether aliases are merged or replaced, and it does not mention error scenarios. Given no annotations and no output schema, the description is adequate but not 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?

The input schema already describes both parameters (path and aliases) with 100% coverage, so the description does not need to explain them. It adds a small semantic nuance by calling aliases 'alternative names,' but this is marginal value beyond the schema.

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

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

The description clearly states the action ('Add aliases') and the target resource ('a note's frontmatter'), distinguishing it from sibling tools like add_tags. It also explains the purpose ('Aliases help find notes by different names'), making the tool's function unambiguous.

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

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

The description implies when to use the tool by explaining the benefit of aliases ('help find notes by different names'), but it does not explicitly exclude alternatives or mention when not to use it. This provides a clear context without naming other options like add_tags or set_frontmatter_property.

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 of behavioral disclosure. It mentions the ability to append/prepend and format as a list item, but does not disclose side effects (e.g., whether existing content is preserved, whether the target note must exist, or whether it handles duplicate links). It also gives no indication of return values or errors.

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

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

The description is two sentences, front-loaded with the core purpose, and contains no filler. Every word earns its place, and it is appropriately concise for the tool's complexity.

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

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

Given the tool has 5 parameters, no annotations, and no output schema, the description is too sparse. It does not explain return behavior, error conditions, or how the 'position' parameter maps to actual file modifications. It also misses opportunities to tie to sibling tools (e.g., append_to_note) for clarity.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add significant meaning beyond the schema; it reiterates placement but not details about displayText or asListItem. The schema already describes each parameter adequately.

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

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

The description clearly states the action ('Add an internal link ([[note]]) to a note') and specifies the resource. It also mentions two placement options ('append to the end or insert at a specific location'), adding scope. However, the phrase 'insert at a specific location' is somewhat vague and undercuts sibling differentiation, as tools like insert_under_heading also insert at locations.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention exclusions (e.g., when to use update_note or append_to_note instead) or prerequisites (e.g., the note must exist). The sibling list shows many related tools, but the description fails to differentiate this one.

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

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

With no annotations provided, the description carries the full burden. It discloses key behaviors: adds to frontmatter, avoids duplicates, and creates frontmatter if needed. This goes beyond the basic function name and provides useful state-change context.

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

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

Two concise sentences with the primary action front-loaded. Every sentence adds value: the first defines the operation, the second clarifies duplicates and frontmatter creation. No unnecessary words.

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

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

For a simple two-parameter mutation tool with no output schema, the description covers purpose, key behavior, and side-effect (creating frontmatter). It is sufficiently complete given the low complexity and rich sibling context.

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

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

Schema description coverage is 100%, so baseline is 3. The description does not add extra parameter-level meaning beyond the schema, though it reinforces the duplicate-free behavior which is related to the tags parameter.

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

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

The description clearly states the verb 'add' and the resource 'tags to a note's frontmatter'. It distinguishes from siblings like remove_tags and get_tags by specifying the action and the duplicate-free 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?

The description implies usage for adding tags without creating duplicates, but does not explicitly explain when to choose this over alternatives like set_frontmatter_property or update_frontmatter. No exclusions or alternative guidance is provided.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only restates the append action and offers no details about side effects, prerequisites (e.g., having an active note), error handling, or what happens if no active note exists. This is a mutation tool and lacks meaningful transparency.

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

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

The description is two short sentences with no redundant wording. It front-loads the core action and includes a usage hint, making it appropriately sized and efficient.

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

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

Given the simple nature of the tool and full parameter schema, the description is minimally adequate. However, it does not explain what constitutes an 'active note', whether a note must be open, or the behavior when no active note exists. These gaps could lead to incorrect usage 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 description coverage is 100%, so the parameters content and ensureNewline are fully documented in the schema. The description does not add additional semantic meaning beyond what the schema provides, hence baseline 3 is appropriate.

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

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

The description clearly states the verb (append) and resource (currently active note in Obsidian), and it distinguishes itself from siblings like append_to_note which likely target a specific note path. The phrase 'currently active note' provides a specific scope.

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

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

The description implies when to use this tool: when you want to quickly add content to the note you're working on, without needing to specify a path. It does not explicitly name alternatives or exclusions, but the context of 'active note' versus specific note tools provides clear usage intent.

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

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

Since no annotations are provided, the description carries the full burden of behavioral disclosure. It reveals two key behaviors: appending content and creating the note if it doesn't exist, which goes beyond the tool's name. It does not detail formatting or error handling, but the core side effect is transparent.

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

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

Two sentences with no fluff, front-loaded with the primary action. Every word contributes to understanding the tool's purpose and 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?

Given the tool's simplicity and full schema coverage, the description is sufficient for selecting and invoking the tool. It covers the essential behavior and the creation fallback, though it omits explicit comparison to alternatives.

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

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

The input schema already covers all three parameters with 100% description coverage, so the baseline of 3 applies. The description adds no additional meaning to the parameters beyond what the schema provides.

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

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

The description clearly specifies the action ('append'), the resource ('today's daily note'), and explicitly states the creation fallback. This distinguishes it from sibling tools like append_to_note (which targets arbitrary notes) and prepend_to_note (which prepends).

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

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

The description provides clear context by indicating the target (today's daily note) and the auto-create behavior, which helps an agent decide when to use this tool. However, it does not explicitly name alternatives or state when not to use it, so it lacks explicit exclusions.

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

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

With no annotations, the description carries the burden. It states the core behavior (append to end) but does not disclose edge cases like behavior with missing notes (createIfMissing) or newline handling. These are left to the schema, and the description adds no extra behavioral context beyond the obvious 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?

Two concise sentences with the action front-loaded and use cases following. Every word earns its place, with no redundancy.

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

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

For a simple append operation, the description covers the main purpose and gives usage examples. There is no output schema, but the tool is a straightforward mutation; given the schema's coverage of parameters, the description is sufficiently complete.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds no parameter-specific guidance beyond what the schema already documents, so it neither adds nor detracts from parameter meaning.

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

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

The description uses the specific verb 'append' with a clear target ('to the end of an existing note'), which distinguishes it from siblings like prepend_to_note and insert_under_heading. The use cases further clarify scope.

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

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

The description explains that it is useful for adding sections, logging entries, or updating lists, giving clear contexts for use. However, it doesn't explicitly mention alternatives or when not to use it, though the differentiation is implicit.

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 only mentions the period targeting behavior, but fails to disclose other important traits such as whether the note is created if it doesn't exist, how content is formatted, or any side effects like timestamp changes. This is a significant gap for an append operation.

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

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

The description is concise, with two short sentences that are front-loaded and free of fluff. The first sentence states the primary action, and the second adds a key scoping detail. It could be more informative, but it earns its place.

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

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

Given the tool has 5 parameters, no annotations, and no output schema, the description is under-specified. It does not explain return behavior, edge cases like missing notes, or formatting of appended content. A more complete description would address these aspects, especially for a mutation tool with no annotation safety net.

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 parameters are already documented in the input schema. The description's phrase 'current period's note or a specific date' reinforces the optional day/month/year parameters, but adds no new information beyond what the schema already says about defaulting to current values. Baseline 3 is appropriate.

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

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

The description clearly states the verb 'Append' and the resource 'periodic note', and specifies that it can target the current period's note or a specific date. This distinguishes it from sibling tools like append_to_note and append_to_daily_note, which have different scopes.

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

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

The description implies usage for periodic notes and mentions the ability to target current or specific dates, giving some context. However, it does not explicitly state when to use this tool over alternatives like append_to_note or append_to_daily_note, nor does it provide exclusionary guidance. For comparison, the high example explicitly names an alternative.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds the key fact that 'The original note is preserved,' which is a non-obvious behavior. However, it does not mention what happens if a file exists at the destination and overwrite is false, or whether intermediate directories are created, leaving some behavioral ambiguity.

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

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

The description is two short, direct sentences that efficiently convey the core action and a critical side effect. Every word earns its place, with no fluff or repetition.

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

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

For a simple copy operation with a well-defined schema, the description is adequately complete: it states the operation and that the original is preserved. The absence of an output schema is acceptable given the tool's simplicity, and the overwrite behavior is documented in the schema. Minor gaps like error handling on conflict are not critical.

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

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

The input schema covers all three parameters with clear descriptions (sourcePath, destinationPath, overwrite), achieving 100% schema_description_coverage. The description provides no additional parameter semantics, so it does not add value beyond the schema.

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

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

The description clearly states the tool's function: 'Copy a note to a new location in the vault.' It specifies the verb (copy), the resource (note), and the outcome (new location), and it distinguishes itself from sibling tools like delete_note (which removes) and create_note (which creates new notes).

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

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

The description provides no explicit guidance on when to use this tool versus alternatives such as create_note or update_note. It does not mention scenarios where copying is preferred or any exclusions, leaving the agent to infer usage from the tool name and purpose.

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 full burden. 'Create' implies a write operation, but there is no mention of where the note is saved, whether it's in the vault, default folder behavior, or authorization needs. Worse, it mentions 'action items' which do not appear in the schema, introducing ambiguity. This is a significant transparency gap.

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

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

The description is a single, short sentence, which is concise and front-loaded with the verb. However, it includes a stray reference to 'action items' that is unsupported by the schema, making it inaccurate. It earns a 3 because it's not overly long but sacrifices correctness 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 create operation with no annotations and no output schema, the description is too thin. It doesn't explain return values, vault placement, or any side effects. The schema is simple, but the description still fails to paint a complete picture of what the tool does beyond the bare minimum.

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

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

The schema has 100% description coverage for its five properties, so the baseline is 3. The description adds no useful parameter detail beyond the schema; instead, it introduces 'action items' which are not a property, potentially misleading the agent into thinking there is an action_items field. This actively detracts from parameter understanding.

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

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

The description clearly states the action ('create') and the resource ('structured meeting note'), and it hints at specific content (attendees, agenda) that distinguishes it from generic create_note. However, it does not explicitly differentiate from sibling tools like create_note_from_template or create_project_note, so it's clear but not fully distinguishing.

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 tool name and description: use this for meeting notes. There is no explicit guidance on when to choose this over alternatives like create_note or when not to use it. The rubric marks implied usage as a 3.

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, and the description does not disclose important behavioral traits such as default overwrite behavior, parent folder creation, or conflict handling. The schema provides these details, but the description itself adds minimal behavioral context beyond the basic create action.

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

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

The description is two concise sentences, front-loaded with the main purpose and followed by a helpful note about frontmatter capabilities. No unnecessary words or repetition.

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

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

The schema is rich and covers all parameters with descriptions, and the description provides the tool's core purpose. However, the description lacks any mention of return values or error behavior, and given there is no output schema, this is a minor gap for a create tool.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value by explicitly mentioning 'custom fields' in frontmatter, which clarifies that additional frontmatter properties beyond the listed ones are allowed, supplementing the schema's additionalProperties: true.

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

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

The description clearly states the tool creates a new note in the Obsidian vault, which distinguishes it from sibling tools like update_note, append_to_note, and delete_note. It also mentions frontmatter capabilities, further defining its purpose.

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

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

The description clearly indicates this is for creating new notes, which implies usage over update/append tools. However, it does not explicitly mention when not to use it or provide alternatives, so it lacks explicit exclusions or alternatives.

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 burden of behavioral disclosure. It only states the basic action ('Create a new note') without mentioning return values, error handling, duplicate title behavior, or what content is included beyond the template. This is minimal and insufficient for a no-annotation 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 sentence that front-loads the core action and then lists the available templates. Every word earns its place, with no fluff or repetition of schema 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?

The tool is relatively simple with an output schema absent and no annotations, but the description covers the core purpose. It lacks guidance on what happens after creation (e.g., return value) or how customFields interact with templates, so it is complete enough for basic use but leaves gaps for an agent needing robust expectations.

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 covers all parameters with descriptions (100% coverage), so the baseline is 3. The description adds no additional meaning beyond the schema; it merely repeats the template enum values, which are already present in the schema. Therefore it neither improves nor worsens parameter understanding.

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

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

The description clearly states the tool creates a new note using a built-in template and explicitly lists the available templates. This specific verb+resource distinction sets it apart from siblings like create_note, create_meeting_note, and list_templates.

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

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

The description gives clear context by indicating this tool is for template-based note creation and enumerates the templates, but it does not explicitly name alternatives or exclusions (e.g., when to use create_note or create_meeting_note instead). Thus it has 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 full burden. It only states 'Create' without disclosing overwrite behavior, folder handling, or side effects. The 'tasks' reference adds confusion rather than transparency.

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

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

The description is a single sentence with no fluff, which is concise in form. However, given the tool's six parameters and absent annotations, this brevity leads to under-specification rather than effective conciseness.

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

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

The description does not cover usage context, return behavior, or differentiate from sibling tools. No output schema exists, so the description should have provided more behavioral detail, but it remains minimal.

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

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

Schema description coverage is 100%, providing baseline 3. The description adds a high-level summary but does not compensate for the 'tasks' mismatch, and it fails to clarify parameter relationships beyond the schema.

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

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

The description clearly states the action ('Create') and resource ('structured project note'), distinguishing it from generic note creation. However, the mention of 'tasks' which is not present in the schema introduces slight ambiguity.

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 given on when to use this tool versus alternatives like create_note or create_meeting_note. The description lacks context about prerequisites or 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?

With no annotations provided, the description carries the full burden. It says 'Add' and 'Creates' but does not disclose whether the note must exist, whether it appends or inserts, how the formatting behaves, or any side effects. This is a significant gap 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 description is two short sentences, front-loaded with the action and resource. It includes useful information about formatting and optional sections without redundancy or fluff.

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

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

For a write tool with no annotations, no output schema, and a specialized function, the description is incomplete. It does not mention prerequisites (e.g., whether the daily note must exist), return values, or how the journal entry is integrated into the note. The high schema coverage doesn't compensate for missing behavioral context.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds minimal parameter meaning; 'optional sections' loosely references todos/gratitude/highlights but does not explicitly map them. No extra value beyond the schema is provided.

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

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

The description uses a specific verb 'Add' and clearly identifies the resource 'today's daily note' with a structured journal entry. It distinguishes itself from siblings like append_to_daily_note by emphasizing 'structured' and 'optional sections', which implies a formatted output.

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

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

The description implies the tool is for journal entries in daily notes, but it does not explicitly state when to use it versus alternatives like append_to_daily_note or quick_capture. No exclusions or alternative recommendations are provided.

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

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

With no annotations, the description must disclose behavior on its own. It states the operation ('Add'), the target ('today's daily note'), and the entry format. Yet it does not mention whether this appends vs. replaces, whether the daily note is created if absent, or what the response is, leaving some behavioral ambiguity.

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

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

Two short sentences, front-loaded with the action, and no filler. The phrase 'yesterday, today, blockers' is compact and 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 small tool with a fully described schema, the description adequately covers purpose and format. The only notable omission is behavior around missing daily notes or append semantics, which would make it more complete, but it is not necessary for basic 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 100%, so the schema fully documents all three parameters. The description only repeats the field names without adding new semantic detail, so it meets the baseline but doesn't exceed 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 clearly identifies the tool's function: adding a daily standup/scrum entry to today's daily note, and explicitly names the classic standup fields (yesterday, today, blockers), which distinguishes it from generic note-editing siblings like append_to_daily_note and daily_journal_entry.

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

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

The description implies when to use it (to record a standup entry in the daily note) and even contrasts with general note tools by specifying the standup format. However, it does not explicitly state when not to use it or name alternatives, so it relies on the reader to infer the appropriate context.

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

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

With no annotations, the description clearly discloses the critical destructive behavior: 'WARNING: This permanently removes the file. Use with caution.' This is essential safety information. It does not, however, mention the confirmation requirement or any recovery options, but the warning sufficiently conveys the irreversible nature.

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

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

The description is extremely concise: two short sentences plus a warning. It is front-loaded with the action and immediately follows with the critical caution. Every word earns its place without redundancy.

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

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

For a simple two-parameter destructive tool with a complete schema, the description conveys the essential purpose and risk. It lacks clarification relative to sibling tools (e.g., 'delete_note') and does not state success/error behavior, but these are not required given the simplicity and schema completeness.

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

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

Schema coverage is 100% with both 'path' and 'confirm' fully described. The description adds no param-specific detail beyond what the schema already provides, so it defaults to the baseline. The warning about permanence indirectly supports the 'confirm' parameter but does not explain its syntax or semantics further.

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 a file from the Obsidian vault.' This clearly identifies the action and target. However, it does not distinguish between deleting a file and the sibling 'delete_note' tool, leaving potential ambiguity about which is appropriate for different content types.

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

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

The description provides a warning about permanence but gives no guidance on when to use this tool versus alternatives like 'delete_note' or how to handle prerequisites (e.g., confirming paths). No specific usage context or exclusions are offered.

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 full responsibility for behavioral disclosure. The explicit WARNING that the deletion 'permanently removes the note' provides a crucial safety-relevant behavior beyond the tool name, despite not mentioning side effects like backlinks or permissions.

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

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

The description is concise, front-loaded with the action, and includes a critical warning in just three short sentences. Every word contributes meaningful information without redundancy.

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

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

For a simple two-parameter delete tool with a well-documented schema, the description is adequately complete. It states the action, the target, and the permanence, which is essential context. It doesn't address potential effects on backlinks, but this is not a major omission for such a tool.

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

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

The input schema already provides descriptive definitions for both parameters (path, confirm), achieving 100% schema_description_coverage. The description adds no additional parameter information, so the baseline score of 3 applies.

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

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

The description clearly states 'Delete a note from the Obsidian vault,' using a specific verb and resource. It distinguishes from the sibling tool 'delete_file' by targeting notes specifically, though it doesn't explicitly name the alternative.

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 alternatives like 'delete_file' or under what circumstances deletion is appropriate. The warning 'Use with caution' is a caution, not a usage guideline.

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 present, the description must disclose behavioral traits but fails to mention potential side effects of executing arbitrary commands or error behavior for invalid IDs. It only states the basic operation, insufficient for a tool that can trigger arbitrary functionality.

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

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

Two concise sentences with useful examples and no filler. Front-loaded with the core action, then relevant guidance and examples.

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 single-parameter tool, the description adequately covers the workflow: find a command ID, then execute it. It doesn't discuss error handling or side effects, but given the tool's simplicity and schema coverage, it is reasonably 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 already covers commandId, and the description adds value by telling the agent to use get_commands for finding valid IDs and providing example command IDs, which goes beyond the schema's minimal 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?

Clearly states the action (execute) and the resource (an Obsidian command by its ID). References get_commands for finding IDs, distinguishing it as the execution counterpart and differentiating from sibling command-listing 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?

Explicitly instructs to use get_commands to find available commands and their IDs, providing essential usage context. Also gives example command IDs to illustrate valid input, but does not explicitly discuss when not to use the tool (e.g., for unsupported commands).

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 for behavioral disclosure. It states the basic function but does not disclose the return format, underlying behavior, performance characteristics, or limitations. For a simple read-only operation, the absence of side effects is not stated, and the user cannot infer what output to expect.

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 exactly two sentences, every word earning its place. It is front-loaded with the main purpose and gives a concise definition of the broken-link target, with no redundancy or extraneous 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 tool with one optional parameter and no output schema, the description covers the core purpose but lacks any mention of return values or behavior for the optional folder parameter. While simple, it falls short of fully equipping an agent to know what to do with the results or how the optional parameter affects the search scope.

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 optional 'folder' parameter, and the schema already explains its meaning. The description adds no additional parameter semantics beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

The description uses a specific verb ('Find') and resource ('broken internal links in the vault'), further clarifying the target ('[[links]] that point to notes that don't exist'). This clearly distinguishes it from sibling tools like get_outgoing_links or find_orphan_notes.

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

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

The description implies a clear use case (finding broken internal links) but provides no explicit guidance on when to use it versus alternatives, nor any exclusion conditions. It lacks the explicit 'when not to use' or alternative tool references seen in higher-scoring examples.

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 only states that the search is by filename containing text, but does not disclose behavior for exactMatch, case sensitivity, the scope of the search (all notes vs folder), or the return format. This is a significant transparency gap.

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

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

Two short sentences that both contribute: the first gives a high-level purpose, the second specifies the contains behavior. No wasted words.

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

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

Given there is no output schema or annotations, the description should explain return values and search scope. It does neither, and it fails to mention the exactMatch option entirely, leaving the tool under-specified for an agent.

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

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

Schema description coverage is 100%, so the baseline is 3. The description reinforces the 'contains' behavior for the name parameter, which is already in the schema, but adds no additional meaning for exactMatch or other aspects.

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

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

The description clearly states the action 'Find notes by their filename' and specifies the resource (notes) and criterion (filename). This distinguishes it from content search tools like search_notes or search_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?

The description indicates the use case: searching notes by filename. However, it does not explicitly mention when not to use it or point to alternatives for content search, so it lacks explicit exclusions.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It explains the core semantics and implies a read-only search, but it doesn't describe the return format, default scope, or any side effects. The 'find' verb suggests safety, but details are sparse.

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

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

The description is two concise sentences, front-loaded with the main definition and then elaborating on the concept. Every word contributes meaning; there is no fluff or repetition.

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

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

The tool is simple with well-documented parameters, but there is no output schema and the description doesn't explicitly state what the tool returns (e.g., a list of note names). This leaves a gap for the agent regarding expected output, so completeness is average.

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%: both 'folder' and 'includeUnlinked' are described in the schema. The description adds no parameter-specific information, so it aligns with the baseline for high schema coverage.

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

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

The description clearly states the tool's function: finding orphan notes, defined as notes with no incoming links from other notes. This distinguishes it from sibling tools like find_broken_links and get_backlinks by focusing on connectivity rather than broken links or backlink data.

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

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

The description provides a clear context: it identifies notes that are disconnected from the knowledge graph. This tells the agent when to use the tool, but it doesn't explicitly name alternatives or exclusions, so it stops short of a perfect score.

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

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

No annotations are provided, so the description carries the burden. It discloses the return structure (content, path, metadata), which adds context, but it does not explicitly state that the operation is read-only, what happens if no note is active, or any error behavior. This is a moderate gap for a tool without annotations.

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

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

The description is a single, front-loaded sentence that directly states the purpose and output. No redundant words, no repetition of the tool name. It is concise and efficient.

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 getter tool with no output schema, the description adequately covers the main use case and return values. It even mentions that it returns metadata, which is helpful. The only notable omission is edge-case behavior (e.g., no active note), but that is a minor gap given the simplicity of the tool.

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

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

The input schema has 100% description coverage for both parameters (includeStats and includeContent), so the schema already explains their meaning. The description does not add extra semantic value beyond the schema, such as how these parameters interact with the return fields. Baseline of 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 clearly states it gets the currently active (focused) note in Obsidian, specifying the verb (Get) and resource (active note), and lists the return fields (content, path, metadata). This distinguishes it from siblings like read_note, which reads a specific note by path.

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

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

The phrase 'currently active (focused) note' provides clear context for when to use this tool: when the user needs the note that is open/focused in Obsidian. However, it does not explicitly mention alternatives (e.g., read_note for a specific path) or exclusion criteria, so it stops short of full guidance.

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

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

No annotations are provided, so the description carries the burden of behavioral disclosure. It communicates scope ('entire vault'), uniqueness, and that a list is returned, but it does not mention performance implications, the effect of the optional folder, ordering, case sensitivity, or empty-result behavior. This is adequate for a simple read tool but not rich.

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

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

Two short sentences with no filler. The main action and resource are stated immediately, and the added use-case 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 simple tool with one optional parameter and no output schema, the description sufficiently states the return concept (list of unique tags) and scope. The schema handles the folder parameter, so the description is nearly complete, though it could slightly clarify how the folder option relates to the 'entire vault' scope.

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

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

The input schema covers 100% of the single parameter with 'Optional folder to limit the search.' The description adds no parameter-specific detail beyond what the schema already states, so the baseline of 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 uses a specific verb ('Get') and names a precise resource ('all unique tags used across the entire vault'). This clearly distinguishes it from sibling tools like get_tags or search_by_tag by emphasizing vault-wide scope and uniqueness.

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

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

The description provides a clear use case ('understanding tag taxonomy and finding related notes'), giving the agent context for when this tool would be helpful. However, it does not explicitly call out alternatives or when not to use it, so it stops short of a full 5.

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

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

No annotations are provided, so the description carries full burden. It discloses that the search spans the entire vault and looks for [[note]] references, which is useful. However, it does not mention return format, exact match behavior, or handling of non-existent notes. It adds some context but not rich detail.

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

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

The description is two sentences, immediately conveys the core action, and adds the vault-wide scope. No redundant or vague wording; every clause contributes useful information.

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

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

For a simple read-only search tool, the description covers purpose and scope adequately. However, since there is no output schema, a brief statement about the return value (e.g., list of note paths) would improve completeness. The tool's simplicity and clear sibling context prevent a lower score.

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 both path and includeContext already described in the schema. The description adds no additional parameter semantics beyond what the schema provides, so the baseline score of 3 is appropriate.

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

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

The description clearly states the tool's function: 'Find all notes that link to a specific note (backlinks)' with a specific verb and resource. It also adds scope ('Searches the entire vault') and the syntax ([[note]] references), which distinguishes it from sibling tools like get_outgoing_links.

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 rather than explicit. The description says what the tool does but does not state when to choose it over alternatives, such as get_outgoing_links, nor does it provide exclusion criteria. The reader must infer use cases from the 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?

With no annotations provided, the description carries the full burden of disclosing behavior. It states the tool returns a list of commands but does not mention return format (e.g., array of names/IDs), sorting, or performance implications. It implies a read-only operation but does not explicitly confirm no side effects, though that is reasonable for a 'get' tool. The examples add a bit of context, but deeper behavioral transparency is lacking.

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

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

The description is two sentences, front-loaded with the primary purpose and includes illustrative examples. Every sentence earns its place without redundancy or unnecessary detail. It is appropriately concise and well-structured.

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

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

For a simple listing tool with one optional parameter and no output schema, the description adequately explains what the tool does. However, it does not specify the output format (e.g., whether it returns command IDs, names, or both), which an agent might need for downstream use with execute_command. This is a minor but notable gap given the lack of an output schema.

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

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

The single filter parameter is fully documented in the input schema with a clear description ('Filter commands by name (case-insensitive)'). The tool description adds no additional meaning beyond the schema, so it does not compensate for any gaps. Since schema coverage is 100%, the baseline of 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 uses a specific verb 'Get' and resource 'commands', making it clear this tool lists available commands. It provides concrete examples like 'Toggle fold' or 'Export to PDF', which helps distinguish it from sibling tools like execute_command (which runs commands) and file listing tools. The purpose is unambiguous and immediately understandable.

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

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

The description implies that the tool is used to discover commands that can be executed, especially given the sibling execute_command tool, but it never explicitly states when to use this tool versus alternatives. There is no direct guidance on using this to find command IDs/names before executing, nor any exclusions. The context is implied rather than stated.

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

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

With no annotations, the description carries the burden and does well by disclosing the non-obvious side effect 'Creates the note if it doesn't exist' and the dependency on Daily Notes or Periodic Notes plugins. It stops short of describing the exact return format, but the core behavior is transparent.

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

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

Two concise sentences deliver the purpose, the create-on-missing behavior, and the plugin requirement without wasted words. The description is front-loaded with the primary action.

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

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

For a simple tool with one optional parameter, the description covers the purpose, creation side effect, and prerequisites. It does not detail return values, but the absence of an output schema lowers that burden. Minor gap: no mention of error behavior when plugins are absent.

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

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

The input schema fully describes the only parameter includeContent with a clear explanation, so the schema does the heavy lifting. The description adds no additional parameter context, matching the baseline for 100% schema coverage.

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

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

The description opens with 'Get the content of today's daily note,' clearly stating the verb and resource. It also notes that it creates the note if missing, distinguishing it from general read_note and placing it in the daily-note 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?

The description implies use for today's daily note and notes the plugin requirement, but it does not explicitly contrast with siblings like read_note or get_periodic_note. There is no when-not or alternative guidance, only a prerequisite.

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 describes the output (file counts by extension, total files, directory counts) but does not disclose behavioral traits such as whether subdirectories are included recursively, how hidden files are handled, or any side effects, which is a notable gap even for a read-only stats 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 two concise sentences, front-loaded with the action and resource, and every clause contributes meaning. There is no wasted filler or redundant 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 1-parameter tool with no output schema, the description sufficiently covers what the tool returns (file counts by extension, total files, directory counts). It could mention whether the stats are recursive or if there are edge cases, but it is largely complete for typical use.

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

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

Schema description coverage is 100%: the 'path' parameter is fully documented in the schema ('Directory path to analyze. Leave empty for entire vault.'). The description adds minimal extra value by restating that it can operate on the whole vault or a specific directory, so the baseline of 3 is appropriate.

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

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

The description uses a specific verb ('Get statistics') and resource ('files in the vault or a specific directory'), and clearly distinguishes it from sibling tools like list_files or get_vault_structure by focusing on aggregated statistics rather than raw listings.

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

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

The description implies when to use the tool (when you need file statistics such as counts by extension), but does not explicitly mention alternatives or when not to use it. Context is clear but lacks exclusionary guidance.

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

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

With no annotations provided, the description carries the burden of disclosure. It explicitly states the return scope ('all frontmatter fields including tags, aliases, and custom properties') and the verb 'Get' implies a read-only operation. However, it does not mention edge cases like missing frontmatter, but this is acceptable for a simple getter.

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

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

The description is two sentences, front-loaded with the main action, and includes useful information about return values without any fluff. It earns its place with every word.

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

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

Given the tool's simplicity (one parameter, no output schema, no annotations), the description is fairly complete. It explains the return value and clearly differentiates from other note-related tools. The only minor gaps are the lack of explicit read-only confirmation and behavior when frontmatter is absent, but these are not critical for such a basic 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 schema provides 100% coverage for the single 'path' parameter, so the baseline is 3. The description does not add any extra meaning beyond the schema, but the schema itself is sufficient for understanding the parameter.

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

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

The description clearly states the tool retrieves frontmatter (YAML metadata) from a note and lists the types of fields returned (tags, aliases, custom properties). This specific verb+resource combination distinguishes it from siblings like read_note (whole note) and get_tags (only tags).

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

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

The context is clear: use this tool when you need the parsed frontmatter metadata of a note. It does not explicitly mention alternatives or exclusions, but the description makes the tool's purpose unambiguous enough that an agent can infer when to use it, especially given sibling tool names.

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 discloses the output shape (nodes and edges) and the scope (folder/vault), but does not mention limitations, performance implications, or that it is a read-only operation. This adds some context beyond the schema but is not rich.

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

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

The description is two concise sentences, front-loaded with the action and resource, and contains no filler. Every word contributes to conveying what the tool does and what it returns.

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

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

Given the tool's simplicity and the absence of an output schema, the description adequately covers the core aspects: what data is returned (nodes/edges), the scope (folder/vault), and the purpose (visualization). It is missing explicit alternative guidance, but remains sufficient for an agent to invoke correctly.

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

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

The schema covers 100% of parameters with descriptions for 'folder' and 'maxNotes', so the baseline is 3. The description adds context about the overall purpose but does not enhance parameter understanding beyond what the schema already provides.

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

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

The description clearly states the tool retrieves link graph data for a folder or the entire vault, and specifies the output as nodes and edges for visualization. This is a specific verb+resource that distinguishes it from sibling tools like get_outgoing_links or get_backlinks, which focus on individual note links.

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

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

The description implies usage for graph-wide visualization by mentioning 'folder or entire vault' as the scope, but it does not explicitly say when to use this tool versus alternatives such as get_outgoing_links, get_backlinks, or find_broken_links. The context is clear but lacks exclusions or alternative guidance.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It does reveal that the tool returns internal links, external links, and tags, providing some insight into expected output. However, it doesn't mention error behavior, formatting, or explicitly state read-only status beyond the 'get' verb.

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 that states the purpose first and then the return types. It contains zero wasted words and is appropriately sized for the tool's simplicity.

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, the description adequately explains return types, which is sufficient for an agent to invoke it correctly. It doesn't cover edge cases, but the simplicity of the operation doesn't require more. The presence of related sibling tools doesn't necessitate additional detail.

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

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

The input schema fully documents the only parameter 'path' with a description. The tool description adds 'from a note' which aligns with the path parameter but offers no additional parameter details. Baseline 3 is appropriate given 100% schema coverage.

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

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

The description uses a specific verb 'Get' with a specific resource 'outgoing links from a note' and explicitly lists what is returned (internal links, external links, tags). This clearly differentiates it from sibling tools like get_backlinks and get_link_graph_data.

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's focus on 'outgoing links' gives clear context for when to use this tool, but it does not explicitly mention alternatives or when-not-to-use. Despite lacking exclusions or comparisons, the context is sufficient for an agent to infer its role.

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. It reveals that the Periodic Notes plugin is required for non-daily periods, which is useful context. However, it does not state whether the operation is read-only, what happens if the note does not exist, or the return format, leaving gaps in behavioral transparency.

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

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

The description consists of two concise sentences with no redundancy. The first sentence states the purpose, and the second adds supported periods and a dependency caveat, both earning their 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?

The description covers the tool's purpose and key dependency. The schema handles parameter descriptions and defaults. Missing details about return value or error behavior are minor for this simple getter tool, especially given the absence of an output schema.

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

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

Schema descriptions cover all 4 parameters (100% coverage), so baseline is 3. The description adds the plugin requirement for non-daily period values, which provides additional semantic context for the 'period' parameter beyond the enum list in the schema.

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

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

The description begins with a specific verb and resource: 'Get a periodic note for a specific period and date.' It explicitly lists the supported period types (daily, weekly, monthly, quarterly, yearly), distinguishing it from sibling tools like get_daily_note which is daily-only.

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

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

The description implies this is the general tool for all periodic notes but does not explicitly compare it to get_daily_note or state when to prefer one over the other. It does note a plugin requirement for non-daily periods, giving some usage context, but lacks explicit alternatives or 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It fails to state whether the tool is read-only, what the return format is (e.g., metadata vs. full content), whether results are sorted by modification time, or what 'recently' means. These are significant gaps for a tool operating on notes.

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

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

The description is two concise sentences with no wasteful wording. The first sentence immediately states the core action, and the second adds a relevant use case, making it well-structured and front-loaded.

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

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

The tool is relatively simple with well-documented parameters, but the lack of an output schema and annotations leaves ambiguity about the return format (e.g., note paths vs. content) and the definition of 'recently.' It is minimally viable but has clear gaps that could be 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?

The input schema has 100% description coverage for both parameters (limit and folder), so the schema already provides the necessary meaning. The description adds no additional parameter context, and the baseline for full schema coverage is 3.

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

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

The description clearly states the tool 'Get a list of recently modified markdown notes,' which uses a specific verb and resource, and the modifier 'recently modified' distinguishes it from generic list tools like list_files and list_all_files. The sentence 'Useful for finding notes you've worked on recently' reinforces its intended purpose.

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

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

The description provides a clear context for use: 'Useful for finding notes you've worked on recently.' However, it does not explicitly mention alternatives or when not to use the tool, so it stops short of a full 5.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It adds value by explicitly stating that both frontmatter tags and inline tags (#tag) are included, which is a meaningful behavioral trait beyond the simple 'get tags' phrasing. It also implicitly indicates a read-only operation.

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

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

The description is exactly two sentences, with the first sentence stating the core purpose and the second adding a clarifying detail about tag sources. No filler or redundant 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 simple read operation with one parameter, the description is mostly complete: it defines the input, the scope, and the sources of tags. It does not describe the return format (e.g., a list of strings), but this is somewhat implied by 'all tags.' The lack of an output schema is not a major gap given the simple nature of the tool.

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

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

The input schema has 100% coverage for the single 'path' parameter, already describing it as 'Path to the note.' The description adds no additional semantic meaning about the parameter (e.g., path format or resolution rules), so it stays at the baseline.

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

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

The description clearly states the action ('Get all tags from a note') and specifies the resource scope (a single note). It distinguishes itself from the sibling tool 'get_all_tags_in_vault' by explicitly limiting to one note, and from 'search_by_tag' which is for finding 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?

The description implies usage for retrieving tags from a specific note but does not explicitly discuss when to use this tool versus alternatives like get_all_tags_in_vault or search_by_tag. No when-not-to-use guidance or alternative references are provided.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose one key behavioral trait—'Only shows directories, not individual files'—and implies a read-only operation via 'Get'. However, it does not mention the default max depth (5) or the maximum (10), the handling of empty paths, or the exact return format (e.g., JSON nesting). These gaps leave some behavior unspecified.

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

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

The description is three short sentences, each serving a purpose: the first states the primary action, the second explains when it's useful, and the third clarifies scope. It is front-loaded with the verb and resource, contains no fluff, and 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?

The tool is relatively simple with two optional parameters and no output schema. The schema documents parameters well, but the description does not specify the exact return structure (e.g., whether it returns nested JSON, markdown, or a list). The phrase 'tree-like structure' is somewhat vague, and without an output schema, the description should explain what the agent will receive. It is adequate but not 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?

The input schema provides complete descriptions for both parameters: path ('Starting directory path. Leave empty for entire vault.') and maxDepth ('Maximum depth to show (default: 5).'). Since schema coverage is 100%, the description adds no additional parameter-specific meaning. A baseline of 3 is warranted.

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

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

The description clearly states the tool's function: 'Get a tree-like structure of folders in the Obsidian vault.' It specifies the resource (folders in the vault) and the output format (tree-like structure). The clarification 'Only shows directories, not individual files' distinguishes it from sibling file-listing tools like list_files and list_all_files.

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

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

The phrase 'Useful for understanding the vault organization' provides clear context on when to use the tool. The note that it 'Only shows directories, not individual files' implies it should be used for folder structure rather than file content listing, though it does not explicitly name alternative tools or list exclusions. This is clear context without explicit alternatives, so a 4 is appropriate.

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 of behavioral disclosure. It does state 'without modifying the rest', which conveys non-destructive behavior to surrounding content. However, it fails to disclose behavior when the heading is missing, when multiple matching headings exist, or what the response looks like, leaving notable gaps 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?

The description is two short sentences with the primary action front-loaded. Every word serves a purpose, and there is no irrelevant filler.

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

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

The description is adequate for the core use case and mentions non-destructive behavior, but with five parameters, no output schema, and no annotations, it leaves edge cases (e.g., missing heading, parameter interactions) unaddressed. It is complete enough for a straightforward task but not for full operational clarity.

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% for all five parameters, so the baseline is 3. The description adds no extra semantic value beyond the schema—it does not explain interactions like createHeadingIfMissing with headingLevel or the default heading level behavior.

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

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

The description uses the specific verb 'Insert content' and identifies the exact target 'under a specific heading in a note'. This clearly distinguishes it from sibling tools like append_to_note or replace_in_note by specifying the insertion point.

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 adding content to specific sections without modifying the rest' provides clear when-to-use context and implies not using it for whole-note edits. However, it does not explicitly name alternative tools or state when not to use it, so it falls short of a 5.

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

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

No annotations are provided, so the description carries full transparency burden. It discloses recursion, starting directory, and extension filtering, but does not mention edge behaviors like handling of non-existent paths, hidden files, symlinks, file ordering, or what happens when maxDepth is reached. These are relevant for a recursive file listing tool.

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

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

The description is concise: two sentences. The first sentence front-loads the core action, and the second covers optional parameters and use case. No filler or unnecessary repetition, making it efficient for an agent to parse.

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

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

The tool is moderately complex with three parameters and no output schema. The description covers the main behavior and options, but it does not mention return format, sorting, edge cases, or explicitly compare against similar sibling tools. This leaves some ambiguity for an agent deciding between 'list_all_files' and 'list_files' or 'get_vault_structure.'

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

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

Schema descriptions cover 100% of the three parameters (path, maxDepth, extensions), so the baseline is 3. The tool description adds minimal value beyond the schema, only restating that one can start from a directory and filter by extension, without additional clarifications on defaults, formats, or boundary behaviors.

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 the action and scope clearly: 'Recursively list all files in the Obsidian vault.' It adds optional directory and extension filtering, which distinguishes it from a plain list. However, it does not explicitly differentiate itself from the sibling 'list_files' tool, so it's not fully unique.

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

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

The description gives context with 'Useful for getting a complete view of vault structure,' which implies a use case but does not provide explicit when-to-use/when-not-to or mention alternative tools like 'list_files' or 'get_vault_structure.' This leaves the agent to infer when this is preferred.

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 adds useful details like directories ending with '/', but does not mention recursion depth, hidden files, or explicitly state it is a read-only operation. Adds some behavioral context but leaves gaps.

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

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

The description is two sentences with no wasted words. The first sentence states the core purpose, and the second adds scope and return format detail. Each sentence earns its place and information is front-loaded.

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

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

For a one-parameter tool with no output schema, the description adequately covers purpose, usage scope, and return format. However, it fails to specify whether the listing is recursive (direct children only) or what ordering/sorting is applied, which is relevant given sibling tools. This leaves a minor completeness gap.

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

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

The schema description covers 100% of the single 'path' parameter, including its relative-to-root semantics and that empty means root. The description does not add parameter-specific meaning beyond that, so the baseline of 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 clearly states the tool lists files and folders in the Obsidian vault, with a specific verb and resource. It also notes it can list the root or a specific folder, which adds scope. However, it does not explicitly distinguish this tool from the sibling 'list_all_files', so it stops short of full 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?

The description gives context by saying it can list the root directory or a specific folder, implying when to use it. But it does not provide explicit guidance on when not to use it or mention alternatives like 'list_all_files' or 'get_vault_structure'. Usage is implied rather than clearly delineated.

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. The term 'List' clearly indicates a read-only operation with no side effects. It also scopes the behavior to 'built-in templates' and clarifies that descriptions are included. This is sufficient for such a simple 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?

One concise sentence that immediately states the action and outcome. No superfluous words or repetition.

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, no-output-schema tool, the description is complete: it specifies the scope ('all available built-in templates'), the type of data returned ('their descriptions'), and the action. No additional context is needed for an agent to invoke it correctly.

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

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

The tool has zero parameters, so the baseline of 4 applies. There is no parameter information needed, and the description adds no ambiguity.

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

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

The description uses a specific verb ('List') and a clear resource ('all available built-in templates'), and explicitly mentions the return content ('their descriptions'). This cleanly differentiates it from sibling tools like create_note_from_template and 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 guidance is provided about when to use this tool versus alternatives. For example, it doesn't state that this is the only tool for listing built-in templates or that other list tools (list_files, get_vault_structure) serve different purposes.

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

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

With no annotations provided, the description carries the full burden. It discloses the behavioral outcome (making the note visible and active), but does not mention edge cases, failure modes, or prerequisites such as Obsidian being running. The disclosure is adequate for a simple tool but lacks depth.

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

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

The description is two concise sentences that front-load the action and include the key behavioral effect. Every word contributes to understanding, with no unnecessary jargon or repetition.

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

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

For a simple tool with one required parameter and no output schema, the description adequately covers the purpose and effect. It lacks details on error behavior or the newPane option's visual effect, but these are partially addressed by the schema. Overall, it is reasonably complete for the tool's simplicity.

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

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

Schema description coverage is 100%, so the parameters are already well-documented in the schema. The tool description adds no extra semantic detail about 'path' or 'newPane', so it holds the baseline score for high schema coverage.

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

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

The description clearly states the tool's purpose: opening a note in the Obsidian user interface, making it visible and active. The verb 'Open' is specific, and the resource ('note') and context ('Obsidian user interface') are explicit. This distinguishes it from siblings like read_note or delete_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?

The description implies usage for UI interaction, but does not explicitly mention when to use this tool vs alternatives like read_note. The phrase 'in the Obsidian user interface' provides clear context, but there is no direct comparison to siblings or stated exclusions. Thus, usage is implied rather than explicitly guided.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It does not mention that this is a mutating operation, what happens if the note doesn't exist, whether existing content is preserved, or any permission requirements. The only behavioral detail is 'after frontmatter', which is useful but insufficient for a destructive/modifying 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 two sentences and immediately states the core action and placement. The use cases are illustrative without being verbose. Every word earns its place, making this concise and well-structured.

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

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

For a tool with no output schema and no annotations, the description covers the primary action but omits important operational context such as failure behavior (missing file, permissions), whether newlines are handled by default, and any side effects. It is sufficient for a basic understanding but not fully complete for safe autonomous 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 coverage is 100%, with each parameter already described. The description adds minimal extra meaning beyond the schema, though it clarifies the purpose of 'content' (prepending at the top) and mentions the frontmatter interaction. This meets the baseline for schema-heavy cases but does not go beyond.

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

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

The description clearly states the action ('prepend content to the beginning of a note'), specifies the resource (note), and provides context ('after frontmatter'). It also gives concrete use cases (headers, timestamps, notices) and implicitly distinguishes itself from sibling tools like append_to_note by emphasizing 'beginning'.

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 'to the beginning' and 'after frontmatter' establishes clear placement context, distinguishing it from append_to_note and insert_under_heading. However, it does not explicitly name alternatives or state when not to use this tool, so it falls short of the top examples that provide explicit when/when-not guidance.

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

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

The description discloses the key behavior of appending to a file and adding a timestamp, which is valuable given there are no annotations. However, it does not mention potential side effects such as whether the file is created if missing, overwriting risks, or permission requirements. For a write operation, more transparency would be helpful.

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

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

The description is two sentences long, front-loaded with the primary action and quickly covers the use case. Every word adds value, and there is no redundancy.

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

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

The tool is simple and the schema fully documents parameters, but the description lacks information about return values, behavior when the capture file is missing, or error scenarios. Since there is no output schema and no annotations, a more complete description would add operational details.

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

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

The input schema already provides 100% coverage with descriptions for all parameters, including defaults and enums. The description adds only a passing mention of the capture file and timestamp, which mirrors the schema. Thus, the baseline of 3 is appropriate.

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

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

The description clearly states the tool captures a thought, idea, or note and appends to a designated capture file with a timestamp, which specifies both the action and resource. It implies an inbox-style use case but does not explicitly contrast with sibling tools like append_to_note or create_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?

The phrase 'Great for inbox-style note capture' provides implied context for when to use this tool, but there are no explicit when-to-use/when-not-to-use rules or mentions of alternatives. It lacks guidance on choosing this over similar append/create 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?

The description discloses that it returns full content including frontmatter, and mentions a 'parsed sections' capability, adding some behavioral context. However, it does not explain what 'parsed sections' means or how to enable them, and since no annotations are provided, more detail would be expected.

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, concise sentence that front-loads the primary purpose ('Read the content of a note') and quickly adds return details. No unnecessary words or repetition.

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

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

For a simple read tool with no output schema, the description gives a basic sense of the return value (full content with frontmatter, or parsed sections). However, it lacks details on error handling, the meaning of parsed sections, and how this tool fits with other read/search tools, leaving gaps for an AI agent.

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 provides full descriptions for all three parameters, so the baseline is 3. The description adds no additional meaning about parameters such as includeStats or includeFrontmatter beyond what the schema already states.

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

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

The description clearly states the tool reads note content from the Obsidian vault, with a specific verb and resource. It distinguishes itself from siblings like get_frontmatter by mentioning full content and parsed sections, though not explicitly naming 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?

No guidance is provided on when to use this tool versus alternatives such as get_frontmatter, search_notes, or get_file_stats. There is no mention of suitable use cases or 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?

With no annotations provided, the description carries the full burden. It discloses the frontmatter-only limitation, which is useful, but does not mention side effects like whether the tool rewrites the file, errors on missing tags, or handles duplicate tags.

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

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

The description is two short sentences that are front-loaded and directly to the point. Every word adds value and there is no unnecessary 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 tool with two well-described parameters and no output schema, the description is sufficient. It clearly states the action and its limitation, making it easy for an agent to select and invoke correctly.

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

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

Schema coverage is 100%, so the parameters (path and tags) are fully described there. The description adds no additional parameter semantics beyond what the schema already provides.

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

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

The description clearly states the tool removes tags from a note's frontmatter, with a specific verb and resource. It also distinguishes itself from removing inline tags, which clarifies its exact scope.

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 states what the tool does and explicitly notes it only removes frontmatter tags, not inline tags, giving a clear exclusion. However, it does not name sibling tools like add_tags or get_tags as alternatives for other tag operations.

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 mentions 'replace' (implying a write) and 'without replacing entire content' (targeted nature), but it does not disclose whether the note is modified in-place, whether the operation is reversible, what happens if no match is found, or that replaceAll defaults to false (only first occurrence). 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?

The description is two sentences, front-loaded with the primary action, and every word earns its place. There is no redundant information or filler.

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

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

Despite a simple tool with fully documented parameters, the lack of any annotations means the description must cover behavioral essentials. It does not state that this is a mutating operation (beyond the verb), what the return value is, or important edge-case behavior like no-match or multiple occurrences. The description is too thin for a write tool operating on files.

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

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

The input schema has 100% parameter coverage, so the baseline is 3. The description adds no additional parameter context beyond what the schema already provides, such as behavior of replaceAll or requirements for the path. It therefore does not exceed the baseline.

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

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

The description uses a specific verb+resource combination ('Find and replace text in a note') and clearly differentiates from siblings like read_note, update_note, and append_to_note by emphasizing targeted edits rather than full content replacement.

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 'Useful for making specific edits without replacing the entire content' implies a use case and distinguishes it from full-file update tools, but it does not explicitly name alternative tools or state when not to use this tool. Guidance is present but not fully explicit.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It reveals that tags are searched both in frontmatter and inline content, which is non-obvious and adds value beyond the schema. It also states the multi-tag behavior, though it omits the optional 'matchAll' toggle; however, the schema covers that parameter.

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

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

The description is concise, consisting of three short sentences. It is front-loaded with the main purpose, followed by key behavioral details. Every sentence contributes meaningful information with no redundancy or filler.

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

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

Given the tool's simplicity (2 parameters, no output schema), the description covers the essential aspects: purpose, tag locations, and multi-tag behavior. It does not specify the return format or explicitly mention the 'matchAll' option, but the latter is in the schema, and for a search tool, the missing return description 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?

Schema description coverage is 100% for both parameters, so the baseline is 3. The description adds some context about tag locations (frontmatter/inline), which indirectly clarifies what the 'tags' parameter matches, but it does not add detailed parameter-level semantics beyond the schema.

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

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

The description clearly states the tool's purpose with a specific verb and resource: 'Find all notes that have specific tags.' It also provides important details about tag locations (frontmatter or inline) and multi-tag behavior, distinguishing it from sibling search tools like 'simple_search' or 'get_all_tags_in_vault'.

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

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

The description gives clear context for when to use the tool: when you need to find notes by tags, including notes with tags in frontmatter or inline. It does not explicitly name alternatives or exclusions, but the purpose is self-evident and different from other search 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 burden. It only states the core operation without disclosing edge cases, matching behavior, output format, or consequences of omitting the query. Minimal behavioral detail.

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

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

The description is two concise sentences, front-loaded with the core action and no extraneous information. Every word earns its place.

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

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

Given the large set of sibling search tools and lack of annotations, the description is not complete enough. It does not explain the output format, distinguish from similar tools, or clarify behavior when query is omitted, leaving the agent to infer important context.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds that folder path filtering and text search are combined, which aligns with the parameters but does not provide significant meaning beyond what the schema already states.

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

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

The description clearly states the tool searches for notes within a specific folder and explicitly combines folder path filtering with text search. This distinguishes it from other sibling search tools like search_notes or search_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?

The description implies usage for folder-scoped searches but does not explicitly state when to use this tool versus alternatives. There is no mention of exclusions or references to sibling search 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 burden of behavioral disclosure. It mentions that results include relevance scores and supports operators, but does not clarify pagination, sorting, side effects (though search is clearly read-only), or error behavior. This is adequate but not rich.

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

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

The description is two sentences, front-loaded with the core action, and contains no fluff. Every sentence contributes useful information.

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

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

There is no output schema, so the description appropriately mentions return format (files with relevance scores). It covers the core purpose and query syntax, but could be more complete by noting default limit behavior and when to use it relative to sibling search tools. Still, it is largely sufficient for an agent to select and invoke the tool.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds examples of query syntax that also appear in the schema, offering no meaningful extra meaning beyond the parameter descriptions.

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

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

The description clearly states the tool's purpose: searching notes in the Obsidian vault using Obsidian's query syntax. It lists supported operators, distinguishing it from simpler sibling tools like search_by_tag or simple_search.

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

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

The description implies usage for queries requiring Obsidian's full syntax but does not explicitly mention when to choose this over alternatives such as simple_search or search_by_tag. No exclusion criteria or context is given.

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 present, so the description carries the full burden. It discloses the core behavior (returns snippets/context) and the practical benefit (avoid opening each note). It does not, however, explain ordering, matching semantics, or behavior with edge cases, making the transparency adequate but minimal.

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

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

The description is two concise sentences that immediately convey function and use case, with no redundant or filler content.

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

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

For a relatively simple search tool with full schema coverage, the description is sufficient to understand what it does and when to use it. It could add more distinction from sibling search tools or describe result format, but overall it is complete enough.

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

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

The input schema provides complete descriptions for all three parameters, including defaults and ranges. The tool description adds no extra parameter information, so the baseline score of 3 applies.

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

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

The description clearly states that the tool searches notes and returns results with content snippets/context, which is a specific verb+resource+output. It hints at differentiation from plain search tools by emphasizing snippets, but does not explicitly distinguish it from sibling search tools like search_notes.

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

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

The description includes a concrete use case: 'useful for previewing search results without opening each note.' This implies when to use the tool. However, it does not explicitly mention when not to use it or name alternatives, so it stops short of full guidance.

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

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

With no annotations provided, the description carries the full burden. It discloses the create-if-missing behavior, which is valuable. However, it does not mention that setting a value overwrites an existing property, that null removes the property (though the schema covers this), or any side effects such as file modification permissions. This is partial 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?

The description is two sentences and exactly as long as needed. It front-loads the core action and adds one key behavioral detail with zero waste.

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 setter with no output schema and full parameter coverage in the schema, the description is mostly complete. It conveys the essential behavior (single property, create if missing). It could be more complete by mentioning overwrite semantics or return behavior, but given the simplicity and schema richness, it is adequate.

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

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

The input schema covers 100% of parameters with descriptions, so the baseline is 3. The tool description adds no additional parameter-specific meaning beyond what the schema already provides. The schema's value description includes the null-to-remove behavior, which the description does not mention.

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

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

The description clearly states the action ('Set a single frontmatter property in a note') with a specific verb and resource. The qualifier 'single' distinguishes it from sibling tools like update_frontmatter, and the additional phrase 'Creates the property if it doesn't exist' adds behavioral clarity.

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

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

The description implies when to use the tool (when setting exactly one property, and it can create if missing) without explicitly naming alternatives or exclusions. The 'single' qualifier provides clear context but does not mention 'update_frontmatter' or other related tools, so it falls short of a 5 but is above minimal guidance.

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

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

It discloses the exact-match and case-insensitive behavior, which is useful. But with no annotations, the description should also mention whether the operation is read-only and what the return format is. It leaves these 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 sentences are used effectively: the first states scope, the second adds behavior and use case. No fluff, information is front-loaded, and 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?

The tool is simple with only two parameters, but there is no output schema, so the description should explain what the search returns (e.g., matching note names). It also does not position itself against siblings like search_with_context or search_notes, leaving a slight gap in context.

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

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

Schema coverage is 100% with descriptions for both query and limit. The description adds crucial semantics to the query parameter by specifying 'exact text' and 'case-insensitive', which is not in the schema description. This goes beyond the baseline.

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

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

The description clearly states the tool's action and scope: 'Simple text search across all notes in the vault' and 'Searches for the exact text (case-insensitive)'. This differentiates it from sibling tools like search_by_tag or search_in_folder, making the purpose unambiguous.

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

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

It provides a clear use case: 'Good for finding specific phrases or terms.' However, it does not explicitly mention alternatives or when not to use this tool, despite many sibling search tools. The context is clear but lacks 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?

With no annotations provided, the description carries the burden of behavioral disclosure. It discloses the additive/updating nature and preservation of unspecified fields, but does not cover error cases, prerequisites (e.g., note existence), or side effects on note content beyond frontmatter.

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

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

The description is two sentences, front-loaded with the action, and every sentence adds value. There is no fluff or redundancy.

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

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

For a simple mutation tool with 2 parameters and no output schema, the description covers the core behavior sufficiently. It omits return value/error information, but this is common for write operations and does not severely impact understanding.

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 parameters are already documented. The description adds meaningful semantics by explaining how the 'properties' parameter behaves (merging, preserving unspecified fields), which helps correct invocation.

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

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

The description clearly states 'Update frontmatter fields in a note' with a specific verb, resource, and scope. It explicitly mentions adding or updating fields, which distinguishes it from related tools like get_frontmatter or update_note.

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

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

The description clarifies the merge behavior ('Existing fields not specified are preserved'), implying when to use this tool over a full overwrite. It does not explicitly mention alternatives or exclusions, but the context is clear enough for selection.

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 does disclose the most important behavioral trait—that it replaces the entire content—which signals potential destructiveness. However, it omits other context such as behavior when the note is missing, return value, or how frontmatter is handled; the schema partially covers frontmatter defaults, but the description itself adds little beyond the replacement fact.

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 consists of two short sentences that immediately state the action and the key behavior. It is concise, front-loaded, and contains no filler or redundant 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 mutation tool with no annotations and no output schema, the description provides the essential purpose and the destructive full-replacement behavior, but it lacks guidance on when to use this tool relative to several similar update tools, error conditions, or expected return values. The minimalism leaves some gaps, so it is adequate but not comprehensive.

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 all four parameters, including defaults and explanations for updateModified and preserveFrontmatter. The tool description adds no additional parameter meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.

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

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

Description uses a specific verb ('update') with a clear resource ('content of an existing note') and clarifies the core behavior ('replaces the entire content'). This distinctly separates it from sibling tools like append_to_note, prepend_to_note, and replace_in_note, which perform partial modifications.

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 'existing note' and 'replaces the entire content' gives clear context for when this tool is appropriate: full-content replacement rather than partial edits. It does not explicitly name alternatives or exclusion criteria, but the behavior is distinctive enough to guide selection among the many sibling tools.

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

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

With no annotations, the description carries the full burden. It discloses that the tool tests MCP-Obsidian communication and is a status check, implying read-only, but it does not specify what happens on failure or whether any state changes occur. This is adequate but not comprehensive.

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

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

The description is two sentences, front-loaded with the core action, and contains no filler. Every word adds value.

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

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

For a zero-parameter tool, the description is compact, but since there is no output schema or annotations, it doesn't clarify what 'server status information' includes (e.g., connected/disconnected, version). An agent would benefit from knowing the expected return shape.

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

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

The tool has zero parameters, so the baseline of 4 applies. The empty schema and description are consistent; there is nothing additional to document.

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

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

The description clearly states the tool checks the connection to Obsidian and gets server status, using a specific verb and resource. This distinguishes it from sibling tools, which are file/note operations, searches, and commands.

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 says 'Use this to verify the MCP server can communicate with Obsidian,' providing clear when-to-use context. It doesn't explicitly contrast with alternatives, but none are relevant for a status check, so no exclusions are needed.

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