Skip to main content
Glama
Knuckles-Team

vaultwarden-mcp

Invite user

vaultwarden_invite_user

Invite a new user to a Vaultwarden server from the admin panel by submitting the required form or JSON parameters.

Instructions

Create/invite a new instance user from the admin panel

Input Schema

NameRequiredDescriptionDefault
formNo
paramsNo
json_bodyNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.2.2

TDQS

C2.4/5.0
Behavior2/5

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 create-and-outbound nature is covered structurally. The description adds only that this happens via the admin panel; it says nothing about whether an invite email is dispatched immediately, what happens for an already-invited address, required admin permissions, or reversibility of the created account.

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

Conciseness3/5

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

A single front-loaded sentence with no filler, so it is concise. However, the brevity is under-specification rather than precision, since the one sentence carries almost no operational detail for a mutation tool.

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?

Given a create operation with openWorldHint, no output schema, and three completely undocumented parameters, the description leaves too much unknown. It does not reveal the payload shape, the expected outcome (invited vs. created user), or what a failure returns.

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

Parameters1/5

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, undocumented, and defaulted to null. The description supplies no indication of what belongs in the body — email, name, permissions, or collections — so an agent cannot construct a valid call from either source.

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

Purpose4/5

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

States a specific verb and resource ("Create/invite a new instance user") and adds the scope qualifier "from the admin panel," which separates it from organization-level invites such as vaultwarden_organizations_send_invite. It does not, however, explicitly distinguish itself from close siblings like vaultwarden_resend_user_invite or vaultwarden_confirm_invite.

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

Usage Guidelines2/5

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

The only usage signal is the phrase "from the admin panel," which implies an admin-privileged context. There is no statement of when to choose this over resend_invite, bulk_reinvite_members, or organizations_send_invite, and no prerequisites (admin role, existing email, etc.) are given.

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