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

No annotations are provided, so the description carries the full behavioral burden, and it largely fails to. It says it dispatches by route name but does not disclose that some dispatched routes are mutating/destructive (2FA disable, emergency access grants, account deletion), any permission or auth requirements, or rate limits. Naming the dispatch pattern is mildly useful, but the safety profile of a multi-domain router is undisclosed.

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?

Three compact lines, front-loaded with the verb and resource list before the dispatch explanation. The trailing 'CONCEPT:VW-ECO.mcp.account-operations' token is non-prose noise that costs a bit of polish but the core text is efficient.

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?

An output schema exists, so return values need not be explained. However, for a router spanning four distinct API domains, the description stops short of clarifying how route names map to actions or which sub-domains carry destructive operations, leaving an agent to discover that via list_actions. Minimally adequate for the complexity.

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

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

Schema description coverage is 100%, so the schema already documents both parameters and the action='list_actions' discovery path, making 3 the baseline. The description adds no syntax, format, or naming-convention detail for 'action' or 'params_json' beyond what the schema states, so it neither compensates nor detracts.

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

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

The description states a clear verb ('Operate') and enumerates the specific resources it covers: account profile, two-factor methods, emergency access, and audit event feeds. It also explains the dispatch mechanism ('Dispatches to every Vaultwarden accounts, two_factor, emergency_access, and events API route by its route name'), which distinguishes it from siblings like vaultwarden_ciphers or vaultwarden_organizations. The domain scoping gives a competent agent enough to tell it apart from the other module tools.

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

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

Usage is only implied by the domain listing: the agent infers it should pick this tool for account/2FA/emergency/audit operations. There is no explicit when-to-use framing, no named alternative among the eight siblings, and no mention in the description that action='list_actions' is the discovery entry point (that hint lives only in the schema). Adequate but with a clear gap.

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

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

With no annotations, the description carries the full burden and does disclose two genuinely useful behavioral facts: admin routes require the instance admin token (VW_ADMIN cookie auth), and rejected/missing credentials surface as a {"error","status"} dict rather than a raw exception. It stops short of describing the read/write/destructive nature of the underlying actions, which matters for a multi-action admin tool.

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 opening sentence front-loads the purpose cleanly, but the trailing "CONCEPT:VW-ECO.mcp.admin-operations" line is internal taxonomy that adds no value for an agent and dilutes the structure.

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

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

An output schema exists, so return shapes needn't be explained, and the auth/error notes cover the operational essentials. However, for a dispatcher across many admin actions the description gives only category labels (users, config, diagnostics) with no sense of what those actions change.

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

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

Schema description coverage is 100% — both action and params_json are well documented in the schema, including the list_actions discovery pattern. The description adds no additional parameter meaning, so the baseline 3 applies.

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?

States a clear verb+resource ("Administer the instance") and scopes it to users, config, diagnostics, plus identity-server and favicon routes. This distinguishes it from the narrower siblings like vaultwarden_accounts or vaultwarden_ciphers, though the mixed scope (admin + identity + favicon) is slightly muddled.

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 never says when to reach for this tool versus siblings such as vaultwarden_system or vaultwarden_maintenance; the reader must infer it from the word "Administer." The action='list_actions' discovery hint lives in the schema, not the description, so the description itself offers no routing guidance or exclusions.

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

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

With no annotations, the description carries the full burden and does disclose meaningful behavior: decrypted actions return/accept plaintext (a real security constraint), and move_to_trash is a recoverable soft-delete. It omits auth requirements and rate limits, but the plaintext and soft-delete disclosures are genuine beyond-schema value.

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 core purpose is front-loaded in the first sentence, followed by tightly scoped operational notes; little is wasted. The trailing CONCEPT tag is non-functional noise but doesn't materially bloat the definition.

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?

An output schema exists, so return values need not be explained, and the description covers the key actions plus the call_operation fallback and a list_actions discovery path. For a multi-action dispatcher with no annotations, this is nearly complete, missing only auth/scope prerequisites.

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

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

Schema description coverage is 100%, so the schema already documents 'action' and 'params_json', establishing a baseline of 3. The description names the valid actions and points to list_actions, but adds no syntax or format detail for the params_json payload beyond what the schema states.

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 a specific verb+resource pair, 'Read and write vault items (ciphers),' and enumerates the primary actions (list_items, get_item, create_item, edit_item, move_to_trash). An agent can see it operates on vault items, though it never explicitly contrasts itself with siblings like vaultwarden_accounts or vaultwarden_folders.

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 explains the privileged decrypted actions and notes that other ciphers routes are reachable by route name via call_operation, which implies a usage pattern. However, it offers no explicit when-to-use-this-vs-sibling guidance or prerequisites, leaving selection between the vaultwarden_* tools largely to inference.

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

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

With no annotations, the description carries the full burden. It does add real value by disclosing that list_folders/create_folder return decrypted folder names and that the tool covers both read and write. It does not state permission requirements, whether creates can fail on duplicates, or any rate limits, leaving meaningful gaps for a mutating tool.

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 core capability and the decryption caveat are front-loaded in the first two sentences, and there is little waste. The trailing 'CONCEPT:VW-ECO.mcp.folder-operations' tag is noise for an agent reader but doesn't harm comprehension.

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?

An output schema exists, so return values needn't be explained, and the dual-mode dispatch is covered. But for a tool that includes a write operation with zero annotations, the description should say more about write behavior, permissions, and the shape of params_json per action, which it leaves to the schema alone.

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

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

Schema description coverage is 100%, so the schema already documents both action and params_json thoroughly. The description only adds the hint that create_folder takes a 'name' parameter, which is marginal beyond what the schema provides. Baseline 3 applies.

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

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

The description states a clear verb+resource ('Read and write personal-vault folders') and names the specific operations (list_folders, create_folder) plus the fallback route mechanism. The domain scoping ('personal-vault folders') distinguishes it reasonably from siblings like vaultwarden_ciphers or vaultwarden_organizations, though it doesn't explicitly contrast against them.

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 explains the dispatch model (named actions vs. raw Route.name via call_operation) and notes list_actions exists, which is useful implied guidance. However, it gives no guidance on when to prefer folder operations over sibling tools, and no prerequisites or exclusions are stated.

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

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

With no annotations, the description carries the full burden, and it does disclose real behavior: results return item ids and counts only, applying/rotating requires confirm: true, and a loose deduplication plan is never auto-applied. It omits permission/auth requirements and failure behavior, keeping it short of a 5.

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 purpose is front-loaded in the first sentence, followed by tightly packed behavioral constraints. The trailing 'CONCEPT:VW-ECO.mcp.maintenance-operations' tag is boilerplate that does not earn its place, costing a point.

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?

An output schema exists, so return values need not be explained, and the safety gating is covered. But for a multi-action tool whose real parameters are hidden in an opaque params_json object, the description gives no per-action parameter guidance, leaving a meaningful gap.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds value by revealing a 'confirm: true' flag that must be supplied inside params_json and is not documented in the schema. It still does not describe what params_json should contain for each action (e.g., which item id rotate_password needs).

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 opening sentence names specific verbs and resources: plan/apply deduplication and rotate/generate passwords. It is clearly distinct from the sibling tool set (accounts, ciphers, folders, etc.), which are all CRUD/resource tools, though the description never explicitly contrasts itself with them.

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

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

Usage is implied through the enumerated actions and the gating rules (apply/rotate need confirm: true), which tells the agent when a write is permitted. However, there is no explicit when-to-use-this-vs-alternatives statement or guidance on which action to pick in a given situation.

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

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

With no annotations, the description carries the full burden. It discloses meaningful behavior: the snapshot returns opaque identifiers, type codes, lifecycle timestamps, counts and typed relationships, and it states that commit authority lives elsewhere and backfeed is unsupported. It omits permissions, rate limits, and side-effect profile, so the disclosure is partial rather than rich.

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 opening sentence is front-loaded and the middle paragraph is dense but informative, yet the trailing 'CONCEPT:VW-KG.ingest.metadata-only' token is cryptic and does little work for an agent. Length is moderate, but the jargon density reduces effective conciseness.

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

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

An output schema exists, so return values need not be spelled out, and the two-parameter surface is small. The definition is adequate but leaves the schema-listed backfeed_metadata action in tension with its claim that backfeed is 'explicitly unsupported', and it provides no sibling-routing context, so it falls short of complete for an agent choosing among nine vaultwarden tools.

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

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

Schema description coverage is 100%, so the schema already documents 'action' and 'params_json', establishing the baseline of 3. The description names metadata_snapshot and backfeed_metadata, but adds no syntax or payload detail for params_json beyond what the schema provides. No extra value beyond structured fields.

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

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

The description gives a verb and resource ('Serve the certified metadata-only source projection') and lists what metadata_snapshot returns, but the phrasing is heavily jargon-laden and never plainly states what the tool is for. It does not distinguish this tool from siblings like vaultwarden_system or vaultwarden_maintenance, leaving the agent to infer the boundary.

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 does communicate some directional guidance: commit/checkpoint/reconcile belongs to source_sync, and backfeed is unsupported. However, there is no explicit when-to-use statement relative to the eight sibling tools; the agent must infer that this is the metadata-projection read path. Implied usage only.

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

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

With no annotations, the description carries the full burden. It discloses the dispatch-by-route-name mechanism, but nothing about mutation vs read behavior, destructive operations (org/policy deletion, LDAP import), authentication or server-config prerequisites, or rate limits — significant gaps for a dispatcher spanning dozens of write routes.

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?

Short and front-loaded: coverage statement first, dispatch mechanism second. The trailing 'CONCEPT:' token is noise, and the 'plus the public LDAP import and misc...' clause is dense, but overall it is efficient.

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?

An output schema exists, so return values need not be described. However, for an unannotated mega-dispatcher over read and write routes, the description omits the operational prerequisites and safety context an agent needs before firing it, leaving it only minimally adequate.

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

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

Schema description coverage is 100%, so the schema already explains 'action' as a Route.name and 'params_json' as path/query parameters. The description adds only the general dispatch concept and does not clarify param_json shape for specific actions, so baseline 3 applies.

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?

It names a concrete verb ('Manage') plus the resource families (organizations, collections, members, groups, policies, plus public LDAP and misc routes) and states the dispatch mechanism by route name. The domain enumeration implicitly separates it from siblings like vaultwarden_ciphers or vaultwarden_sends, though it never explicitly contrasts them.

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

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

No statement of when to use this tool versus siblings. The claim to also cover 'public' and 'misc server-settings/HIBP routes' actively blurs the boundary against vaultwarden_system and vaultwarden_maintenance without resolving which one wins. The only usage hint (action='list_actions') lives in the schema, not the description.

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

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

No annotations exist, so the description carries the burden, and it discloses the non-obvious multiplexing behavior (every sends route dispatched by route name) plus that removal is among the actions. It does not state auth requirements, permission scope, or whether removal is permanent/irreversible, which is a real gap for a tool that includes destructive operations.

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?

Front-loaded with the verb/resource summary and kept to two short lines plus an identifier. The trailing CONCEPT tag is inert for an agent but does not bloat the text meaningfully.

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?

An output schema exists and the parameters are fully documented, so return values and argument shape are covered. What is missing is behavioral context for a multiplexer with no annotations: which actions mutate state, auth/permission needs, and any irreversibility of remove.

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

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

Schema description coverage is 100% and both parameters are documented in-schema, including the list_actions discovery hint, so the baseline is 3. The description adds no format or syntax detail for action or params_json beyond what the schema already provides.

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

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

The description names specific verbs (create, list, update, remove) and the resource (Bitwarden Sends, text or file), which clearly separates it from siblings like vaultwarden_ciphers or vaultwarden_folders. It also discloses the dispatch mechanism (routing by Route.name). It stops short of enumerating the concrete operations, which it defers to the list_actions action.

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

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

Usage is implied rather than stated: the reader must infer this tool handles all sends operations and that the schema's action='list_actions' is the discovery path. There is no explicit when-to-use versus siblings or when-not to use, though the routing hint gives a workable entry point.

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

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

No annotations are provided, so the description carries the full disclosure burden. It implies a harmless read ('Read', 'public configuration'), but says nothing about whether authentication is required, rate limits, or what happens on a failing/offline server — significant gaps for an ops 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.

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

The core sentence is short, front-loaded, and waste-free. The trailing 'CONCEPT:VW-ECO.mcp.system-operations' tag adds little value for an agent but is brief enough not to be a serious defect.

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?

An output schema exists, so return values need not be explained, and the required 'action' parameter is documented in the schema. However, for a system-operations tool with no annotations, the description omits any guidance on auth requirements or when each action is appropriate, leaving it only minimally viable.

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

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

Schema description coverage is 100%, and the schema enumerates the three valid 'action' values, so the baseline is 3. The description restates the same three capabilities without adding syntax or format detail beyond the schema.

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

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

The description uses a specific verb ('Read') plus a concrete resource set ('Vaultwarden server liveness, version, and public configuration'), which maps to the three schema enum values alive/version/config. It does not name any sibling tool to differentiate itself, so it falls short of a 5.

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

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

There is no statement of when to use this tool versus alternatives such as vaultwarden_metadata or vaultwarden_admin, nor any exclusion conditions. Usage (health/version checks) can only be inferred from the word 'liveness', which is thin guidance.

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