manage_vault_credentials

status: preview Create or update login credentials in a per-end-user vault. Credentials follow one of two paths, and the user chooses which:

KERNEL-hosted collection (provider: "kernel"): the user enters values in a KERNEL-hosted form, and the agent fills them into the browser with value-free bindings. See Credentials.
1Password brokered approval (provider: "1password"): the user connects their 1Password account once and approves each login request in the 1Password app. See 1Password.

Before creating a credential, list the vault with manage_vault_items and reuse an existing one for the site. If none fits, ask the user where their login lives and set provider to match; the tool rejects a create without provider.

Actions

Action	Description
`create`	Create a credential, or return the identical existing credential with the same key.
`update`	Update the description or values of a KERNEL-hosted credential. 1Password credentials can’t be updated.
`connect_account`	Connect a 1Password account to the vault. Returns an authorization URL for the account owner.

Parameters

Parameter	Description
`action`	Operation to perform: `create`, `update`, or `connect_account`. Required.
`vault`	Vault ID or name. Required.
`key`	Immutable item key within the vault, not the item ID. Required.
`provider`	(create, connect_account) `kernel` or `1password`. `connect_account` only supports `1password`.
`spec`	(create, update) Credential specification. Shape depends on the provider and action; see below.
`version`	(update) Current item version. Required for update.
`expected_item_id`	(update) Optional item ID from an earlier read. The update fails if the key now refers to a different item.
`project`	Optional project name or ID.

KERNEL-hosted create spec

Field	Description
`description`	Recognizable site or service name only, such as `GitHub`. Display text, not a destination policy.
`fields`	1–32 field definitions, in the website’s top-to-bottom order. The collection form renders them in this order.

Each field definition takes:

Field	Description
`name`	Stable field name used for updates and fills. Starts with a letter; letters, numbers, and underscores; up to 64 characters. Must be unique.
`label`	Optional non-secret display text shown on the collection form.
`type`	`text`, `email`, `password`, or `totp`.
`required`	Whether the user must supply a value.
`sensitive`	Defaults to `true`. Set `false` explicitly for ordinary usernames and emails so they’re readable. `password` and `totp` must stay sensitive.
`value`	Optional initial value. Omit secrets so the user enters them privately. A `totp` value is a seed, not a current code.

Definitions are immutable after create.

KERNEL-hosted update spec

Field	Description
`description`	Replacement display name. An empty string clears it.
`fields`	Values keyed by field name, such as `{ "username": { "value": "new-name" } }`. Omitted fields are preserved; `null` or `""` clears a supported value.

Never ask for passwords or TOTP seeds in chat. To let the user edit values, reopen the collection form with manage_vault_items (action: "invoke", operation: "collect").

1Password create spec

Field	Description
`account`	Key of a connected `credential_account` item in the same vault. Each end user’s vault connects its own account.
`logins`	1–5 logins the owner approves together, each with an `https://` `website` and optional `reason` (up to 100 characters) and `keywords` (up to 5).
`goal`	Optional short goal (up to 140 characters) shown to the account owner.

1Password supports logins in the owner’s own non-shared vault, not shared-vault items or passkeys. Use KERNEL-hosted collection for those, or if the user declines 1Password. Create the credential without values:

{
  "action": "create",
  "provider": "kernel",
  "vault": "user-123",
  "key": "github-login",
  "spec": {
    "description": "GitHub",
    "fields": [
      { "name": "username", "type": "text", "required": true, "sensitive": false },
      { "name": "password", "type": "password", "required": true, "sensitive": true }
    ]
  }
}

The response includes a bearer collection URL in item.action.url. Give it only to the intended user, outside the agent-controlled browser. Then wait for readiness with manage_vault_items (action: "get", wait: 60) before invoking fill.

Use 1Password

Connect the account once per vault:

{
  "action": "connect_account",
  "provider": "1password",
  "vault": "user-123",
  "key": "onepassword"
}

Give the returned authorization URL only to the account owner. Once manage_vault_items get reports the account connected, create the credential:

{
  "action": "create",
  "provider": "1password",
  "vault": "user-123",
  "key": "github-login",
  "spec": {
    "account": "onepassword",
    "logins": [{ "website": "https://github.com/login" }]
  }
}

Next, invoke 1pw_create_access_request through manage_vault_items; it doesn’t need a browser. The owner approves the request in the 1Password app. Once the credential is ready, create a browser with the vault attached and invoke 1pw_fill. See manage_vault_items.

1Password credentials backed by a customer-supplied access token and integration key are created and rotated through the KERNEL API, not MCP. The MCP server never accepts those secrets.

Writes aren’t automatically retried. Reconcile conflicts or uncertain outcomes before writing again.

Getting Started

Connect Your Client

Tools

Resources & Prompts

Reference

manage_vault_credentials

Actions

Parameters

KERNEL-hosted create spec

KERNEL-hosted update spec

1Password create spec

Use 1Password

​Actions

​Parameters

​KERNEL-hosted create spec

​KERNEL-hosted update spec

​1Password create spec

​Collect a login

​Use 1Password

Actions

Parameters

KERNEL-hosted create spec

KERNEL-hosted update spec

1Password create spec

Collect a login

Use 1Password