list_vaults

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

Annotations already mark the tool as readOnly and non-destructive, and the description adds that only accessible vaults are returned and that share_id is a key output. It does not describe response shape or possible pagination, but the added context is reasonable for a read-only list.

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

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

The description is two short clauses with no filler; the first states the operation and scope, the second states the integration purpose. It is front-loaded and every word earns its place.

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

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

For a no-parameter, read-only list tool, the description covers the core resource and identifies the important output field, share_id, that other tools need. There is no output schema, so a bit more detail on returned fields would help, but this is largely sufficient.

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

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

This tool has zero input parameters and an empty schema, so there is nothing for the description to explain about parameter meaning. The schema coverage is complete by default, and the 0-parameter case correctly gets a baseline score of 4.

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 opens with 'Proton Passのアクセス可能な保管庫一覧', a clear list operation on a specific resource scoped to accessible vaults. The second sentence notes that share_id is meant for other tools, which adds context, though it does not explicitly distinguish this from the sibling list_shares.

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

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

The description implies the tool should be used to obtain a share_id to pass to other tools, giving useful context. However, it does not explicitly state when to prefer this over list_shares or other siblings, leaving some routing to inference.

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