Skip to main content
Glama
Knuckles-Team

vaultwarden-mcp

Post access file legacy

vaultwarden_post_access_file_legacy

Retrieve the download URL for a specified file by providing both the file ID and the associated send ID.

Instructions

Anonymous: legacy get-download-URL path

Input Schema

NameRequiredDescriptionDefault
formNo
paramsNo
file_idYes
send_idYes
json_bodyNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.2.2

TDQS

C2.2/5.0
Behavior3/5

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

Annotations already disclose readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so the safety profile is partly covered. The description adds useful context that the path is anonymous and legacy, but it does not explain what the POST actually does beyond returning a URL, nor does it describe side effects or response behavior.

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

Conciseness2/5

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

The description is extremely short, but it is not concise in a helpful way; it is an under-specified sentence fragment. It is front-loaded with 'Anonymous', but the rest of the text does not earn its place by explaining the operation, parameters, or alternatives.

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

Completeness1/5

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

For a tool with five parameters, zero schema description coverage, no output schema, and only sparse annotations, this description is far from complete. It leaves the agent without the information needed to understand what is being accessed, how to form the request, or what will be returned.

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?

The schema has five parameters with 0% description coverage, including required send_id and file_id plus opaque form, params, and json_body fields. The description mentions none of these parameters and provides no meaning, format, or constraints to compensate for the empty schema documentation.

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

Purpose3/5

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

The fragment 'legacy get-download-URL path' hints that the tool retrieves a download URL through an older endpoint, and 'Anonymous' adds a scope qualifier. However, it never states that it operates on a Send file, never mentions send_id or file_id, and does not distinguish it from siblings such as vaultwarden_post_access_file or vaultwarden_post_access_legacy.

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 word 'Anonymous' weakly implies this is for unauthenticated access, but the description gives no explicit when-to-use guidance. It does not say when to choose this legacy path instead of the non-legacy post_access_file or post_access_legacy alternatives.

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