Initiate emergency access

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

Annotations already declare this is a non-destructive mutation (readOnlyHint=false, destructiveHint=false), so the safety profile is covered. The description does add real value beyond that by disclosing that the call only opens a waiting period rather than performing the takeover, but it omits waiting-period length, what state changes, and whether the action can be undone or withdrawn.

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 the actor and outcome front-loaded; nothing is wasted. The terseness is a completeness problem rather than a verbosity one.

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 tool in a dense cluster of ~15 emergency-access siblings with zero parameter documentation and no output schema, one fragment is not enough. An agent cannot determine prerequisites, expected identifiers, or what to call next (view vs. takeover) from this 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 even emer_id is declared as an untyped empty object, so the description carries the full burden — yet it never mentions emer_id or what identifier it expects. The opaque wrapper parameters (form, params, json_body) are similarly unexplained, so an agent gets no help on how to construct the call.

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 actor (the grantee) and a specific action (starting the takeover/view waiting period), which distinguishes the initiation step from the later takeover itself. It does not explicitly name or rule out the many sibling emergency-access tools (takeover, view, approve, confirm), so sibling differentiation is left implicit.

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 call this versus vaultwarden_takeover_emergency_access, vaultwarden_view_emergency_access, vaultwarden_approve_emergency_access, or vaultwarden_confirm_emergency_access. Prerequisites such as being the designated grantee, an existing emergency-access record, and any required authentication are unstated.

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