Server Quality Checklist

Tool Scores

• get_itemA
  4/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden and does disclose important behavioral traits: the vault must be unlocked and the returned entry includes sensitive values. However, it does not describe what happens if the vault is locked, error behavior, or return format, leaving some gaps for a sensitive-data operation.

  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 no wasted words. It front-loads the core behavior and adds a usage directive efficiently.

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

  Completeness4/5

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

  Given the simple 2-parameter tool and no output schema, the description adequately conveys what is returned, its sensitive nature, and the prerequisite of an unlocked vault. Minor omissions like return structure and error handling are acceptable but could be enhanced.

  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 coverage is 100%, meaning the parameters (vault and uuid) are already fully described in the schema. The description adds no additional parameter-level detail, so the baseline score of 3 applies.

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

  Purpose5/5

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

  The description uses a specific verb ('Returns') and identifies a precise resource ('full entry from an unlocked vault'), while explicitly mentioning sensitive field values. This distinguishes it from sibling tools like get_password and get_otp, which target individual fields.

  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 clearly states when to use the tool ('when the user explicitly wants the credentials'), giving strong contextual guidance. However, it does not explicitly mention when not to use it or direct users to alternatives like get_password or get_otp for single-field extraction.

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

• get_otpA
  4/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden of disclosing behavior. It explains that it generates the current code and returns the code plus seconds until rotation. However, it omits behavioral details such as prerequisites (e.g., vault must be unlocked) or error behavior if the entry lacks an OTP secret, leaving some ambiguity.

  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 concise sentences, starts with the primary action, and includes the key output details. Every sentence provides useful information without unnecessary fluff.

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

  Completeness4/5

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

  Given the tool's simplicity, the description adequately covers purpose and return value. The only missing context is implicit prerequisites (e.g., vault unlocked), but the sibling tool list (unlock_vault, lock_vault) helps fill that gap. Overall, it is complete enough for an agent to use 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?

  Schema coverage is 100%, as both parameters (uuid and vault) have detailed descriptions. The description does not add parameter-level semantics beyond referring to 'an entry that stores an OTP secret,' which aligns with the uuid parameter. Baseline 3 is appropriate since the schema already handles parameter meaning.

  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 tool's function with a specific verb ('Generates') and resource ('current TOTP / two-factor one-time code'). It also distinguishes from siblings like get_password by focusing on OTP entries and describing the return value, making the purpose unambiguous.

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

  Usage Guidelines4/5

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

  The description provides clear context by specifying it is for 'an entry that stores an OTP secret,' indicating when the tool should be used. However, it does not explicitly mention alternatives or when not to use it, so it stops short of providing explicit exclusion criteria.

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

• get_passwordA
  4/5.0
  Behavior3/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 discloses the limited scope ('just the password') and conditional TOTP return ('if present'), but does not describe failure modes (e.g., locked vault, missing entry) or any side effects. Basic behavior is covered, but not deep 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 sentence that is front-loaded with the key verb and object, with no filler or redundancy. It earns its place by being directly informative.

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

  Completeness4/5

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

  For a simple 2-parameter tool with no output schema, the description adequately explains the return content and prerequisite (unlocked vault). Minor gaps include lack of information about return format or error behavior, but overall it is reasonably complete for the tool's simplicity.

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

  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 thoroughly documents both parameters (uuid from list_items, vault name). The description adds no additional semantic meaning beyond the schema, so baseline 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 uses a specific verb ('Returns') and a clear resource ('the password (and TOTP if present) of an entry in an unlocked vault'). It distinguishes from siblings like get_item by emphasizing 'just the password' and from get_otp by indicating TOTP inclusion when present.

  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 phrase 'in an unlocked vault' conveys a clear prerequisite context for use. However, it does not explicitly mention alternative tools or when not to use this tool, though the 'just' phrasing implies using get_item for full details.

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

• lock_vaultA
  4/5.0
  Behavior4/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 goes beyond a mere action verb by revealing a key side effect: clearing the derived key from memory for this session. This adds meaningful context about session-scoped behavior and memory impact, though it stops short of detailing reversibility or effects on other vault data.

  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, well-structured sentence that front-loads the primary action ('Locks a vault') and appends a critical behavioral detail. Every word earns its place, with zero redundancy or filler.

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

  Completeness4/5

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

  For a simple one-parameter tool with no output schema, the description sufficiently covers the action and a key behavioral consequence. The session-scoped caveat is useful, though it could slightly benefit from mentioning whether the lock is temporary or affects other sessions. Overall, it is adequately complete for the tool's simplicity.

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

  Parameters3/5

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

  The schema provides 100% coverage for the single parameter 'vault' with the description 'Registered vault name', so the description does not need to add much. However, the tool description itself offers no extra clarification about the parameter, keeping it at baseline without enhancing meaning beyond the schema.

  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 uses the specific verb 'Locks' with the resource 'vault' and adds a distinctive behavioral detail: it clears the derived key from memory for this session. This clearly distinguishes it from sibling tools, especially unlock_vault, making the purpose unmistakable.

  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 conveys when to use the tool by stating its action ('Locks a vault'), and the sibling list includes unlock_vault, implying this is the inverse operation. However, it does not explicitly mention alternatives, prerequisites, or scenarios where locking is appropriate or discouraged, leaving usage guidance largely implicit.

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

• list_attachmentsA
  4.2/5.0
  Behavior3/5

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

  With no annotations, the description carries the full behavioral burden. It adds useful context: the vault must be unlocked, and the output includes name, size, and MIME. However, it does not mention whether this is a read-only operation, what happens if the vault is locked, or any error behavior. It is adequate but not deeply transparent.

  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 concise: two sentences, each with a clear purpose. The first sentence states the action and output, the second gives an alternative. No unnecessary words or repetition.

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

  Completeness4/5

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

  For a simple two-parameter tool with no output schema, the description covers the core aspects: what it does, what it returns, a prerequisite (unlocked vault), and an alternative tool for a different use case. It lacks edge-case details (e.g., behavior when the vault is locked), but for a listing tool this is sufficient.

  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 already has 100% description coverage for both parameters ('vault' and 'uuid'). The description adds the qualifier that the vault must be unlocked, which provides slight additional meaning, but it does not significantly enhance the parameter semantics beyond what the schema already conveys. Baseline 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 tool's function: 'Lists the file attachments of an entry in an unlocked vault (name, size, MIME).' It uses a specific verb ('lists') and resource ('file attachments of an entry'), and explicitly distinguishes it from the sibling tool 'export_attachment' by noting that the latter is for getting the file itself.

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

  Usage Guidelines5/5

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

  The description provides explicit usage guidance: it says to use 'export_attachment' to get the file itself, implying this tool is for listing metadata (name, size, MIME). It also specifies the prerequisite that the vault must be unlocked, which tells the agent when the tool can be used.

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

• list_itemsA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description carries full burden. It discloses key behavioral traits: requires an unlocked vault, returns only non-sensitive fields, and supports filters. It does not mention pagination or error behavior, but for a read-only listing tool, the disclosure is adequate and goes beyond basic scope.

  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: the first states function and output scope, the second states filters. Every word earns its place, with no redundancy or fluff. Information is front-loaded and immediately usable.

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

  Completeness4/5

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

  Given no output schema and no annotations, the description adequately covers return values (titles, usernames, URLs), constraints (unlocked vault, no sensitive data), and filter options. It omits default limit, but that is covered by the schema. For a simple list tool, this is sufficiently complete.

  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 coverage is 100%, with each parameter having a descriptive comment. The description mentions 'optional search, category and folder filters' which aligns with query, category, and folder params, but adds no new meaning beyond the schema. Baseline 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 states a specific action ('Lists entries') and a clear resource ('in an unlocked vault'). It distinguishes from siblings like list_vaults (lists vaults) and get_item (single entry) by focusing on entry listings, and clarifies it returns only titles/usernames/URLs, not passwords, setting it apart from get_password.

  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 it: after unlocking a vault, for non-sensitive entry listings. It also provides a when-not by explicitly excluding passwords/sensitive values, implicitly steering to other tools. However, it does not name alternative tools explicitly or state exclusions like 'use get_item for details', so it's clear context without full exclusions.

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

• list_vaultsA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full behavioral transparency burden. It explains what the tool reports: file existence, keychain storage of master password, and session unlock state. This goes beyond a generic 'list vaults' and informs the agent about latent checks without requiring external knowledge.

  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 sentence that packs multiple relevant details without unnecessary words. It is front-loaded with the primary action and scope, and each clause adds value to the agent's understanding.

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

  Completeness4/5

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

  For a simple 0-parameter tool with no output schema, the description sufficiently explains what the returned data covers (vault registration, file existence, keychain status, unlock state). It does not specify the exact return format, but the key attributes are enumerated, which is adequate for an agent to know what to expect.

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

  Parameters4/5

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

  The tool has zero parameters, so the baseline is 4. The description correctly focuses on behavior rather than parameters, and no parameter documentation is needed.

  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 uses a specific verb ('Lists') and clearly identifies the resource ('Enpass vaults registered on this machine'). It distinguishes the tool from siblings like list_items by scoping to vault-level metadata rather than items or attachments.

  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 when to use the tool (when needing vault registration/status info) but does not explicitly state alternatives or exclusions relative to sibling tools. It lacks phrases like 'use this instead of' or 'when you need' that would provide stronger guidance.

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

• unlock_vaultA
  4.3/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden. It discloses important behavioral traits: the master password is retrieved from the OS keychain, never passed as an argument, and never reaches the model. It also states a prerequisite ordering. This adds valuable context beyond the schema, though it does not mention potential side effects or error states.

  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 long, front-loaded with the core action, and every sentence earns its place. It efficiently covers purpose, security handling, and usage requirement without any unnecessary words.

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

  Completeness5/5

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

  For a simple one-parameter, no-output tool, the description is complete. It explains what the tool does, the security model for the password, and the required call order. The agent has enough context to select and invoke the tool correctly. No output schema is needed for a void operation.

  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 coverage is 100% with the single parameter 'vault' described as 'Registered vault name'. The description adds little beyond that, only implying that the vault must be registered. It does not provide examples or clarify how to obtain the vault name, but the schema already handles the semantics adequately.

  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 tool's function: 'Unlocks a registered vault.' The verb 'unlocks' and the resource 'vault' are specific, and it distinguishes itself from siblings like lock_vault and list_vaults.

  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 provides explicit usage guidance: 'Must be called before listing or reading entries.' This tells the agent when to use the tool. It does not explicitly mention exclusions or alternatives (e.g., when vault is already unlocked), but the requirement is clear and actionable.

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

• export_attachmentA
  4.4/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It clearly states that the tool decrypts, writes to disk by default, returns a path, and offers an inline base64 alternative for small files. It also notes 'works for any size' for the default mode. This goes beyond the schema's parameter list and gives useful operational context, though it does not disclose potential edge cases (e.g., what counts as 'small' or overwrite 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 two sentences long and front-loads the core purpose. The first sentence states the action and resource; the second explains the default behavior and an alternative. Every word earns its place with no filler or repetition of schema fields.

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

  Completeness4/5

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

  For a tool with five parameters, a 100% covered schema, and no output schema, the description provides enough context: it explains the two output modes, the prerequisite of an unlocked vault, and the scalability of the default mode. It could go further by detailing error conditions or the exact return structure for inline mode, but it is not incomplete.

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

  Parameters4/5

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

  The schema has 100% description coverage for all five parameters, so the baseline is 3. The description adds value by clarifying the behavior tied to the `inline` parameter (returns base64 instead of writing to disk) and explaining the default output path. This goes beyond the schema's brief parameter descriptions, especially for `inline` and `dest`, so a 4 is warranted.

  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 opens with a specific verb and resource: 'Decrypts a file attachment from an unlocked vault.' This clearly distinguishes it from sibling tools like list_attachments (which lists) and get_item (which retrieves metadata). The phrase 'file attachment from an unlocked vault' precisely scopes the operation.

  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 conveys when to use the tool: it requires an unlocked vault, implying a prerequisite. It also explains the two modes (default disk write vs. inline base64) and states that the default works for any size while inline is for small files. However, it does not explicitly name alternative tools or say 'use list_attachments to find attachment names,' so it falls slightly short of a 5.

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

• sync_statusA
  4.4/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden of disclosure. It goes beyond a simple 'lists sync status' by detailing that it reports the sync folder location, compares local vs. remote copy timestamps, and includes a reason in answers, allowing distinctions like 'no baseline yet' vs 'up to date'.

  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, front-loaded with the main action, and every clause adds essential information: scope (vaults with folder sync), details (folder path, newer copy), and answer characteristics (include reason). No wasted words.

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

  Completeness4/5

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

  For a zero-parameter tool with no output schema or annotations, the description is complete enough. It defines what is listed, what is excluded, and what kind of answers to expect. It does not explain the exact return format, but given the simplicity, this is not a critical gap.

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

  Parameters4/5

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

  There are no parameters, so the description has no parameter details to add. The baseline score of 4 is appropriate because no parameter documentation is needed.

  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 uses the specific verb 'Lists' and clearly identifies the resource: vaults using Enpass folder sync. It also distinguishes itself from sibling list_vaults by stating that vaults without folder sync are not listed, making its purpose distinct.

  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 clearly indicates the tool's scope (folder sync status) and notes that vaults without folder sync are not included, which implies when to use it. However, it does not explicitly name an alternative tool such as list_vaults for all vaults, so it lacks explicit guidance on alternatives.

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