Skip to main content
Glama
Sign In
keepassxc-mcp

keepassxc-mcp

by preginald
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

create_group

Creates a new group at a specified path in an unlocked KeePassXC database, organizing logins and TOTP entries into folders via MCP.

Instructions

Create a group (path, e.g. 'Root/MCP' or 'Work/API keys').

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "group_name": "<group_name>"
    },
    "name": "create_group"
  }
}

Input Schema

NameRequiredDescriptionDefault
group_nameYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations at all, the description carries the full behavioral burden, yet it says nothing about permissions, what happens on a duplicate or conflicting path, whether parent groups are auto-created, or whether the operation is reversible. The only behavioral value it adds is the path/nesting format hint.

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?

One short front-loaded sentence with the essential example inline and no filler. It is arguably under-specified rather than padded, which is the lesser sin but still leaves the entry thin.

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

Completeness3/5

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

The presence of an output schema relieves the description of explaining return values, which keeps this from scoring lower. However, for a creation tool with zero annotation coverage, missing preconditions and failure modes leave it only marginally adequate.

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

Parameters3/5

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

Schema coverage is 0%, so the description must compensate for a single undocumented parameter. The example values ('Root/MCP', 'Work/API keys') do teach that group_name encodes a hierarchy with slash separators, which the schema does not, but validation rules, allowed characters, and max depth remain unspecified.

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?

Specific verb+resource (create a group) with a concrete path-format example ('Root/MCP'), which tells an agent more than the bare name. It does not distinguish itself from the sibling read tool get_database_groups or explain how the created group relates to logins, so sibling differentiation is only implicit.

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?

There is no statement of when to use this versus alternatives, and no prerequisites. The presence of lock_database/unlock_database among siblings makes the missing 'database must be unlocked' precondition a real gap, not a nitpick.

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