Connect Claude to 1Password

List the vaults this Connect token can reach, with each one's id, name, description, type and item count. Call it first - every item operation needs a vault id, and the list is also the honest statement of this connection's reach: a vault that was not ticked when the token was issued does not appear here and cannot be reached by any other action. `filter` takes a SCIM-style expression on the name only, e.g. name eq "Staging".

Fetch one vault by id, with its name, description, type and item count. Use it to confirm which vault an id refers to before listing what is in it. Vault types are PERSONAL, USER_CREATED, EVERYONE and TRANSFER.

List the items in one vault, with each one's id, title, category, tags, linked URLs and timestamps. This endpoint returns item overviews and never carries field values, so it is the safe way to see what a vault holds: which credentials exist, what they are called, what they are for, and when they were last changed. Categories include LOGIN, PASSWORD, API_CREDENTIAL, SERVER, DATABASE, SSH_KEY, SECURE_NOTE and DOCUMENT. Use search_items to narrow by title or tag rather than paging through a large vault.

Find items in one vault by title or tag, without paging through everything. `filter` is a SCIM-style expression Connect accepts on those two properties only: title eq "Production database", or tag eq "billing". Like list_items it returns overviews and no field values. This is the operation to reach for when the question is "where is the credential for X" - it answers where, and nothing here answers what.

Read one item's metadata - its title, category, tags, linked URLs, version, and who last edited it and when. It is named metadata rather than get_item because that is exactly what it returns: 1Password's own endpoint answers with the whole item, and this operation strips `fields`, `sections` and `files` out of the response inside the gateway, before an agent sees it and before anything is written to the audit log. There is therefore no password, no token, no private key and no note body in the result, and no argument to this operation can put one there. If a value genuinely has to be used, a person retrieves it from 1Password; this connector's job is to say where it lives, not to hand it over. The response is withheld from the audit log as well, so not even the metadata accumulates a second copy.

List the files attached to one item, with each file's id, name and size in bytes. Names and sizes only: the `content` key is stripped from the response and this connector does not expose the `inline_content` parameter that would make Connect fill it in, so an attached certificate, key file or recovery-code document is visible as an entry and never as bytes. Useful for answering "is the private key stored alongside this server record" without retrieving it.

Read the Connect server's own request log - which token made which request, against which vault or item, when, from which address, and whether it was allowed. This is how to answer "what has actually been read through this Connect server", including by this connection itself. Page with `limit` and `offset`. Withheld from the audit log because each entry names an actor and the address they called from.

Report the Connect server's own state - its name, version, and the status of each service it depends on, such as the sync process and its local database. Use it when a call fails to tell "the Connect server is unwell" apart from "the token cannot reach that vault". It is served at the server root rather than under /v1, and it says nothing about any vault or item.