Anakin

Official

Overview Schema Source Related Servers Discussions Admin

wire_login

Destructive

Sign in to a credentials-based site to obtain a credential_id for immediate use with read/write actions. Provide catalog slug and login fields such as email and password.

Instructions

Sign in to a credentials-mode site and get a credential_id usable immediately with wire_read_action / wire_write_action. Provide the catalog slug and login params (the fields that catalog's login schema defines, e.g. email/password — see wire_catalog's login_input_schema). The password is never stored, only the encrypted session. Only needed for actions whose auth_mode is "required", and only for catalogs that support password sign-in; cookie-based sites use the dashboard connect flow instead.

Input Schema

TableJSON Schema

Name	Required	Description
`params`	No	Login fields defined by the catalog (e.g. { email, password }). Use wire_catalog's login_input_schema to learn the field names.
`source_id`	No	Optional 1Password identity-source ID (alternative to params).
`source_ref`	No	Optional 1Password item locator { vault_id, item_id, fields } (use with source_id instead of params).
`catalog_slug`	Yes	The catalog to sign in to (e.g. "neb").
`identity_name`	No	Optional name for the identity. Derived from params in password mode; required when using a 1Password locator.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.4.1Sep 22, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations declare destructiveHint and openWorldHint, but the description adds valuable context beyond them: the password is never stored, only the encrypted session is kept, and the resulting credential_id is immediately usable. It doesn't exhaustively describe session lifecycle side effects, but it complements the annotation coverage well.

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?

The description is compact and front-loaded with the core purpose and outcome. Each sentence earns its place: purpose, required inputs, security behavior, and explicit usage boundaries. No filler or repetition of schema details.

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

Completeness4/5

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

Given the 5-parameter schema, output schema, and annotations, the description covers the key operational context: when to use the tool, what to provide, how password data is handled, and which alternative flows exist. The few remaining details such as source_id/source_ref semantics are already documented in the input schema.

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

Parameters4/5

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

Schema coverage is 100%, so a baseline of 3 applies. The description adds meaning by explaining that `params` must follow the catalog's login_input_schema and giving a concrete example (email/password). This helps the agent understand that `params` is not arbitrary but schema-driven.

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?

The description states a specific verb and resource: 'Sign in to a credentials-mode site' and names the direct outcome, 'get a credential_id usable immediately with wire_read_action / wire_write_action.' This clearly differentiates it from sibling tools like wire_catalog and the read/write action tools.

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

Usage Guidelines5/5

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

It explicitly says when this tool is needed ('Only needed for actions whose auth_mode is "required"'), and when it is not needed ('cookie-based sites use the dashboard connect flow instead'). It also directs the agent to wire_catalog's login_input_schema for the exact param shape, providing concrete routing guidance.

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