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 states only that content is appended to the end of a note; it does not mention behavior when note_id does not exist, whether content is inserted verbatim, newline/formatting handling, idempotency, permissions, or failure modes.

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

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

The description is two short sentences with no filler. The first sentence front-loads the core action, and the second adds a useful usage preference. 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 two-string-parameter operation, the description covers the essential intent and the output schema covers the return shape. Still, with no annotations and no parameter-level detail, some context about the expected existence of the note and error/edge-case behavior is missing.

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

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

Schema description coverage is 0%, and the description does not explain either parameter beyond what their names imply. It gives no additional meaning about note_id validity, content format, or constraints, so it fails to compensate for the missing parameter documentation.

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

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

The description uses the specific verb 'Append' with the resource 'note' and the position 'end', clearly distinguishing it from update_note, patch_note, or create_note. The phrase 'Prefer over full rewrites' further reinforces what this tool is for compared to rewrite-style siblings.

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

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

The instruction 'Prefer over full rewrites' gives an explicit usage preference, signaling that this tool should be chosen when adding content rather than replacing a note. However, it does not name sibling tools or specify when to avoid append (e.g., when reordering or replacing content), 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 provided, the description carries the full burden. It discloses that questions may not be answered immediately and are filed for future retrieval, which is useful. However, it does not state whether the tool has side effects (e.g., creating a record), whether it is read-only, or any authentication or rate-limit considerations. The filing behavior hints at mutation but is not explicit.

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 filler. It front-loads the action and adds the key behavioral nuance about filing unanswered questions. 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 tool with one parameter and an output schema, the description covers the main behavior (answer from vault or file for future). It lacks explicit mention of side effects or whether it is safe to call repeatedly, but given the presence of an output schema, return format is covered. Overall, it is adequate but not exhaustive.

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

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

Schema description coverage is 0%, so the description should compensate. The single parameter 'question' is self-explanatory as a string, but the description adds no detail about format, length, language, or constraints. Given the low coverage, the description fails to add any parameter-specific meaning beyond what the schema already trivially 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 a specific verb ('Ask') and resource ('the librarian'), and specifies the behavior: answered from the vault when possible, otherwise filed as an automated question. This distinguishes it from the note-focused sibling tools like search_notes, which have a different 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 gives clear context for when to use this tool (when you have a question that might be answered from the vault) but does not explicitly contrast it with alternatives like search_notes or give any 'use instead' guidance. It implies a distinct role but leaves exclusions to inference.

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

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

With no annotations, the description must carry the behavioral burden. It does disclose the folder-creation side effect and the markdown format, which are useful. However, it omits error behavior, idempotency, and how the tool handles an existing note_id, so some significant behavioral gaps remain 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?

Two short sentences with no filler. The action is stated first, and the key behavioral detail (folder creation) is clear and concise. 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 tool with two parameters and an output schema, the description covers the core action and a notable side effect. It doesn't address conflict or error scenarios, but given the simplicity and the presence of an output schema, the definition is nearly 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 0%, so the description must compensate. It adds meaning to note_id by explaining that folders are derived from the id path, which is valuable. The content parameter is not mentioned, but its default of '' and the word 'note' make it largely self-explanatory.

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

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

The description states a specific verb ('Create') and resource ('markdown note'), and it adds a distinctive detail: folders are created from the id path. This distinguishes it clearly from the many sibling tools, even though it doesn't explicitly name alternatives.

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

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

The usage is implied by the name and verb: use when you want a new note. However, there is no explicit when-to-use or when-not-to-use guidance, such as when to prefer append_note or patch_note over create_note. It's sufficient but not directive.

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 and it delivers the key trait: deletion is soft and moves the note to trash, and the action is reversible via restore_note. It does not mention permissions or side effects on links, but the output schema can cover return details.

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

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

One compact sentence with no filler; the action and the key caveat are both front-loaded and the restore pointer is tucked cleanly into a parenthetical.

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

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

For a single-parameter mutation with an output schema and no annotations, the description covers the essential purpose, behavior, and undo path. Minor details like note_id sourcing or trash behavior after restore are absent, but not critical for invoking the tool correctly.

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

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

There is only one parameter, note_id (string), and the description indicates it identifies the note being soft-deleted, which is reasonable but adds little format or provenance guidance. Since schema description coverage is 0%, the description only partially compensates, but the single obvious parameter limits the 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?

Description uses specific verb 'soft-delete' with resource 'note' and destination 'trash', making the operation unmistakable. It also names restore_note as the inverse, distinguishing it from a permanent delete and from the restore sibling.

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

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

The soft-delete wording clearly implies this is the right tool when a note should be removed but kept recoverable. The parenthetical points to restore_note for reversal, though it does not explicitly state when not to use it or compare with move_note/update_note.

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

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

No annotations are provided, so the description carries the full burden. It discloses the core behavior (resolving inbound wiki-links) but does not mention response contents, sorting, deduplication, or any edge cases. The output schema may compensate for return-value details, but the description alone is thin.

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, with no filler or repetition. Every word contributes to the core meaning, and the structure is appropriate for such a simple tool.

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

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

For a one-parameter retrieval tool with an output schema, the description conveys the essential input and function. It is nearly complete, though it would benefit from explicitly identifying note_id and contrasting with get_outgoing.

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

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

With 0% schema description coverage, the description should explicitly map note_id to the target note. The phrase 'this one' only vaguely references the parameter and does not clearly explain the expected ID format or role, leaving the single parameter under-documented.

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 returns notes linking to a target note via [[wikilinks]]. It implies an inbound-link operation that contrasts with get_outgoing, though it does not explicitly name the sibling tool.

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

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

No guidance is given about when to use this tool versus get_outgoing or other note-lookup tools. The only contextual hint is the phrase 'linking to this one,' which implies inbound links, but no exclusions or alternatives are stated.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only describes the resource (frontmatter) and gives no indication of side effects, read-only nature, return format, or error behavior. This is a critical gap for a tool that is presumably a read operation.

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

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

The description is extremely brief, but brevity here is under-specification rather than conciseness. It is a single incomplete sentence that fails to convey essential information. While front-loaded, it does not earn its place because it says almost nothing useful.

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, output schema), the description is still incomplete. It does not state that the tool returns frontmatter, nor does it clarify what the 'etc.' means. An agent would struggle to know what the tool actually does beyond inference from the title and siblings.

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

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

Schema description coverage is 0%, and the description does not mention the sole parameter (note_id). While the parameter name is self-explanatory as an identifier, the description adds no context about the parameter's role or expected format, leaving the agent to rely solely on 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 is a noun phrase ('A note's YAML frontmatter') that does not explicitly state the action of 'getting' or 'retrieving'. It names the resource but lacks a verb, making the tool's purpose ambiguous. The title 'Get Frontmatter' provides some clarity, but the description itself is a fragment.

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

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

There is no guidance on when to use this tool versus alternatives like set_frontmatter or read_note. The description does not mention any context, preconditions, or exclusions, leaving the agent to infer usage purely from the tool name.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states what the result relates to ([[Link]] targets) and does not mention whether the operation is read-only, what shape the output takes, or how edge cases like missing notes are handled.

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 very short and contains no fluff, which is appropriate for a simple getter tool. However, the phrasing is grammatically awkward and would benefit from a clearer subject-verb structure.

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 presence of an output schema reduces the need to describe return values, and the single required parameter is simple. Still, without annotations and without an explicit statement that note_id identifies the note to inspect, the description is minimally viable rather than 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 schema provides only a required note_id string with zero description coverage. The description implicitly connects 'a note' to the note_id parameter, suggesting the caller must identify the source note, but it never names the parameter or explains what counts as a valid note_id.

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 identifies the resource as the [[Link]] targets that a note points to, which clearly conveys the concept of outgoing links. It is not a tautology and the meaning is recoverable, though it lacks an explicit verb like 'returns' or 'lists'.

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 no guidance on when to choose this tool over alternatives such as get_backlinks or search_notes. There are no exclusions, prerequisites, or mention of sibling tools, so the agent must infer the usage context from the name alone.

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

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

The description transparently discloses that entries are queued as pending and reviewed (applied/approved/rejected) before vault changes, which is a key behavioral trait beyond what the schema shows. It does not mention permissions, error handling, or other side effects, but given no annotations are provided, the description covers the most critical aspect of delayed application.

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

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

The description is well-structured with a clear opening metaphor, a purpose explanation, and a kind list. It is front-loaded with the key idea and remains readable. It is slightly verbose but not excessively so, earning a strong score.

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 purpose, the queue/review flow, and kind values, but omits note_id semantics and any additional context like prerequisites or failure modes. Since an output schema exists, return values are not needed, but the description could be more complete in explaining all parameters and 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?

The description explains 'kind' as one of edit|missing|request|question, and 'body' as the information or source. However, it does not explain 'note_id', leaving it ambiguous. With 0% schema description coverage, the description should cover all parameters, so this partial coverage is a gap.

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

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

The description clearly states the tool's purpose: queue feedback for the librarian to apply later. It identifies the verb+resource ('queue feedback') and explains the self-learning loop. However, it does not explicitly differentiate from sibling tools like update_note or create_note, so it falls short of a perfect score.

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 context that this is for feedback that is reviewed before vault changes, implying it is for corrections/facts rather than direct modification. However, it does not explicitly state when to use this tool versus alternatives, nor does it name specific siblings or provide exclusion criteria. The guidance is implicit rather than explicit.

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

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

With no annotations, the description carries the burden of behavior disclosure. It usefully states that only direct children are returned and that the result consists of subfolders and note ids, signaling non-recursive behavior and a lightweight output format. It does not mention ordering, hidden entries, or edge cases, but the key behavioral scope is clear.

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 immediately states the core behavior with no filler or redundancy. It is well-suited for quick agent scanning.

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 an output schema, the core operation is adequately described. The main gap is the meaning and usage of the 'prefix' parameter, which is essential for targeting a specific folder, and no alternative tools are referenced. This makes the definition 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 has one parameter, 'prefix', with no description and 0% schema description coverage. The tool description never mentions 'prefix', so its meaning, format, and effect on the folder being listed are left entirely to inference. The name and default '' give only a weak clue.

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 resource (a folder) and the scope of results ('Direct children', 'subfolders and note ids'), which distinguishes it from list_notes or search_notes by focusing on a shallow directory listing. It lacks an explicit verb, but the title 'List Directory' supplies the action.

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 'Direct children of a folder' implies when to use this tool: when you need a shallow listing of a folder rather than full note content. However, it does not name any sibling tool or provide explicit when-not-to-use guidance, so the usage 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 provided, the description carries the full burden of behavioral disclosure. It mentions 'sorted' and 'pagination', which are behavioral traits, and implies a read-only operation by using 'list'. However, it does not explicitly state that it has no side effects, nor does it describe defaults or error behavior. The read-only nature is inferred, not stated.

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 filler. It front-loads the core function and packs all essential information efficiently. Every word adds value, making it an exemplary model of conciseness.

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

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

For a simple list tool, the description covers the essentials: it returns ids, is sorted, supports a folder prefix, and includes pagination. The output schema likely describes the exact return shape, so missing details like sort order direction are acceptable. The lack of explicit safety info is a minor gap given the read-only nature implied by 'list'.

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?

Since schema description coverage is 0%, the description must compensate for parameter meaning. It does so by mapping 'folder prefix' to the 'prefix' parameter and 'pagination' to 'limit' and 'offset'. However, it does not explain how pagination works (e.g., offset semantics, limit defaults) or the exact effect of the prefix. This provides some value but leaves details to be inferred from the schema types and defaults.

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 ('List'), the resource ('note ids'), and key attributes ('sorted', 'optional folder prefix', 'pagination'). This distinguishes it from siblings like read_note or list_directory, which target different resources or actions. The phrasing is specific and leaves no ambiguity about what the tool returns.

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 through its clear purpose but does not explicitly state when to choose this tool over siblings like list_directory or read_notes. No exclusions or alternative comparisons are provided. The context is reasonably clear for a basic list operation, but explicit guidance is absent.

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 full responsibility for behavioral disclosure. It merely says 'Move/rename a note' without explaining side effects such as whether the old identifier becomes invalid, whether links are updated, or whether the operation is reversible.

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

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

The description is concise and front-loaded, with no wasted words. However, it is under-specified rather than effectively concise, providing only the barest statement of 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?

The tool has no annotations, no parameter descriptions, and a 0% schema coverage. The minimal description leaves important operational context unclear, such as what new_id represents, whether the move crosses directories, and what happens to the original note.

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

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

Schema description coverage is 0%, and the description does not explain either parameter. 'new_id' could mean a new path, new filename, or new identifier, and 'note_id' has no format or context provided. The description fails to compensate for the missing schema documentation.

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

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

The description clearly states the action (move/rename) and the resource (a note). This distinguishes it from content-editing tools like update_note and patch_note, while aligning with its sibling set.

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

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

There is no guidance on when to use move_note versus alternatives like update_note, patch_note, or restore_note. No conditions, use cases, or exclusions 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 carries the behavioral disclosure burden. It does disclose the kind filter values and the presence of per-kind counts, which is useful. However, it does not explain ordering, pagination behavior, whether counts are overall or filtered, or whether only successful interactions are logged. Partial behavioral transparency, but several important behaviors are left unstated.

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

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

The description is compact and front-loads the core behavior. The kind filter list is useful and included without unnecessary elaboration. It loses a point only because the structure is slightly choppy and the limit/offset parameters are ignored.

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 conveys the primary purpose and main filter, and an output schema exists to clarify return shape. However, it does not explain how limit and offset interact with the history and counts, nor does it clarify whether per-kind counts are affected by the filter. For a moderately complex read-history tool, this is adequate but incomplete.

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

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

Schema description coverage is 0%, so the description must compensate. It does document the 'kind' parameter's allowed values and implies 'note_id' identifies the note, but it says nothing about 'limit' or 'offset'. For a tool with four parameters, leaving two entirely unexplained is a significant gap.

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

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

The description states the tool returns every logged interaction for one note, with kind filtering and per-kind counts. This is specific enough to identify the resource and behavior, though it relies on the title to establish it is a history/retrieval operation. It distinguishes itself from sibling CRUD tools by focusing on interaction logs for a single 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 purpose implies when to use it: when you need the activity log for one specific note, optionally filtered by kind. However, it does not explicitly differentiate from siblings like recent_changes, search_notes, or read_note, nor does it state when not to use this tool. Usage context is inferred rather than explicit.

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

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

With no annotations, the description must carry behavioral disclosure. It does disclose the main mutation behavior (replace or append) and the scoped target ('section under a heading,' 'surgical'). However, it omits important traits like behavior when the heading is missing, whether other sections are preserved, and the exact effect of append mode.

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 remarkably concise: two short sentences with the primary operation front-loaded and 'Surgical edits' adding useful context without redundancy. 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?

There is an output schema, so explaining return values is not necessary, but the absence of annotations and a terse description leaves ambiguity about edge cases such as missing headings and append semantics. The description is sufficient for a straightforward invocation 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?

Schema description coverage is 0%, and the description adds some meaning by linking heading to the section, content to the replacement text, and mode to replace/append. It does not explain note_id or specify allowed mode values or content formatting, so compensation is only partial.

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 action and resource: 'Replace (or append to) the section under a heading.' 'Surgical edits' hints at precision but does not explicitly compare against sibling tools like update_note or append_note, so it lacks clear sibling differentiation.

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

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

There is no guidance on when to use this tool versus alternatives such as append_note or update_note. 'Surgical edits' is a characterization of the behavior, not an explicit condition, exclusion, or pointer to a sibling.

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. 'Read' implies a non-mutating operation and provides some transparency, but it does not disclose behavior for missing IDs, access errors, or other edge cases.

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 with no filler or redundant detail. It front-loads the core intent and resource, making it easy for an agent to parse quickly.

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

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

For a single-parameter read operation with an output schema, the description is minimally sufficient. However, given the large set of sibling tools, some additional context about how read_note differs from read_notes, list_notes, or search_notes would improve 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 description coverage is 0%, but the description only contributes 'by id', which largely restates the existing note_id property name. It does not provide additional meaning about the expected format, source, or semantics of the ID beyond what the schema already implies.

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 a specific action ('Read') applied to a specific resource ('a note') and identifies the lookup mechanism ('by id'). It is easy to understand, though it does not explicitly differentiate itself from sibling tools like read_notes or list_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 phrase 'by id' implies this tool is appropriate when the agent already has a note_id, providing a basic usage context. However, it offers no explicit guidance about when not to use it or which alternative sibling tool to choose for other retrieval needs.

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

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

With no annotations, the description carries the full behavioral burden. It discloses that missing ids are reported but not fatal, which is a key non-obvious behavior. It also implies read-only operation. However, it does not cover other error scenarios or auth requirements, but for a simple read tool this is sufficient.

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

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

The description is a single, front-loaded sentence with zero fluff. It states the purpose and a critical behavioral note immediately, 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?

Given the presence of an output schema, return values do not need to be described. The description covers the core purpose and the key edge case (missing ids). It does not mention any prerequisites or specific error formats beyond the missing-id note, but for a batch-read tool this is adequate. It could be slightly more explicit about the partial success behavior, but the statement 'missing ids are reported, not fatal' already conveys that.

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

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

Schema description coverage is 0%, so the description must compensate. The description implies that note_ids is the list of IDs to read, but it does not add extra meaning beyond what the parameter name suggests. Since the parameter is a simple array of strings, the meaning is fairly obvious, and the missing-id behavior does not clarify the parameter itself. The description meets the minimum bar but does not enrich 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 ('Read') and resource ('several notes'), and explicitly distinguishes from the singular sibling read_note by stating 'several at once'. It clearly identifies the batch nature of the tool, making it easy to differentiate.

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 conveys that this tool is for reading multiple notes in a single call, implying it is the batch counterpart to read_note. It does not explicitly mention alternatives or exclusions, but the context of batch reading is clear, so it provides adequate usage guidance.

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

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

With no annotations, the description carries the behavioral disclosure burden. It explicitly states the result is paged, ordered newest-first, audited, and includes per-kind counts for the whole log. This goes beyond the schema and gives an agent a solid sense of what to expect, though it does not detail authentication or read-only guarantees.

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 tightly written sentences. The first sentence front-loads the core purpose, ordering, and paging; the second adds return-shape context. There is no filler or redundant restating of the tool name.

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 paginated read tool with an output schema, the description covers the essential behavioral context: scope, order, paging, and result shape. It is slightly vague about what 'capture changes' means and relies on the reader knowing the per-note history shape, but the output schema reduces the need for more 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 schema has no descriptions for limit or offset, and the description only indirectly addresses them via the word 'paged.' Limit and offset are standard pagination terms, and the defaults in the schema help, but the description does not add explicit detail about how pagination behaves or what each parameter controls.

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 identifies the resource as 'latest audited vault and capture changes' and provides ordering and pagination context. It does not use an explicit active verb like 'list' or 'get', but the passive 'Returned with...' makes the retrieval intent clear. It also distinguishes itself from per-note history by emphasizing the whole log.

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 context is implied: this is for recent changes across the entire vault and capture log, contrasted with 'the per-note history reports for one file.' However, it does not explicitly say when to choose this tool over note_history or other sibling tools, and it offers no 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, the description carries the behavioral burden. It does disclose the key state transition: from trashed back into the vault. However, it does not mention edge behavior such as idempotency, what happens if the note is not trashed, or any permission requirements.

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

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

The description is a single eight-word sentence that states the action and target immediately. It contains no filler and does not repeat 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?

For a one-parameter tool with an output schema, the description covers the essential context: what operation is performed and on what object. It omits edge cases like restoring an already-restored note, but these are secondary and are likely reflected in output/error behavior.

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

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

The schema has only one required parameter, note_id, and the description never names it. The phrase 'a trashed note' implicitly identifies note_id as the target note to restore, but the description does not explicitly elaborate on the parameter or its format.

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

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

The description names a specific verb ('Restore'), a specific resource ('a trashed note'), and a destination ('back into the vault'). This clearly distinguishes it from sibling create/delete/move tools because restoring from trash is a unique 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 wording clearly implies the tool should be used when a note is trashed and needs to be returned to the vault. It does not explicitly list alternatives or exclusions, but the intended context is clear and unlikely to be confused with siblings.

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

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

No annotations are present, so the description carries the full burden of disclosing behavior. It does not state whether the tool is read-only, what it returns (full notes, metadata, etc.), how it handles missing tags, or any side effects. The single phrase offers essentially no 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 is extremely short, but this is under-specification, not effective conciseness. It is not front-loaded with actionable information; it is a fragment that fails to convey the tool's function.

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

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

With one parameter, no annotations, and an output schema that is not described in the tool description, the description is grossly incomplete. An agent cannot correctly infer how to call this tool, what to expect, or when to use it. It needs substantially more context.

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

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

The schema has one parameter 'tag' with 0% description coverage, and the description does not mention the parameter at all. It says 'frontmatter tag' but does not clarify that the 'tag' parameter is the value to match, leaving the parameter's meaning entirely unexplained.

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

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

The description is a noun phrase ('Notes carrying a frontmatter tag') rather than a clear verb+resource statement. It implies the tool returns notes with a tag, but it does not explicitly state a search or filtering action, nor does it differentiate from siblings like search_notes or list_notes. This is vague and under-specified.

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. There are many sibling tools (search_notes, list_notes, get_frontmatter) that could overlap, but the description gives no exclusions, conditions, or context 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 disclosure burden, but it is sparse: 'search' implies a read-only operation and 'ripgrep' hints at regex behavior, yet side effects, result ordering, and pagination semantics are unstated. The ripgrep mention and by-name/content scope add some behavioral context, but the description remains a high-level line.

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

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

One short sentence, front-loaded with the action and scope, with no filler. The 'ripgrep' parenthetical earns its place by adding an implementation/regex signal. It is concise, though it sacrifices routing and parameter detail.

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

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

This is a low-risk search tool and an output schema exists, so the description does not need to document the return shape. However, in a sibling set that includes search_by_tag, the lack of explicit differentiation and the 0% schema coverage leave an agent to infer usage details like pagination parameters and whether tag queries are supported.

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

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

Schema description coverage is 0%, so the description should compensate for the undocumented 'query', 'limit', and 'offset' parameters. It only partially helps for 'query' by stating name/content search, and it never addresses 'limit' or 'offset'. The parameter names and defaults are relatively self-explanatory, which is why this is not a 1.

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

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

The description gives a clear verb ('Search'), resource ('notes'), and scope ('by name and content'), and the parenthetical 'ripgrep' signals full-text/regular-expression search. It does not explicitly name a sibling to differentiate it from, so it stops short of a perfect score.

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 should be used for full-text/name searches, but it provides no explicit when-to-use guidance or alternatives, such as preferring search_by_tag for tag-based lookups. The context is oriented around the tool's own function rather than placement among its siblings.

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

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

No annotations exist, so the description carries the burden of behavioral disclosure. It does reveal the key behavioral nuance: the operation merges rather than replaces, and a null value deletes a key. However, it does not disclose whether existing keys are overwritten, how nested objects are handled, error behavior, or any permission requirements.

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

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

The description is a single sentence with no wasted words. The main action is front-loaded, and the parenthetical efficiently captures the deletion behavior without adding bulk.

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

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

With an output schema present and only two parameters, the core invocation details are sufficient. However, the arbitrary 'updates' object leaves ambiguity about accepted value types, shallow versus deep merge behavior, and validation failure handling, so the description is not fully complete for all realistic agent scenarios.

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

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

Schema description coverage is 0%, so the description must compensate. It explains that 'updates' is a set of frontmatter keys to merge and that null values delete keys, which adds real meaning beyond the raw schema. It does not specify the format or type of 'note_id', but the name and string type are largely self-explanatory.

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, 'merge', tied to a specific resource, 'frontmatter', and adds the key deletion rule for null values. It is not a tautology and clearly differentiates from 'get_frontmatter', though it does not explicitly contrast with sibling mutation tools like 'patch_note' 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?

There is no explicit guidance about when to use this tool versus alternatives such as 'patch_note', 'update_note', or 'get_frontmatter'. The intended context is only implied by the word 'frontmatter', with no stated prerequisites, exclusions, or comparison to siblings.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. 'Replace' indicates the note's existing content is overwritten, but it does not mention whether the note must already exist, whether the operation is reversible, or what side effects might occur.

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 entire description is one focused sentence with no filler, and the core action 'Replace' is front-loaded. Every word contributes meaning.

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

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

For a two-parameter update with an output schema, the core call shape is adequately described. However, absent annotations and explicit usage guidance, an agent gets little help on failure behavior or choosing this over patch_note and append_note.

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

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

Schema description coverage is 0%, so the description must compensate by explaining the parameters. It maps note_id to the identifier and content to the replacement text, but adds no detail about format, length, or behavior beyond the schema's raw string types.

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 ('replace'), a concrete resource ('a note's content'), and an identifier method ('by id'), making the core operation clear. It does not explicitly contrast itself with sibling tools like patch_note or append_note, so it misses the strongest level of 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 word 'replace' implies this tool is for full content overwrite rather than incremental changes, which gives a weak usage signal alongside patch_note and append_note. However, there is no explicit statement of when to use it versus alternatives or any prerequisites.

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