Skip to main content
Glama
Knuckles-Team

vaultwarden-mcp

Remove 2fa

vaultwarden_remove_2fa
Destructive

Removes all two-factor authentication methods from a specified user as an admin recovery action when access is locked or 2FA needs resetting.

Instructions

Strip all 2FA methods from a user (admin recovery action)

Input Schema

NameRequiredDescriptionDefault
formNo
paramsNo
user_idYes
json_bodyNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.2.2

TDQS

B3.4/5.0
Behavior3/5

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

The annotations already declare destructiveHint=true, readOnlyHint=false, and openWorldHint=true, so the safety profile is known. The description adds that this removes *all* 2FA methods and frames it as an admin recovery action, but it does not describe permission requirements, irreversibility, effects on active sessions, or what happens to existing 2FA enrollment data.

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

Conciseness4/5

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

The description is a single front-loaded sentence with no filler. It is appropriately concise, though for a destructive admin operation with four parameters and no schema descriptions, it is arguably too terse to be fully self-contained.

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

Completeness2/5

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

For a destructive admin recovery tool with no output schema and 0% schema description coverage, the description is incomplete. It does not explain prerequisites, authorization needs, side effects, or how the generic form/params/json_body parameters are used.

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

Parameters2/5

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

Schema description coverage is 0%, and the description only implies a 'user' target without documenting the required user_id parameter or the form, params, and json_body parameters. With four parameters and no schema-level descriptions, the description does not compensate for the missing parameter semantics.

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

Purpose5/5

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

The description states a specific verb and resource: 'Strip all 2FA methods from a user.' It also scopes the operation as an 'admin recovery action,' which distinguishes it from sibling tools like disable_twofactor or disable_authenticator that target individual 2FA methods.

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

Usage Guidelines3/5

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

The phrase 'admin recovery action' implies a usage context, suggesting this is for administrative recovery rather than routine user self-service. However, it does not explicitly state when to choose this tool over siblings such as vaultwarden_disable_twofactor or vaultwarden_disable_authenticator, nor does it name exclusions.

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

Deploy Server

Other Tools