keymaster-mcp

Overview Schema Source Related Servers Discussions Admin

update_credential

Update stored credentials' details, secrets, or policies; changes are versioned for rollback, and policy loosening needs user approval.

Instructions

Modify a credential. Only the arguments you pass change. To change the main secret use secret_source (prompt / clipboard / file / generate / value) — the previous value is kept in version history for rollback. Loosening the policy requires the user's approval. Use add_urls/add_aliases whenever you learn a new way the user refers to this credential.

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": {
      "ref": "<ref>"
    },
    "name": "update_credential"
  }
}

Input Schema

Name	Required	Default
`ref`	Yes
`name`	No
`notes`	No
`fields`	No
`policy`	No
`reason`	No
`secret`	No
`add_tags`	No
`add_urls`	No
`username`	No
`expires_at`	No
`add_aliases`	No
`remove_tags`	No
`remove_urls`	No
`rotate_days`	No
`secret_file`	No
`set_secrets`	No
`secret_field`	No
`generate_kind`	No	password
`remove_fields`	No
`secret_source`	No	none
`remove_aliases`	No
`remove_secrets`	No
`generate_length`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.1.0Oct 7, 2026

TDQS

A3.5/5.0

Behavior4/5

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

Annotations only declare readOnlyHint=false, destructiveHint=false, openWorldHint=false. The description adds value beyond these: the previous secret value is preserved in version history for rollback, and loosening policy requires the user's approval (an auth/consent gate). These are meaningful traits the annotations do not convey.

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?

Four short, front-loaded sentences with no filler; the partial-update rule and secret_source guidance come first. The final add_urls/add_aliases sentence is slightly advisory in tone but still earns its place.

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?

For a 24-parameter mutation tool with no output schema and minimal annotations, the description is far too thin: it covers secret handling and URL/alias hints but omits the bulk of the parameter surface and rollback/authorization behavior for most fields. An agent cannot infer correct values for most arguments.

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

Parameters2/5

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

Schema description coverage is 0% across 24 parameters, so the description carries the full burden. It only explains secret_source (five modes) and hints at add_urls/add_aliases, leaving ~22 parameters (policy enum values, set_secrets, rotate_days, generate_length, expires_at, etc.) undocumented in both schema and description.

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 clear verb+resource ('Modify a credential') and the critical partial-update semantics ('Only the arguments you pass change'), which distinguishes it from add_credential and delete_credential. It does not explicitly differentiate from siblings like rollback_credential or credential_history, which also mutate/examine a credential.

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 actionable when-to-use guidance: use secret_source to change the main secret, use add_urls/add_aliases when learning new references, and note that loosening policy requires user approval. No explicit when-not or named alternative tool, so it stops short of a 5.

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