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

With no annotations, the description carries the behavioral disclosure burden. It discloses the positional behavior (append at end), the mutating nature of appending, and a concrete failure condition when the note does not exist. It does not describe the return value or potential side effects like newline handling, but it is sufficiently transparent for a simple 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?

Two short sentences contain no filler, and the primary action and critical failure condition are front-loaded. 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?

For a two-parameter mutation tool with no output schema and no annotations, the description covers what it does, where it does it, and when it fails. A slightly richer description could mention what is returned on success, but that is not required for correct invocation given the simple side-effect behavior.

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

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

Schema description coverage is 100% and the schema already documents path and content precisely. The description adds little beyond restating the append-to-end behavior already present in the content parameter description, so it meets the baseline but does not 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 uses a specific verb ('Appends') and resource ('end of an existing note') and clearly distinguishes this from create_note by requiring an existing note and by appending rather than creating. The failure condition reinforces the 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?

It states a clear usage context: use this to add text to the end of an existing note, and it warns that nonexistent notes cause failure. It does not explicitly name sibling alternatives such as create_note for new notes, so it stops 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?

With no annotations provided, the description carries the full burden and does substantial work: it discloses the creation action, the failure mode when the note exists, the overwrite escape hatch, and automatic creation of intermediate subfolders. These are non-obvious behaviors beyond what the tool name alone conveys.

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

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

Three short sentences with no filler. The core action comes first, followed by the failure condition and the subfolder behavior. Every sentence adds useful operational 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?

Covers the action, failure condition, overwrite behavior, and subfolder creation, which is nearly complete for a straightforward create tool. The main gap is the lack of return/response information, but since there is no output schema, the description is otherwise sufficient.

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, but the description adds meaning beyond the schema: it explains that the path parameter can include intermediate subfolders that will be created if needed, and it clarifies the practical effect of 'overwrite=true' on the failure behavior. This compensates above 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?

States a specific action ('Creates a new note') and resource ('in the vault'), and its semantics are clearly distinct from sibling tools like read_note, append_to_note, and delete_note. The phrase 'Fails if the note already exists, unless overwrite=true' reinforces that this is a create-not-update operation.

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 mechanics (creation, overwrite behavior, subfolders) but no guidance on when to choose this tool versus alternatives such as append_to_note for existing notes or search_note for discovery. There is no explicit 'use when' / 'use instead' 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, the description carries the behavioral burden. It clearly discloses the destructive action and the confirm=true guardrail, but it does not state whether deletion is permanent or reversible, what happens to backlinks, or any side effects.

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

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

The description is a single front-loaded sentence with no filler. Every word earns its place, and the key guardrail is mentioned immediately after the core purpose.

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 destructive two-parameter tool without annotations or an output schema, the description covers the essential action and confirmation requirement but omits important context such as permanence, error cases, or whether the operation can be undone.

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 no further meaning beyond restating confirm=true, while path's relative-vault semantics are already fully documented 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 uses a specific verb and resource ('Deletes a note from the vault'), making the tool's purpose unambiguous and clearly distinct from siblings like list_notes, read_note, and 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 description implies this tool is for deleting a note and explicitly notes that confirm=true is required, but it does not state when to use it versus alternatives or provide exclusions such as checking with read_note first.

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 makes the read-only, listing nature clear and restricts matches to [[wikilink]] references, but it does not disclose edge cases like missing notes, output format, or ordering.

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

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

A single, front-loaded sentence communicates the exact behavior with zero filler. Every word earns its place, and the wikilink qualifier adds precision without bloat.

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

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

For a simple one-parameter listing tool, the description is adequate: it names the resource, the filtering relationship, and the data type involved. The lack of an output schema is mitigated by the straightforward 'lists the notes' phrasing, though exact return formatting remains unspecified.

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%, and the description does not add meaningful semantics beyond the path parameter. The 'given note' wording connects the parameter to the tool's purpose, but the schema already provides the necessary definition of path as a vault-relative path.

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

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

The description states a specific verb ('Lists'), a clear resource ('notes in the vault'), and a precise relationship ('reference the given note via [[wikilink]]'). This makes the tool's purpose distinct from siblings like list_notes or 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 implies the use case: find inbound wikilink references to a specific note. However, it does not explicitly mention alternatives or when not to use this tool, so an agent must infer contrast with siblings rather than being told.

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 full burden. It discloses that hidden folders are ignored, which is a behavioral trait an agent must know. It also indicates it only lists .md files. This is beyond the basic operation, though it doesn't mention sorting, depth, or recursion, which are minor.

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, with no fluff. The primary action and restriction are front-loaded, and the hidden-folder note is appended as a caveat. 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?

For a simple listing tool with one optional parameter and no output schema, the description is complete. It covers the core behavior, file type, and hidden-folder exclusion. It doesn't specify return format or pagination, but these are likely inferable for a list operation, and no annotations are needed.

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 single parameter 'folder' is fully documented in the schema. The description adds the meaning of 'subfolder relative to the vault' and default root behavior, which is helpful but not extensive. 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 'Lists', the resource 'vault's notes (.md)', and the optional restriction to a subfolder. It also explicitly notes the file extension and hidden folder exclusions, which distinguishes it from siblings like read_note and 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 implies usage: it lists notes, optionally in a subfolder. It does not explicitly state when to choose this over search_notes or read_note, but the mention of 'listing' and 'subfolder' gives clear context. No alternatives are named, but the purpose is distinct enough.

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 conveys a non-mutating read and names the returned data, which is helpful, but it does not describe error behavior for missing paths, how wikilinks are represented, or whether any normalization occurs.

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, compact sentence with the active verb front-loaded and no filler or redundancy. Every word contributes meaningful information about the tool's 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?

For a tool with one well-documented required parameter, the description and schema together are sufficient for an agent to make a correct call. The lack of an output schema is mitigated by explicitly listing the returned components, though error conditions and path-resolution details remain unspecified.

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 parameters, including a relative path example, so the description adds no additional parameter meaning beyond the schema. Per the baseline for high schema coverage, this is adequate.

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 starts with a specific verb, 'Reads', and a clear resource, 'a vault note', so the core action is unambiguous. It further enumerates what is returned (frontmatter, body, wikilinks), which clearly differentiates it from sibling tools like list_notes, search_notes, and get_backlinks.

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 this tool is for retrieving a note's content, and the sibling names make alternatives inferable. However, it never explicitly states when to use this tool versus search_notes, list_notes, or get_backlinks, nor does it mention any exclusions or preferred conditions.

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 explaining behavior. It clearly states the operation is a search across all notes and discloses the return fields (file, line, snippet), which is meaningful behavioral context. It does not mention edge cases like no matches or whether hidden files are included, 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?

A single sentence with no filler, front-loading the action and scope and then stating the return shape. 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?

For a search tool with three well-documented parameters, this description is nearly complete: it names the resource, scope, and output shape. It could specify search semantics (e.g., substring vs. regex) or behavior on no matches, but the description plus schema gives an agent enough to call it correctly in most cases.

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

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

Schema coverage is 100%, so each parameter is already documented in the schema. The description adds no additional meaning to the parameters themselves, 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?

States a specific verb and resource: 'Searches text across all notes in the vault.' It also clarifies the output shape (file, line, snippet), which distinguishes it from sibling tools like list_notes or read_note. An agent can immediately understand what this tool does.

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 (when you need to find matching text across notes), but it does not explicitly contrast it with sibling tools such as get_backlinks or read_note, nor does it state when not to use it. The scope 'across all notes in the vault' provides some usage context but no exclusions or alternatives.

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