Skip to main content
Glama
keepassxc-mcp

keepassxc-mcp

by preginald

get_logins

Look up saved credentials by matching URL in KeePassXC, returning username, password, name, UUID, and TOTP when available.

Instructions

Look up saved credentials whose URL field matches.

KeePassXC's browser protocol matches on URL, not title. Pass a full URL such as https://github.com or https://console.aws.amazon.com. Returns username, password, name, uuid, and TOTP when present.

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": {
      "url": "<url>"
    },
    "name": "get_logins"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlYes
submit_urlNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.9/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It does disclose that this is a credential-retrieval read and that results include username, password, name, uuid, and TOTP. But it omits operationally important context: the vault likely must be unlocked first (siblings unlock and lock_database exist), and it says nothing about behavior when zero or multiple credentials match.

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

Conciseness5/5

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

Three short sentences, front-loaded with the core action, then the matching rule, then the return shape. Nothing is padded and the constraint most likely to cause a bad call (URL vs title) comes before the examples.

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?

An output schema exists, so the enumerated return fields are a bonus rather than a necessity, and the core lookup is adequately described. Gaps remain for an unannotated tool with an undocumented second parameter: no statement on unlock prerequisites, empty-result behavior, or what submit_url does.

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 description coverage is 0%, so the description must compensate. It fully explains `url` (full URL, URL-field matching, examples), which is the required parameter, but `submit_url` is never mentioned and remains opaque in both schema and description.

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?

States a specific verb and resource ("Look up saved credentials") and adds the decisive scoping detail that matching happens on the URL field, not the title. That distinguishes it cleanly from set_login, get_totp, and the other siblings without needing the schema.

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

Usage Guidelines4/5

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

Gives concrete invocation guidance: pass a full URL such as https://github.com or https://console.aws.amazon.com, and warns that title-based lookup will not work because KeePassXC matches on URL. It does not, however, name an alternative tool or state when not to use it (e.g., when only a TOTP code is wanted, use get_totp).

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