mnemosyne_vault_list

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

Beyond the readOnlyHint annotation, the description adds useful behavioral details: vaults have a local-path `id` that other tools reject, unconfigured vaults are flagged and refused until the user adds them, and the response includes token/display-name/memory-count. This prevents the agent from misusing the wrong identifier.

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?

Every sentence earns its place: it names the resource, tells when to call it, explains how to use the output, warns about the non-useful `id` field, and notes unconfigured-vault behavior. The description is front-loaded and free of filler.

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

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

Even without an output schema, the description explains what the response will contain, how to use that response, and the key caveat about unconfigured vaults. For a simple read-only list tool with no parameters, this is complete enough for an agent to call it correctly and act on the results.

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

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

The tool has zero parameters, so the description does not need to explain parameter meaning. The baseline of 4 applies here, and the description even adds downstream guidance about how the returned token is used as a parameter in other tools.

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

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

The description uses a specific verb ('List') and resource ('memory vaults') and states what each listed vault contains: token, display name, and memory count. It clearly distinguishes this tool from sibling list tools like mnemosyne_agent_list or mnemosyne_todo_list by targeting vaults specifically.

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

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

It gives explicit conditions for use: call it first when unsure which vault to work against, or when the user names a store not yet seen. It also tells the agent how to consume the result by passing the token as the `vault` argument to other tools, and clarifies that the `id` line should not be passed.

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