Server Quality Checklist

Tool Scores

• append_to_noteC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It states the core action but lacks critical details: whether this operation is idempotent, what happens if the note doesn't exist, if there are permission requirements, rate limits, or how conflicts are handled. For a mutation tool with zero annotation coverage, this leaves significant behavioral unknowns.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that states the core functionality without unnecessary words. It's front-loaded with the main action and resource, making it easy to parse. Every word earns its place, with no redundancy or fluff.

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

  Completeness2/5

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

  For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't cover error conditions, success responses, or behavioral nuances like whether the append is atomic or if there are side effects. Given the complexity of file system operations and the lack of structured safety hints, more context is needed for reliable agent use.

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

  Parameters3/5

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

  Schema description coverage is 100%, so all parameters are documented in the schema. The description adds no additional parameter semantics beyond what the schema provides—it doesn't clarify path format (e.g., relative to vault root, file extensions), content constraints, or separator usage examples. Baseline 3 is appropriate when the schema does the heavy lifting.

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

  Purpose4/5

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

  The description clearly states the action ('Append content') and target resource ('to the end of an existing note'), making the purpose immediately understandable. It distinguishes from sibling tools like 'prepend_to_note' by specifying 'to the end', but doesn't explicitly differentiate from other note modification tools like 'update_note' or 'insert_at_heading' beyond the append action.

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

  Usage Guidelines2/5

  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 prerequisites (e.g., the note must exist), when to choose this over 'update_note' or 'insert_at_heading', or any constraints like file size limits. The agent must infer usage from the tool name and sibling list alone.

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

• create_from_templateC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool creates a new note, implying a write operation, but doesn't mention permissions, side effects (e.g., whether it overwrites existing files), error handling, or output format. This is inadequate for a mutation tool with zero annotation coverage.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action, making it easy to parse, and every part of the sentence contributes essential information.

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

  Completeness2/5

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

  Given the complexity of a note-creation tool with template variables and no output schema, the description is insufficient. It doesn't explain what the tool returns (e.g., success/failure, the new note's content), how variables are processed, or error conditions, leaving significant gaps for the agent to operate effectively.

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

  Parameters3/5

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

  The input schema has 100% description coverage, so the schema fully documents all three parameters. The description adds no additional meaning beyond what's in the schema (e.g., it doesn't explain path formats or variable syntax further), meeting the baseline score of 3 for high schema coverage.

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

  Purpose4/5

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

  The description clearly states the action ('Create a new note') and the resource ('from an existing template note'), making the purpose immediately understandable. However, it doesn't explicitly distinguish this tool from 'create_note' (a sibling tool), which appears to create notes without templates, leaving some ambiguity about when to choose one over the other.

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

  Usage Guidelines2/5

  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 like 'create_note' or other sibling tools. It lacks context about prerequisites (e.g., needing an existing template), exclusions, or typical use cases, leaving the agent to infer usage from the tool name alone.

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

• delete_noteC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action is deletion, implying a destructive mutation, but lacks details on permissions needed, whether deletion is permanent or reversible, error handling (e.g., if path doesn't exist), or side effects (e.g., impact on backlinks). This is a significant gap for a destructive tool with zero annotation coverage.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and resource, making it easy to parse quickly, and every part of the sentence contributes essential information.

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

  Completeness2/5

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

  Given this is a destructive mutation tool with no annotations and no output schema, the description is incomplete. It doesn't address critical aspects like what happens on success/failure, whether the deletion is permanent, or how it interacts with sibling tools (e.g., 'get_backlinks' might be affected). For a tool with such behavioral complexity, more context is needed to guide safe usage.

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

  Parameters3/5

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

  The input schema has 100% description coverage, with the 'path' parameter clearly documented as 'Path to the note to delete relative to vault root'. The description doesn't add any semantic details beyond this, such as path format examples or constraints. Given the high schema coverage, the baseline score of 3 is appropriate as the schema does the heavy lifting.

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

  Purpose4/5

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

  The description clearly states the action ('Delete') and resource ('a note from the Obsidian vault'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'rename_note' or 'update_note' which also modify notes, leaving room for ambiguity about when deletion is specifically appropriate versus other modifications.

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

  Usage Guidelines2/5

  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 prerequisites (e.g., note must exist), exclusions (e.g., cannot delete non-empty folders), or suggest sibling tools for related actions like 'rename_note' for moving notes instead of deleting them, leaving the agent to infer usage context.

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

• get_linksC
  2.9/5.0
  Behavior2/5

  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 what the tool does but lacks details on permissions, error handling, return format (e.g., list structure), or any constraints like rate limits. This is a significant gap for a tool with no annotation coverage.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and wastes no space, making it easy to parse quickly.

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

  Completeness2/5

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

  Given no annotations and no output schema, the description is incomplete. It doesn't explain the return value (e.g., what the links look like, if they're structured), error cases, or behavioral nuances. For a tool with one parameter but missing structured context, this leaves gaps in understanding.

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

  Parameters3/5

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

  The input schema has 100% description coverage, with the 'path' parameter clearly documented. The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints. Baseline 3 is appropriate as the schema does the heavy lifting.

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

  Purpose4/5

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

  The description clearly states the action ('Get') and resource ('all internal links from a note'), specifying the types of links included (wikilinks and markdown links). It distinguishes itself from siblings like 'get_backlinks' by focusing on outgoing links rather than incoming references, though it doesn't explicitly name this distinction.

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

  Usage Guidelines2/5

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

  No explicit guidance is provided on when to use this tool versus alternatives like 'search_content' or 'read_note'. The description implies usage for extracting links from a specific note but doesn't mention prerequisites, exclusions, or comparative contexts with sibling tools.

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

• get_tagsC
  2.9/5.0
  Behavior2/5

  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 it 'gets' tags, implying a read-only operation, but doesn't specify if it returns a list, format of tags, error handling for invalid paths, or permissions required. For a tool with no annotations, this leaves significant gaps in understanding its behavior.

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

  Conciseness5/5

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

  The description is a single, clear sentence that directly states the tool's purpose without any unnecessary words. It is front-loaded and efficiently conveys the core functionality, making it easy to understand at a glance.

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

  Completeness2/5

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

  Given the tool has no annotations, no output schema, and the description lacks behavioral details, it is incomplete for effective use. The agent won't know what the return value looks like (e.g., list of strings, structured data) or any operational constraints. For a tool with 1 parameter but missing key context, this is inadequate.

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

  Parameters3/5

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

  Schema description coverage is 100%, with the parameter 'path' fully documented in the schema as 'Path to the note'. The description adds no additional meaning beyond this, such as examples of valid paths or constraints. With high schema coverage, the baseline score of 3 is appropriate as the schema handles the parameter documentation.

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

  Purpose4/5

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

  The description clearly states the action ('Get') and target resource ('all tags used in a note'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'search_content' or 'search_notes', which might also involve tags, but the specific focus on retrieving tags from a note is well-defined.

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

  Usage Guidelines2/5

  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. For example, it doesn't mention if this is for retrieving tags from a single note versus searching across notes, or how it relates to siblings like 'search_content' that might filter by tags. The description only states what it does, not when to choose it.

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

• insert_at_headingC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool inserts content, implying a mutation operation, but doesn't cover critical aspects like whether it modifies existing content, requires specific permissions, handles errors (e.g., if the heading doesn't exist), or what the response looks like. This leaves significant gaps for an agent to understand the tool's behavior.

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

  Conciseness5/5

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

  The description is a single, clear sentence that efficiently conveys the core purpose without unnecessary words. It's front-loaded with the main action and target, making it easy to parse quickly. Every part of the sentence earns its place by specifying key elements like 'content' and 'under a specific heading'.

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

  Completeness2/5

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

  Given the tool's complexity (a mutation operation with 4 parameters) and the lack of annotations and output schema, the description is incomplete. It doesn't address behavioral traits, error handling, or return values, which are crucial for an agent to use the tool correctly in context with its siblings. The description alone is insufficient for safe and effective tool invocation.

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

  Parameters3/5

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

  The description adds no parameter-specific information beyond what the input schema provides. Since schema description coverage is 100%, the baseline score is 3. The description doesn't elaborate on parameter meanings, constraints, or usage examples, so it doesn't compensate for or enhance the schema's documentation.

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

  Purpose4/5

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

  The description clearly states the action ('Insert content') and target ('under a specific heading in a note'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'append_to_note' or 'prepend_to_note', which might have overlapping functionality for content insertion in notes.

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

  Usage Guidelines2/5

  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 prerequisites (e.g., the note must exist), exclusions, or comparisons to siblings like 'append_to_note' (which might append to the entire note rather than under a heading) or 'update_note' (which might handle broader edits).

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

• read_noteC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full burden for behavioral disclosure. While 'Read' implies a safe operation, it doesn't specify what happens with invalid paths (e.g., errors vs. null returns), whether authentication is needed, or any rate limits. The description is minimal and lacks important operational context.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that communicates the core purpose without any wasted words. It's appropriately sized for a simple tool and gets straight to the point with perfect front-loading of information.

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

  Completeness2/5

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

  For a read operation with no annotations and no output schema, the description is insufficient. It doesn't explain what format the content returns in (e.g., plain text, markdown, metadata), whether it includes frontmatter, or how errors are handled. Given the lack of structured fields, more descriptive context is needed.

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

  Parameters3/5

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

  Schema description coverage is 100%, with the single parameter 'path' clearly documented in the schema. The description adds no additional parameter information beyond what the schema provides, so it meets the baseline for adequate but unenriched parameter documentation.

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

  Purpose4/5

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

  The description clearly states the action ('Read') and resource ('content of a single note'), making the tool's function immediately understandable. However, it doesn't differentiate from sibling tools like 'search_content' or 'get_backlinks' that also involve reading note content in different ways, preventing 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.

  Usage Guidelines2/5

  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. With siblings like 'search_content' for finding notes by content, 'get_backlinks' for relationship analysis, and 'list_folder' for directory browsing, there's no indication of when this specific read operation is preferred over other read-like tools.

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

• rename_noteC
  2.9/5.0
  Behavior2/5

  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 'rename or move' which implies mutation, but doesn't specify permissions needed, whether the operation is atomic, what happens on conflicts (e.g., if newPath exists), or error handling. This is inadequate for a mutation tool with zero annotation coverage.

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

  Conciseness5/5

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

  The description is a single, efficient sentence with zero waste—it directly states the tool's function without redundancy. It's appropriately sized and front-loaded, making it easy to understand at a glance.

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

  Completeness2/5

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

  Given the complexity of a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain behavioral aspects like side effects, return values, or error conditions, leaving significant gaps for an AI agent to use it correctly.

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

  Parameters3/5

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

  The schema description coverage is 100%, with clear descriptions for 'oldPath' and 'newPath'. The description adds no additional parameter semantics beyond what the schema provides, such as path format or constraints. Baseline 3 is appropriate when the schema does the heavy lifting.

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

  Purpose4/5

  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 specific verbs ('rename or move') and resource ('a note'), distinguishing it from siblings like 'create_note', 'delete_note', or 'read_note'. However, it doesn't explicitly differentiate from 'update_note' which might also handle renaming, so it's not a perfect 5.

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

  Usage Guidelines2/5

  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 like 'update_note' or 'create_note' for similar operations. It lacks context on prerequisites, such as whether the note must exist or if the new path must be valid, leaving usage unclear.

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

• search_contentC
  2.9/5.0
  Behavior2/5

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

  With no annotations, the description carries full burden but only states the basic function. It doesn't disclose behavioral traits such as pagination (implied by 'limit'), performance considerations, error handling, or what happens if no matches are found. For a search tool with zero annotation coverage, 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.

  Conciseness5/5

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

  The description is a single, efficient sentence with zero waste—front-loaded and directly states the tool's purpose. Every word earns its place, 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.

  Completeness2/5

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

  Given the complexity of a search operation with no annotations and no output schema, the description is incomplete. It lacks details on return format (e.g., list of notes with snippets), error cases, or how results are ordered. For a tool with 3 parameters and behavioral nuances, this is inadequate.

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

  Parameters3/5

  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 parameters. The description adds no additional meaning beyond implying text-based search, which is already covered by the schema's 'query' description. Baseline 3 is appropriate as the schema does the heavy lifting.

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

  Purpose4/5

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

  The description clearly states the action ('Search for') and resource ('notes'), specifying the search scope ('containing specific text in their content'). It distinguishes from siblings like 'search_notes' by focusing on content text rather than broader note attributes, though the distinction could be more explicit.

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

  Usage Guidelines2/5

  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 'search_notes' or 'list_folder'. The description implies usage for text-based content searches but lacks explicit context, prerequisites, or exclusions, leaving the agent to infer from tool names alone.

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

• search_notesC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. It mentions search behavior (case-insensitive, regex) but lacks critical information: whether this is a read-only operation, what permissions are needed, how results are returned (format, ordering), pagination details, or error conditions. The description is insufficient for a search tool with zero annotation coverage.

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

  Conciseness5/5

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

  The description is perfectly concise - a single sentence that efficiently communicates the core functionality with no wasted words. It's front-loaded with the main purpose and includes essential technical details in parentheses.

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

  Completeness2/5

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

  For a search tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the search returns (note objects? just names?), how results are structured, whether there's pagination beyond the limit parameter, or any error handling. The description alone is inadequate for proper tool invocation.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description adds minimal value beyond the schema - it mentions 'name pattern' which clarifies the query parameter's purpose slightly, but doesn't provide additional syntax examples, regex format details, or explain the relationship between query and limit parameters.

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

  Purpose4/5

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

  The description clearly states the tool's purpose: 'Search for notes by name pattern' with specific details about case-insensitivity and regex support. It distinguishes from siblings like 'search_content' (which likely searches note content) by focusing on name patterns, but doesn't explicitly mention this distinction.

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

  Usage Guidelines2/5

  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 like 'search_content' or 'list_folder'. It mentions technical capabilities (case-insensitive, regex) but doesn't indicate appropriate contexts or exclusions for usage.

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

• update_frontmatterC
  2.9/5.0
  Behavior2/5

  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 updating or adding properties but fails to cover critical aspects like whether this operation is destructive, requires specific permissions, handles errors, or affects existing content beyond frontmatter. This leaves significant 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.

  Conciseness5/5

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

  The description is a single, efficient sentence that directly states the tool's function without any fluff or redundancy. It is appropriately sized and front-loaded, 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.

  Completeness2/5

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

  Given the complexity of a mutation tool with no annotations and no output schema, the description is insufficient. It lacks details on behavioral traits, error handling, return values, and differentiation from siblings, making it incomplete for safe and effective use by an AI agent.

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

  Parameters3/5

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

  The input schema has 100% description coverage, clearly documenting both parameters ('path' and 'properties') with details like using null to delete a property. The description adds no additional semantic meaning beyond what the schema provides, so it meets the baseline for adequate but not enhanced parameter understanding.

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

  Purpose4/5

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

  The description clearly states the verb ('update or add') and resource ('frontmatter (YAML) properties in a note'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'update_note', which might also modify notes, leaving room for ambiguity.

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

  Usage Guidelines2/5

  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 such as 'update_note' or 'append_to_note'. It lacks context about specific scenarios, prerequisites, or exclusions, leaving the agent to infer usage based on the tool name alone.

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

• update_noteC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool performs an update/replace operation, implying mutation, but lacks details on permissions, error handling (e.g., if the note doesn't exist), whether changes are reversible, or any rate limits. This is a significant gap for a mutation tool without annotation support.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that front-loads the core action ('update/replace') and resource. There is no wasted language, making it easy to parse quickly while conveying the essential purpose.

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

  Completeness2/5

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

  Given the tool's mutation nature, lack of annotations, and absence of an output schema, the description is incomplete. It doesn't cover behavioral aspects like error conditions, return values, or safety considerations, which are critical for an agent to use this tool effectively in a vault context with many sibling tools.

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

  Parameters3/5

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

  The input schema has 100% description coverage, with clear documentation for both parameters ('path' and 'content'). The description adds minimal value beyond the schema by implying 'content' replaces the entire note, but doesn't provide additional syntax, format details, or constraints. This meets the baseline for high schema coverage.

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

  Purpose4/5

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

  The description clearly states the action ('update/replace') and resource ('entire content of an existing note'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'append_to_note', 'prepend_to_note', or 'update_frontmatter', which would require more specific language about full replacement versus partial modifications.

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

  Usage Guidelines2/5

  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 prerequisites (e.g., the note must exist), exclusions (e.g., not for partial updates), or refer to sibling tools like 'append_to_note' or 'update_frontmatter' for different use cases, leaving the agent to infer usage from context alone.

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

• list_folderB
  3.1/5.0
  Behavior2/5

  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 mentions listing items but does not cover critical aspects like whether this is a read-only operation, potential rate limits, authentication needs, or what the output format looks like (e.g., list structure, pagination). This leaves significant gaps for an agent to understand the tool's behavior.

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

  Conciseness5/5

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

  The description is a single, direct sentence that efficiently conveys the core functionality without any wasted words. It is front-loaded and appropriately sized for a simple listing tool.

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

  Completeness3/5

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

  Given the tool's low complexity (a read operation with two well-documented parameters) and no output schema, the description is minimally adequate but incomplete. It lacks details on behavioral traits (e.g., safety, output format) that would help an agent use it correctly, especially since no annotations are present to fill those gaps.

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

  Parameters3/5

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

  The input schema has 100% description coverage, clearly documenting both parameters ('path' and 'recursive') with their types, defaults, and purposes. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline for high schema coverage without compensating value.

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

  Purpose4/5

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

  The description clearly states the verb ('List') and resource ('all notes and subfolders in a folder'), making the purpose immediately understandable. However, it does not explicitly distinguish this tool from sibling tools like 'search_notes' or 'search_content', which might offer similar listing capabilities with filtering, so it misses full sibling differentiation.

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

  Usage Guidelines2/5

  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 such as 'search_notes' or 'search_content', nor does it mention any prerequisites or exclusions. It simply states what the tool does without contextual usage advice.

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

• create_noteA
  3.5/5.0
  Behavior2/5

  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 mentions 'Supports nested folder creation', which adds useful behavioral context beyond the basic creation action. However, it does not disclose critical traits like whether this requires specific permissions, how errors are handled (e.g., if path is invalid), or any rate limits. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.

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

  Conciseness5/5

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

  The description is two sentences with zero waste: the first sentence states the core purpose, and the second adds a key feature. It is front-loaded with the main action and efficiently conveys essential information without redundancy or fluff.

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

  Completeness3/5

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

  Given the tool has no annotations and no output schema, the description is moderately complete. It covers the basic purpose and a notable feature (nested folder creation), but lacks details on behavioral aspects like error handling or return values. For a creation tool with 3 parameters and rich sibling context, it should provide more guidance on usage and outcomes to be fully helpful.

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

  Parameters3/5

  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 (path, content, overwrite). The description does not add any parameter-specific details beyond what the schema provides, such as examples for nested folders or Markdown formatting tips. With high schema coverage, the baseline is 3, as the description does not compensate but also does not detract.

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

  Purpose5/5

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

  The description clearly states the verb 'Create' and the resource 'new note in the Obsidian vault', specifying the action and target. It distinguishes from siblings like 'append_to_note' or 'update_note' by emphasizing creation of a new note, and adds unique value with 'Supports nested folder creation', which is not obvious from the name alone.

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

  Usage Guidelines3/5

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

  The description implies usage for creating new notes, but does not explicitly state when to use this tool versus alternatives like 'create_from_template' or 'update_note'. It mentions nested folder creation as a feature, which provides some context, but lacks clear guidance on prerequisites, exclusions, or specific scenarios where this is the preferred choice.

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

• get_backlinksA
  3.5/5.0
  Behavior2/5

  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. While it states the tool's purpose, it doesn't describe what the output looks like (e.g., list of note paths, metadata), whether it's paginated, if it requires specific permissions, or any rate limits. For a read operation with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that directly states the tool's purpose with zero wasted words. It's front-loaded and appropriately sized for a simple tool with one parameter, making it easy to parse quickly.

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

  Completeness3/5

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

  Given the tool's low complexity (one parameter, no output schema, no annotations), the description is minimally adequate but incomplete. It covers the basic purpose but lacks details on output format, behavioral traits, or usage context. For a tool that returns data, the absence of output schema means the description should ideally hint at what's returned, which it doesn't.

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

  Parameters3/5

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

  Schema description coverage is 100%, with the single parameter 'path' clearly documented in the schema. The description doesn't add any additional meaning beyond what the schema provides (e.g., it doesn't explain path format or examples). Since the schema does the heavy lifting, 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.

  Purpose5/5

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

  The description clearly states the specific action ('Find all notes that link to') and resource ('a specific note'), distinguishing it from siblings like get_links (which likely finds outgoing links) or search_content/search_notes (which search content or metadata). It precisely communicates the tool's unique function in the note-linking ecosystem.

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

  Usage Guidelines3/5

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

  The description implies usage when you need to discover which notes reference a particular note, but it doesn't explicitly state when to use this tool versus alternatives like get_links or search_content. No guidance is provided on prerequisites, exclusions, or specific scenarios where this tool is preferred over others.

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

• prepend_to_noteA
  3.9/5.0
  Behavior3/5

  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 tool modifies existing notes (implied mutation) and handles frontmatter intelligently, which is useful behavioral context. However, it doesn't mention permissions, error conditions (e.g., if note doesn't exist), or what happens to existing content beyond the prepend action.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that front-loads the core purpose ('prepend content to the beginning of an existing note') and adds only essential qualification ('after frontmatter if present'). Every word earns its place with no redundancy or fluff.

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

  Completeness3/5

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

  For a mutation tool with no annotations and no output schema, the description is minimally adequate. It covers the basic operation and frontmatter handling but lacks details on error handling, return values, or side effects. Given the complexity (modifying files) and lack of structured safety hints, more context would be helpful.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description doesn't add any parameter-specific details beyond what's in the schema (e.g., it doesn't explain 'path' format or 'content' constraints), meeting the baseline for high schema coverage.

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

  Purpose5/5

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

  The description clearly states the specific action ('prepend content to the beginning of an existing note') and distinguishes it from sibling tools like 'append_to_note' by specifying the location ('beginning' vs. end). It also adds nuance about handling frontmatter, which further differentiates it from other note modification tools.

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

  Usage Guidelines4/5

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

  The description implies when to use this tool by specifying it's for prepending to 'an existing note', suggesting it shouldn't be used for creating new notes (use 'create_note' instead). However, it doesn't explicitly state when not to use it or name alternatives like 'append_to_note' or 'update_note' for comparison.

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