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?

Annotations already declare this is a non-read-only, non-destructive, open-world mutation, so safety signaling is covered. The description adds that the output is a client_credentials login secret, which is genuinely useful, but it omits the critical behavioral fact that rotating invalidates the previous key and that the plaintext key is only returned once.

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?

A single compact sentence with the key fact front-loaded and no filler. It is arguably too terse for a credential-mutating operation, but nothing is wasted.

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 credential rotation endpoint with an opaque schema, no output schema, and zero annotation detail on side effects, the description says nothing about what gets invalidated, whether the new key is returned in the response, or what the three body parameters are for. An agent cannot call this safely on the strength of the description 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 0% and the three parameters (form, params, json_body) are untyped with 'default: null', so the schema provides essentially no guidance. The description does not mention any parameter at all — not even whether a name, expiration, or scope can be supplied.

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?

Names a specific verb pair (generate/rotate) and a precise resource (the personal API key), and the parenthetical 'client_credentials login secret' clarifies what the key is actually used for. The qualifier 'personal' distinguishes it from the organization-level key tools, though the sibling vaultwarden_accounts_rotate_api_key is left un-differentiated.

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 call this versus vaultwarden_accounts_rotate_api_key or vaultwarden_organizations_rotate_api_key, both of which appear in the sibling list and overlap in intent. The word 'personal' only weakly implies account-scope, and there are no prerequisites or exclusions given.

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?

Annotations already declare readOnlyHint=false, openWorldHint=true, destructiveHint=false, so the safety profile is covered. The description adds the login-context and the alternate mount path, but does not explain the mild tension between the retrieval wording ('Get') and the non-read-only annotation, nor return/pagination behavior. With annotations present, this adds modest value beyond structured data.

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?

A single front-loaded sentence with the purpose stated first and the mount alias in a compact parenthetical. Efficient with little waste, though the parenthetical is secondary detail that could be trimmed.

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 simple prelogin lookup with no output schema, the description conveys what is returned (KDF type/iterations) and its login context, which is the core need. However, with three undocumented body parameters and no guidance on how to supply the email, it is only adequately complete.

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 0% across three parameters (form, params, json_body), and the description does not compensate. It implies an 'email' input exists but never says which parameter carries it or what form/params mean, so there is little guidance beyond the bare opaque 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 gives a specific verb and resource: 'Get KDF type/iterations for an email before login.' That is concrete enough for an agent to know it retrieves key-derivation config. It does not explicitly distinguish itself from the near-identical sibling vaultwarden_identity_post_prelogin, though the parenthetical about the alternate mount provides partial differentiation.

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?

'Before login' implies the timing context in which to use it, but the description never names or rules out alternatives such as vaultwarden_identity_post_prelogin or vaultwarden_prelogin_password. Usage is therefore implied rather than stated, leaving the agent to infer which prelogin tool to pick.

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?

Annotations declare readOnlyHint=false and destructiveHint=false, consistent with a rotate operation, so there is no contradiction. But the description adds nothing beyond the annotations: it does not say whether the prior key is immediately invalidated, whether clients using the old key break, or what credentials the caller must present for such a security-sensitive mutation. For a write tool touching credentials, this is a significant disclosure gap.

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?

A single front-loaded sentence with zero padding, so there is nothing to trim. The problem is under-specification rather than verbosity: the brevity costs the agent information it needs.

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?

A credential-rotating mutation with three opaque, undocumented parameters, no output schema, and only minimal annotations cannot be described in five words. Nothing tells the agent what the call returns (the new key?), whether confirmation is required, or what side effects occur.

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?

Three parameters (form, params, json_body) with 0% schema description coverage and no types or enums, and the description mentions none of them. The schema and the description together leave the agent with no idea what to supply, so the description fails to compensate for the coverage gap.

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 specific verb and resource ("rotate the personal API key"), and the word "personal" implicitly distinguishes it from the sibling vaultwarden_organizations_rotate_api_key. However, it never names or contrasts that alternative explicitly, so the agent must infer the scope distinction rather than being told it.

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 guidance on when to rotate (e.g., key compromise, scheduled rotation), no prerequisites such as authentication or master password confirmation, and no mention of the organization-key alternative. The agent gets no criteria for selecting this tool over its siblings.

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?

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds the meaningful prerequisite that a code must already be generated, but says nothing about what happens on an invalid code, whether an existing authenticator is replaced, or what auth/permissions are required for this mutation.

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?

A single front-loaded sentence with no filler. It is efficient, but for a mutation tool with three opaque parameters this brevity borders on under-specification rather than tight writing.

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?

A state-changing 2FA mutation with no output schema, 0% schema coverage, and three opaque parameters needs far more than one sentence. The description omits parameter mapping, error behavior, and side effects, so an agent cannot reliably construct a correct call from the definition 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 0% and all three parameters (form, params, json_body) are untyped and undocumented. The description mentions a 'generated code' but never says which parameter carries it or in what format, leaving the agent to guess at the entire call shape.

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 specific verb and resource: enabling TOTP 2FA by confirming a generated code. This clearly separates it from a generic 'verify' or 'get' tool, though it does not name the sibling it pairs with (generate_authenticator) or distinguish itself from activate_authenticator_put.

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 phrase 'confirming a generated code' implies the prerequisite workflow (generate first, then activate), which is useful. However, it gives no explicit when-to-use guidance, no exclusions, and no pointer to the near-duplicate _put variant or the alternative activate_duo/webauthn/yubikey tools.

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?

Annotations declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so the safety profile is known. The description adds that it specifically enables TOTP 2FA, which is useful context beyond the generic title. However, it does not disclose side effects, required permissions, or what happens upon activation.

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 a single, front-loaded sentence with no wasted words. It is efficient, though given the tool's complexity (3 undocumented params), a bit more detail could be warranted without sacrificing 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?

For a mutation tool with 3 parameters at 0% schema coverage and no output schema, the description is too brief. It does not explain how to use the parameters, what the response looks like, or any prerequisites, leaving the agent with significant gaps.

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 0% for the three parameters (form, params, json_body). The description mentions none of them, so it provides no meaning beyond the bare schema names. This is inadequate for a tool with undocumented parameters.

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 specific verb and resource: 'Enable TOTP 2FA'. It also notes '(PUT alias)', hinting at the HTTP method, but does not differentiate this tool from its sibling `vaultwarden_activate_authenticator` (non-PUT version).

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 indication of when to use this tool versus alternatives. It does not mention prerequisites, side effects, or when to choose the PUT alias over the regular activate authenticator tool.

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?

Annotations already state readOnlyHint=false, openWorldHint=true, and destructiveHint=false, so the safety profile is partly covered. The description adds that this may update existing Duo setup and supports Duo OIDC, but it does not disclose permissions, side effects, or authentication requirements.

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 single sentence is front-loaded, direct, and free of filler. However, it is arguably too terse for a configuration mutation with opaque parameters.

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 non-read-only, open-world 2FA configuration tool with three undocumented parameters and no output schema, the description leaves major gaps. It does not explain expected input shape, authorization, effects on existing Duo configuration, or return behavior.

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?

There are 3 parameters with 0% schema description coverage, and the description says nothing about what form, params, or json_body should contain. It does not compensate for the schema's lack of type or field-level detail.

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+resource: 'Enable/update Duo (or Duo OIDC) 2FA.' It is clear what the tool does, but it does not distinguish itself from close siblings such as vaultwarden_activate_duo_put or vaultwarden_get_duo.

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 phrase 'Enable/update' implies activation or update, but there is no explicit guidance on when to use this tool versus get_duo or activate_duo_put, nor any prerequisites or when-not-to-use conditions.

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?

Annotations already establish that this is a non-readOnly, openWorld, non-destructive mutation. The description adds that the mutation enables or updates Duo 2FA, but it does not disclose authentication requirements, side effects, or what happens to existing Duo configuration.

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 very short and front-loaded, but it is a terse fragment rather than a sufficient explanation. The cryptic '(PUT alias)' parenthetical does not earn its place without clarifying the alternative it refers to.

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?

This is a mutation tool with three opaque parameters, no output schema, and only generic safety annotations. The description says what the operation does broadly, but it omits prerequisites, parameter guidance, and behavioral effects needed to invoke it correctly.

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 schema defines three parameters (form, params, json_body) with zero percent description coverage, and the description provides no meaning, format, or examples for any of them. An agent cannot determine what to put in these fields from the definition alone.

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 specific verb and resource: 'Enable/update Duo 2FA'. It also hints at a PUT-specific alias, but it does not explain how this differs from the sibling vaultwarden_activate_duo tool.

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 explicit guidance on when to use this tool versus vaultwarden_activate_duo or other 2FA activation methods. The '(PUT alias)' phrase implies a transport variant but does not provide usable selection criteria.

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?

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=true, so the agent knows this is a non-destructive write. The description adds only that it concerns 2FA key registration. It does not state whether existing keys are replaced, whether re-authentication is required, or what the call returns.

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 single sentence is front-loaded and free of waste. It is, however, under-specified rather than appropriately concise, given how opaque the schema is.

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 mutation tool with three undocumented parameters, no output schema and no annotation detail beyond the safety hints, the description leaves critical gaps. It is unclear what payload to supply or what a successful response looks like.

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?

All three parameters (form, params, json_body) have 0% schema description coverage and are entirely generic. The description supplies no information about what the request body must contain, such as credential payload or challenge response, so parameter meaning is not recoverable from the definition.

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 a specific verb and resource: registering a new WebAuthn security key for 2FA. An agent can grasp the action. However, it offers no differentiation from the sibling vaultwarden_activate_webauthn_put, so a choice between the two still requires opening the schemas.

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 gives no when-to-use context, no prerequisites and no exclusions. It does not mention the vaultwarden_generate_webauthn_challenge or get_api_webauthn steps that normally precede activation, nor when to choose this tool over vaultwarden_activate_webauthn_put or vaultwarden_delete_webauthn.

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?

Annotations already declare readOnlyHint=false and destructiveHint=false, so the write nature is known. The description adds nothing about what registration does, whether an existing key is replaced, what auth or prior challenge is required, or what happens on failure.

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 single sentence is front-loaded and waste-free, but it is under-specified rather than appropriately concise for a three-parameter mutation with no documented schema.

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 mutation tool with three undocumented parameters, no output schema, and openWorldHint=true, the description is far too thin. It leaves an agent without enough context to construct the request or understand the effect.

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?

All three parameters (form, params, json_body) have 0% schema description coverage, and the description mentions none of them. It provides no syntax, format, or meaning for the opaque payload objects, so it fails to compensate for the coverage gap.

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 a specific verb ('Register') and resource ('WebAuthn key'), and the '(PUT alias)' parenthetical separates it from the non-PUT sibling vaultwarden_activate_webauthn. However, 'Register' conflicts slightly with the name's 'activate', and the HTTP-method framing doesn't clarify user-level intent.

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 guidance on when to use this versus vaultwarden_activate_webauthn, activate_authenticator, or generate_webauthn_challenge. The '(PUT alias)' note implies a variant but gives no condition for selecting it.

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?

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=true, so the safety profile is known. The description adds nothing beyond them: no statement of required permissions, whether the change is reversible, whether an existing 2FA method is replaced, or what happens on failure. For a security-setting mutation this is a thin contribution.

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?

Four words with zero filler and the action front-loaded, but the brevity crosses into under-specification rather than efficient 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?

A mutation tool with no output schema, three wholly undocumented parameters, and no annotation detail about the auth/permission model needs more than this. The description leaves the agent unable to construct a correct call with confidence.

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?

Three parameters (form, params, json_body) exist with 0% schema description coverage and no types, only default null. The description mentions no parameters at all, so the agent gets no help on what to supply to activate a YubiKey (e.g. an OTP or key identifier).

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 pairs a specific verb ('Enable') with a specific resource ('YubiKey OTP 2FA'), so the agent knows exactly what capability is being turned on. It does not, however, distinguish this tool from the near-identical sibling vaultwarden_activate_yubikey_put, nor from generate_yubikey, leaving ambiguity about which to call.

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 guidance on when to use this versus vaultwarden_activate_yubikey_put, vaultwarden_generate_yubikey, or the other activate_* 2FA tools. No prerequisites (e.g. a YubiKey must already be generated) 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?

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond that: it does not say what state is changed, whether an existing 2FA method is replaced, what credentials/permissions are needed, or that the body content drives the activation.

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?

A single front-loaded phrase with no filler, but it is terse to the point of under-specification rather than efficient. Nothing is wasted, but almost nothing is delivered.

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?

This is a state-changing 2FA endpoint with three opaque body parameters, no output schema, and no annotations covering semantics beyond safety hints. The description does not supply the missing details an agent needs to construct a correct call, so it is materially incomplete.

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?

All three parameters (form, params, json_body) have 0% schema description coverage, no types, and null defaults. The description mentions none of them, and for a body-driven activation endpoint the agent is left with no idea what belongs in json_body.

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?

"Enable YubiKey OTP 2FA" gives a recognizable verb and resource, and "(PUT alias)" hints this is the PUT form of the same operation. But it never distinguishes this from the sibling vaultwarden_activate_yubikey (or activate_authenticator/duo/webauthn variants), so an agent cannot tell which one to pick from the description alone.

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 parenthetical "PUT alias" implies equivalence with another activate_yubikey tool but does not say when to prefer this one, what the alternative is called, or what prerequisites (existing YubiKey, 2FA state) apply. No when/when-not guidance is present.

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?

Annotations already declare destructiveHint=true, readOnlyHint=false and openWorldHint=true, so the safety profile is known. The description adds real value by disclosing the cascade ('all its data'), but says nothing about required admin privileges, whether confirmation is expected, or whether the deletion is recoverable in any way.

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?

A single front-loaded sentence with no filler — the destructive scope leads. It is efficient, though the terseness borders on under-specification for a high-impact operation.

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 high-blast-radius admin operation with 4 undocumented parameters and no output schema, the description omits permissions, confirmation expectations, post-deletion effects on members/collections, and the identity of competing delete endpoints. 'Permanently delete … and all its data' is accurate but far from 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?

Schema description coverage is 0% and four parameters exist. The description never mentions org_id or the three generic wrapper params (form, params, json_body), leaving their meaning and expected formats entirely to inference. Only the required-parameter list in the schema hints that org_id is mandatory.

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 specific verb ('Permanently delete') and resource ('an organization'), plus the scope of what is removed ('all its data'). It does not, however, distinguish this from near-identical siblings such as vaultwarden_organizations_delete_organization, vaultwarden_post_delete_organization, or vaultwarden_leave_organization, so an agent must guess which delete variant is the admin one.

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 guidance on when to use this versus the many other organization-removal siblings (leave_organization, purge_org_vault, organizations_delete_organization). No prerequisites, no admin-permission note, and no 'do not use if…' exclusion is given despite the tool being destructive.

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?

Annotations already declare non-destructive, open-world behavior, so the bar is lower. The description adds one genuinely useful behavioral fact — that a response also exercises DB connectivity — but says nothing about auth requirements, expected response shape, or what a failure indicates.

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?

A single short clause with the core purpose front-loaded and no filler. It is arguably too terse rather than padded, but nothing is wasted.

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?

No output schema exists, so the description could reasonably say what a healthy vs unhealthy result looks like and whether arguments are needed. For a trivial probe this is close to adequate, but the undocumented parameters leave a real hole.

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 0% across three generic parameters (form, params, json_body), and the description supplies no parameter meaning at all. An agent cannot tell from either source whether these should be left empty for a plain health ping.

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 specific verb+resource: liveness/health check, plus the extra detail that it verifies DB connectivity. That distinguishes it from pure version/status siblings like vaultwarden_version or vaultwarden_now, though it never names an alternative explicitly.

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 — an agent can infer this is the 'is the server up and can it reach the DB' probe. There is no explicit when-to-use vs vaultwarden_version, vaultwarden_config, or the diagnostics tools, and no failure-handling guidance.

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?

Annotations declare it is a non-read-only, non-destructive, open-world operation; the description adds real value beyond that by stating the concrete behavior — the normal waiting period is bypassed — and that the caller must be the grantor. It does not say what state the request ends in on failure or what is returned.

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?

A single front-loaded sentence with no filler; the key qualifier (skips wait) is placed prominently. It is efficient but so terse that it borders on under-specification rather than 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?

For a state-mutating tool with 4 parameters (three of them undocumented polymorphic envelopes) and no output schema, the description should at least identify the required request identifier and note the permission model. It supplies the semantic effect but leaves the entire calling contract unstated.

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 0% across 4 parameters, including three opaque fields (form, params, json_body), so the description carries the full burden — yet it never mentions emer_id or any other parameter. An agent cannot tell from the text what identifier to supply or what the form/params/json_body envelopes are for.

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 specific verb (approves), resource (emergency access request), the actor (grantor) and the effect (skips wait). This clearly separates it from sibling emergency-access tools such as reject_emergency_access or takeover_emergency_access, though it does not name any sibling explicitly.

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 phrase 'in-progress request' implies a precondition (a pending request must already exist) and 'grantor' implies who may call it. However, it never states when to prefer it over confirm_emergency_access or when the wait should be allowed to elapse instead, so routing is left 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?

Annotations already mark this as non-read-only, non-destructive, and open-world. The description adds useful context that archiving hides the cipher from the default view and is distinct from trash, but it does not explain reversibility, permissions, effects on collections or folders, or what the response contains.

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 a single front-loaded sentence with no wasted words. The parenthetical distinction from trash is compact and directly useful.

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?

This is a mutation tool with four parameters, no output schema, and zero schema description coverage. The one-line description does not explain the optional parameters, required identifiers, permissions, or what archiving changes, so it is not complete enough for confident invocation.

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 0%, so the description must compensate for four undocumented parameters. It implies that one cipher is targeted, loosely mapping to cipher_id, but it says nothing about form, params, or json_body, nor does it use the actual parameter name.

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 specific verb and resource: archive one cipher. It also explicitly distinguishes archiving from trashing, which is helpful. However, it does not name nearby siblings such as vaultwarden_archive_cipher_selected or vaultwarden_unarchive_cipher_put, so sibling differentiation is incomplete.

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 implies when to use this tool by contrasting archiving with trash: use this to hide a cipher from the default view rather than deleting it. It does not specify when to choose this over vaultwarden_archive_cipher_selected or when to use the unarchive sibling instead.

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?

Annotations already declare readOnlyHint=false and destructiveHint=false, so the agent knows this mutates state without being classified destructive. The description adds nothing beyond that — it doesn't say what happens to already-archived items, whether archiving is reversible (unarchive sibling exists but isn't referenced), or what permissions are required. Given three opaque parameters, 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.

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

Three words, zero waste, but under-specification rather than efficiency — the description is too short to carry any of the needed information. Nothing is front-loaded because there is nothing to front-load.

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 mutating bulk operation with zero schema coverage and no output schema, the description should explain the selection mechanism and the effect of archiving. It leaves all of that unstated, though the name plus annotations at least convey it is a non-destructive bulk write.

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 0% and the three parameters ('form', 'params', 'json_body') are completely generic containers with no types or descriptions. The description does not mention how the cipher selection is expressed, so the agent has no way to know what to pass.

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 a specific verb and resource ('archive ciphers') and adds scope ('bulk'), which distinguishes it from the single-cipher archive variant. However, it never explains what 'selected' means — presumably a set of cipher IDs — and does not differentiate it from vaultwarden_archive_cipher_put or vaultwarden_unarchive_cipher_selected beyond the word 'bulk'.

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 guidance on when to use this versus vaultwarden_archive_cipher_put or the newer ciphers_* tools. No prerequisites (authentication, ownership/admin rights) or exclusions are stated; the agent must infer everything from the name.

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?

Annotations already declare a non-read-only, non-destructive, open-world operation, so the safety profile is partly covered. The description adds the sqlite-only precondition, which is real context, but says nothing about admin privileges required, whether the backup is synchronous or async, where the file is written, or what the response contains.

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?

A single eight-word sentence with the constraint parenthesized at the end — zero waste and front-loaded. It is defensibly efficient, though bordering on under-specified for a mutating admin operation.

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 state-changing backup trigger with no output schema, three undocumented parameters, and no stated auth or async behavior, the description leaves too much unknown. An agent cannot predict the effect, the wait time, or the return value from this text 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 0% and the three parameters (form, params, json_body) are opaque generic passthrough wrappers with no explanation anywhere. The description does not mention parameters at all; at best 'on-demand trigger' implies the call is effectively parameterless, but it never clarifies what the passthrough fields mean or whether any are needed.

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 specific verb (Trigger) and resource (on-demand database backup) plus an environment constraint (sqlite only), so an agent immediately knows what happens. It is clear but does not position itself relative to any of the many sibling administrative tools, though none of them appear to be backups.

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 '(sqlite only)' qualifier is a genuine applicability condition that tells the agent when this tool will work. However, there is no explicit when-to-use guidance versus alternatives (e.g. scheduled/automatic backups, or the other maintenance tools like vaultwarden_maintenance_plan_deduplication), and no prerequisites 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?

Annotations already declare this is a non-read-only, non-destructive operation, and the description usefully adds that the org key is delivered to each member. It does not disclose whether this affects all accepted invites in the org, what permissions are required, or whether the action is idempotent.

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?

A single front-loaded sentence with no wasted words. The key effect and scope are conveyed efficiently.

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 bulk mutation with four undocumented parameters and no output schema, the description is too thin. It omits target selection, permission requirements, expected response, and failure behavior, leaving the agent with significant unknowns.

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 0% across four parameters, including the required org_id, and the description does not compensate. It only vaguely implies organizational scope through 'org key' and gives no meaning for form, params, or json_body.

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 specific verb and resource: bulk-confirm accepted invites, plus the effect of delivering the org key. The word 'Bulk' differentiates it from the sibling vaultwarden_confirm_invite, though it does not name that sibling explicitly.

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 phrase 'accepted invites' implies the precondition for use, but there is no explicit guidance on when to choose this over confirm_invite, bulk_reinvite_members, or other invite-related siblings, 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?

Annotations already declare destructiveHint=true, readOnlyHint=false, and openWorldHint=true, so the safety profile is known. However, the description adds nothing beyond the destructive framing — it does not say what 'bulk' means (selected IDs? all groups in org?), whether deletion is reversible, or what authorization is required.

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 words, but this is under-specification rather than conciseness — there is no information to front-load. Nothing is wasted because nothing is said.

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 destructive bulk mutation with four undocumented parameters, no output schema, and no annotation detail beyond the hint flags, the definition is wholly inadequate. An agent could not safely construct a call from this.

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 0% across four parameters, including the opaque 'form', 'params', and 'json_body' fields, and the description provides zero compensation. An agent cannot determine how to specify which groups to delete or what org_id format is expected.

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?

Tautological: description restates name/title.

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 guidance whatsoever on when to use this versus the numerous single-delete and other bulk-delete siblings. No prerequisites (org admin rights, group selection mechanism) are stated, leaving the agent to infer everything from the name.

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?

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered. The description adds only the org scoping, and says nothing about whether member data is permanently removed, what happens to vaults/collections they owned, or whether admin privileges are required — all critical for a destructive bulk operation.

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?

A single short sentence with no filler, but it is under-specified rather than concise; nothing is front-loaded because there is almost nothing to front-load.

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?

A destructive bulk mutation with four opaque parameters, no output schema, and no annotations beyond the destructive hint. The description should at minimum explain the member-selection input and any irreversible consequences; it does neither.

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 0%: org_id, form, params, and json_body have no types or descriptions. 'From the org' hints that org_id scopes the operation, but nothing explains how the target members are specified (presumably json_body) — the most important parameter semantics for this tool are missing.

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 specific verb ('Bulk remove') and resource ('members from the org'), which is clear. However, it does not differentiate from nearby siblings like vaultwarden_bulk_revoke_members or vaultwarden_delete_member, so an agent cannot tell which one to pick from the description alone.

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 guidance on when to use this versus bulk_revoke_members, delete_member, or bulk_restore_members. No prerequisites, no consequences stated, no 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?

Annotations already declare destructiveHint=true and openWorldHint=true, so the safety profile is known. The description adds nothing beyond that: no mention that deletion is irreversible, whether it requires elevated org permissions, or how many collections the bulk payload can contain.

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?

A single front-loaded sentence with no filler, but its brevity comes from omission rather than efficiency. There is no wasted text, yet almost nothing is said.

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?

A destructive bulk mutation with an undocumented four-parameter schema, no output schema, and a large ambiguous sibling surface. The description leaves the critical question (how ids are supplied) unanswered, which is well short of complete.

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 0% across four parameters, so the description must compensate and does not. It refers to 'id' that does not exist as a named parameter and never explains whether the id list belongs in form, params, or json_body.

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 recognizable verb+resource (bulk delete collections), which is enough to distinguish it from the single-item vaultwarden_delete_organization_collection. However, 'by id' is misleading: the schema exposes no 'id' parameter, only org_id plus opaque form/params/json_body containers, so an agent cannot tell where the ids actually go.

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 versus the single-collection delete sibling or vaultwarden_bulk_delete_groups, and no prerequisites such as admin/owner role or org scoping. The agent must infer everything from the tool name.

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?

The description says 'fetch', implying a read operation, yet annotations declare readOnlyHint=false, a mismatch an agent must resolve. Beyond this inconsistency it says nothing about authorization requirements, whether keys of deleted/locked users are included, or behavior for missing ids, though openWorldHint and destructiveHint=false are separately provided in annotations.

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?

A single efficient sentence with no filler, front-loading the operation and resource. It is appropriately short, though that brevity contributes to the semantic gaps noted elsewhere.

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?

With no output schema, 0% parameter coverage, and four opaque parameters, the description does not provide enough to call the tool correctly. An agent cannot determine where to pass user ids, what the response shape is, or how partial failures are handled.

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 0% and the properties (form, params, json_body) are opaque untyped blobs. The description mentions 'a list of user ids' but never maps that to any parameter (only org_id is required and undocumented), leaving the actual user-id payload location ambiguous.

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 specific verb (bulk-fetch) and resource (public keys) with scope (for a list of user ids). However, it does not distinguish itself from sibling read tools like vaultwarden_get_public_keys, vaultwarden_get_organization_public_key, and vaultwarden_get_organization_keys, so an agent cannot easily tell which key-fetching tool to choose.

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 gives no guidance on when to use this bulk variant versus the singular get_public_keys or the organization-scoped key tools. No prerequisites, no when-not conditions, and no alternatives are named despite many closely related siblings.

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?

Annotations already disclose that this is not read-only, is open-world, and is non-destructive. The description adds almost no behavioral context beyond that: it does not clarify which members are selected, whether emails are actually sent, what permissions are required, or whether there are rate limits or side effects.

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 a single front-loaded phrase with no wasted words, which is structurally efficient. However, it is so terse that it omits essential information rather than being appropriately sized for a bulk operation with four parameters.

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?

This is a bulk mutation-style operation with no output schema and four parameters at 0% schema description coverage. The four-word description does not explain selection criteria, required permissions, expected outcome, or how to invoke it correctly, so it is not complete enough for confident use.

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 0% and the description mentions none of the four parameters. The required org_id is not explained, and the meanings or expected formats of form, params, and json_body are completely absent, leaving an agent unable to infer parameter usage.

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 specific verb ('resend') and resource ('pending invites') with a bulk scope, so the general action is clear. However, it does not distinguish this tool from closely related siblings such as vaultwarden_reinvite_member, vaultwarden_resend_invite, vaultwarden_resend_user_invite, or vaultwarden_bulk_confirm_invite.

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 phrase 'Bulk resend pending invites' implies the tool is used when several pending invitations need to be resent, but it gives no explicit when-to-use versus single-member alternatives, no prerequisites, and no exclusions or warnings.

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?

Annotations declare readOnlyHint=false, destructiveHint=false, openWorldHint=true, so the agent knows this is a non-destructive mutation against an external system. The description adds nothing beyond that: no statement of which members are affected, how they are identified, whether it requires an admin token, or what happens to already-active members.

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 four-word phrase is concise and technically front-loaded, but it is under-specification rather than concision; every sentence that would earn its place is missing.

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?

A mutation tool with four undocumented parameters, no output schema, and no annotations covering semantics beyond safety hints. The description leaves the agent unable to determine required authorization, the shape of json_body, or the effect/return of the operation.

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 0% and the four properties (form, org_id, params, json_body) have no types or descriptions. The description supplies no parameter meaning at all — not even which identifier selects the members to restore, beyond the required org_id.

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?

"Bulk restore revoked members" is essentially a restatement of the title "Bulk restore members" with one qualifier added. It names a verb and resource, but gives no clue how it differs from sibling tools like vaultwarden_restore_member, vaultwarden_restore_member_vnext, or vaultwarden_bulk_revoke_members (the inverse operation).

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 guidance on when to use this bulk endpoint versus the singular vaultwarden_restore_member/vaultwarden_restore_member_vnext, nor any prerequisite (admin role, org scope, whether members must already be revoked). An agent facing a dozen restore/revoke siblings has nothing to route on.

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?

Annotations already declare readOnlyHint=false, openWorldHint=true and destructiveHint=false, but the description adds no context about what revocation does to the affected members (access removal? data retention?), whether it requires admin/owner rights, or whether it is reversible. For a bulk mutation on an org, this is a significant transparency gap.

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 words is not wasteful but is severe under-specification rather than conciseness. There is no front-loaded explanation of effect or scope to anchor the call.

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?

A bulk, open-world, mutation tool with four undocumented parameters, no output schema, and a three-word description leaves an agent with essentially nothing to act on. The description is completely inadequate for the tool's 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 0% and all four parameters (form, org_id, params, json_body) are undocumented and largely untyped, with only org_id required. The description offers no meaning for any of them, leaving an agent unable to construct a valid request.

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?

Tautological: description restates name/title.

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?

Nothing states when to use this versus the many adjacent siblings such as vaultwarden_revoke_member (single), vaultwarden_bulk_delete_member, or vaultwarden_bulk_restore_members. The only implicit signal is the word "bulk," which comes from the name, not from guidance about prerequisites 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?

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=true. The description adds valuable behavioral context beyond that: create_item accepts plaintext item content, which must never be logged or echoed elsewhere, and it is part of the decrypted cipher actions. It does not contradict the annotations.

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 front-loads the tool purpose, but it mixes in family-level security guidance and notes about unrelated actions such as move_to_trash. Those warnings are relevant context, but the paragraph is not tightly focused on how to invoke create_item.

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?

Annotations and an output schema are present, and the description covers the plaintext handling caveat, so the agent knows the action is a write involving sensitive content. However, for a create operation whose only input is params_json, the description does not explain what item fields are expected, leaving a meaningful invocation 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?

The tool has a single params_json parameter with 100% schema description coverage, but the schema only says it is a JSON object of parameters for the action. The description adds no detail about what fields should go inside params_json for a create-item operation, so it does not improve parameter understanding beyond the generic 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 names a specific action and resource: "Create item (vaultwarden_ciphers)" and frames it within vault item cipher operations. It is clear what the tool does, but it does not explicitly distinguish this high-level create action from the many sibling create-cipher routes such as vaultwarden_post_cipher or vaultwarden_post_ciphers_create.

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 that create_item is one of the high-level decrypted cipher actions and says every other ciphers route is reachable via call_operation. However, it does not explicitly state when to choose this tool over alternatives, nor does it give prerequisites or exclusions for creating an item.

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?

Annotations already declare readOnlyHint=false, destructiveHint=false and non-idempotent, so safety basics are covered. The description adds genuinely useful non-obvious context: this action handles plaintext item contents that must never be logged or echoed, and that soft-delete lives on move_to_trash rather than here. It does not say whether an edit replaces or merges fields, which matters for a non-idempotent write.

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 first sentence is front-loaded and useful, but several sentences describe other actions (list_items, get_item, create_item, move_to_trash) rather than this one, and the CONCEPT tag adds no operational value. Proportions are only partly appropriate for a single-action tool.

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. But for a non-idempotent mutation taking an arbitrary JSON parameter bag, the definition omits what an edit requires, whether partial updates are allowed, and what happens to unspecified fields — significant gaps the agent cannot resolve from structured data.

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 schema advertises 100% coverage but only documents an opaque 'params_json' JSON blob with no field breakdown, so real parameter semantics are effectively undocumented. The description does not name a single expected key (id, name, login, notes, folderId) or explain the JSON structure an agent must construct, leaving the caller to guess.

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 'Edit item (vaultwarden_ciphers)' and then describes cipher read/write generally, so the agent can infer it modifies an existing vault item. However, the bulk of the text is collection-level boilerplate and never distinguishes edit_item from the many sibling write routes (put_cipher, post_cipher_partial, put_cipher_partial, edit_member). The specific action is stated but not meaningfully differentiated.

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 guidance on when to use edit_item versus the numerous other cipher mutation tools in the sibling list, nor any prerequisites (item id, ownership, org/collection membership). The only routing hint given ('every other ciphers API route is reachable via call_operation') is generic and does not help select this tool.

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?

Annotations already declare readOnlyHint/idempotent/non-destructive, but the description adds material context the annotations cannot: get_item returns plaintext (decrypted) item contents and the caller must not log or echo them. That is a genuine, decision-relevant disclosure. It falls short of 5 because it says nothing about required access, behavior when the item is missing, or trash state.

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 tool-specific content is a single short line; the remainder is concept-level boilerplate about create_item, edit_item, move_to_trash and call_operation that does not earn its place in a get_item definition. It is front-loaded with the name, but the payload is diluted by unrelated actions.

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?

With an output schema present, return structure need not be described, and the plaintext handling warning covers the main risk. Still missing for a read tool: what identifier form to pass in params_json and what happens on a missing or trashed item, which the caller must infer.

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 single parameter is an opaque params_json blob whose schema description ("JSON object of parameters for the action") gives no key-level detail; schema coverage is nominally 100%, so the baseline of 3 applies. However, the description does not compensate by naming the cipher id that get_item presumably requires, leaving the caller to guess the payload shape.

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 name and first sentence ("Get item (vaultwarden_ciphers). Read and write vault items (ciphers)") imply retrieval of a single cipher, but the body is family-level boilerplate that lumps get_item with list/create/edit/move_to_trash. It never differentiates this tool from close siblings such as vaultwarden_get_cipher, vaultwarden_get_cipher_details, or vaultwarden_ciphers_list_items, so an agent must infer which retrieval tool to pick.

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 use this tool rather than the list or other get variants, nor what condition selects it. The only routing statement ("Every other ciphers API route is reachable by its route name via call_operation") is about the escape hatch, not about choosing get_item.

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?

Annotations already declare readOnly/idempotent/non-destructive, so the description is not carrying the safety burden, yet it still adds real value: it discloses that decrypted actions return plaintext item contents, warns never to log or echo them, and notes that move_to_trash is a recoverable soft-delete. The one gap is that it does not describe listing behavior such as paging or result limits.

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 plaintext warning is valuable and correctly front-loaded, but the opening two sentences mix this tool's purpose with family-level read/write semantics, and the trailing CONCEPT tag and backticked route enumeration are payload-free for an invoking agent. Roughly half the text serves the tool group rather than this call.

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?

With an output schema present, the description need not explain return shape, and it does cover the sensitive-plaintext aspect well. It is still incomplete for a listing tool: no guidance on the params_json contents or on how listing results are scoped, which is the main decision an agent faces here.

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 single parameter is a free-form params_json bag whose schema text ('JSON object of parameters for the action') conveys no field-level meaning, so the nominal 100% coverage is formal rather than substantive. The description does not say which keys the list action accepts (search terms, organization/folder filters, pagination), leaving the agent to guess the pass-through 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 first sentence names the resource ('List items (vaultwarden_ciphers)'), but the following sentence 'Read and write vault items (ciphers)' describes the whole cipher family rather than this read-only action, blurring what the tool actually does. Nothing distinguishes it from close siblings such as vaultwarden_get_ciphers, vaultwarden_get_cipher, or vaultwarden_ciphers_get_item, which an agent could easily pick instead.

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: the name and 'list_items' phrase suggest a listing call, and the note that other ciphers routes are reachable via call_operation is a partial routing hint. There is no statement of when to choose this over get_item (single item) or get_ciphers, nor any prerequisites or filter conventions for listing.

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?

Annotations declare destructiveHint=false and readOnlyHint=false, and the description corroborates this by explaining the delete is soft and recoverable — useful context beyond the flags. It also adds a genuine operational constraint (never log or echo decrypted item contents), though that note is domain-wide boilerplate rather than specific to this action.

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 action-specific sentence is short and front-loaded, but the surrounding text is shared ciphers-domain boilerplate about decrypted actions and call_operation that does little for an agent choosing this specific tool. Roughly half the description is not about moving to trash.

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 and annotations are present, so the description doesn't need to explain returns or the safety profile. It covers recoverability, the id-based targeting, and the confidentiality constraint — enough for correct invocation, with only the payload structure for params_json left thin.

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?