Save a label → address binding to the address book. Production mode + Ledger paired: blob is signed with the user's paired Ledger key on that chain (BIP-137 for BTC, EIP-191 for EVM in v1.0; Solana / TRON support deferred to v1.5). Persisted to ~/.vaultpilot-mcp/contacts.json and verified on ever...
AI agents use add_contact to create or update resources in VaultPilot MCP — usually the action step of a workflow, after the agent has gathered context. Every call changes real data in your VaultPilot MCP environment.
| Parameter | Type | Required | Description |
|---|---|---|---|
tags | array | — | Free-form tags ('family', 'cex-deposit', etc.). Like notes — stored in the unsigned metadata sidecar. |
chain | string | Yes | Which chain's blob to add to. v1.0 ships `btc` + `evm` only. `solana` / `tron` return CONTACTS_CHAIN_NOT_YET_SUPPORTED. |
label | string | Yes | Human-readable label, used to look up the contact by name in every prepare flow. Must be unique within a chain — adding the same label twice on the same chain r |
notes | string | — | Free-form note attached to the LABEL (joins across chains via the metadata sidecar — same notes show up on `Mom`'s BTC and EVM rows). Unsigned: tampering with n |
address | string | Yes | On-chain address. Validated against the chain's address regex at call time; format mismatches reject before any device interaction. |
intendedChains | array | — | EVM-only (issue #482). Tag the contact for specific EVM chains so `preview_send` emits a `CONTACT-CHAIN MISMATCH` warning when a prepare's chain isn't in this l |
Parameters from the server's own tool schema.
An AI agent can call add_contact faster than any human can review — one bad instruction and it creates or modifies resources in VaultPilot MCP by the hundred, each call as confident as the last.
Risk signalsBulk/mass operation — affects multiple targets
Attacks that exploit this kind of access
Save a label → address binding to the address book. Production mode + Ledger paired: blob is signed with the user's paired Ledger key on that chain (BIP-137 for BTC, EIP-191 for EVM in v1.0; Solana / TRON support deferred to v1.5). Persisted to ~/.vaultpilot-mcp/contacts.json and verified on every read. Production mode + no Ledger paired (issue #428): writes to a process-local in-memory store and returns unsigned: true + anchorAddress: "UNSIGNED_NO_LEDGER" so first-run / accountant-share users can label addresses without entering demo mode (which intercepts broadcasts). The label is process-local — lost on restart — and resolves with a (unsigned) warning in send-flow verification blocks. Pair a Ledger and re-add to upgrade to a signed entry. Demo mode (VAULTPILOT_DEMO=true): same in-memory store, returns unsigned: true + anchorAddress: "DEMO_ANCHOR". All four chains usable from day one (btc/evm/solana/tron). v1.0 production chains: btc + evm. solana / tron return CONTACTS_CHAIN_NOT_YET_SUPPORTED. The notes and tags fields update the unsigned metadata sidecar (joined across chains by label) so editing them doesn't require a fresh device signature. Sends like prepare_native_send({ to: "Mom" }) resolve Mom against the signed blob first, then fall through to the unsigned overlay with a warning. Adding the same label twice on the same chain replaces the address (with a fresh signature in production-signed mode). Adding a different label that maps to an already-saved address rejects with CONTACTS_DUPLICATE_ADDRESS. It is categorised as a Write tool in the VaultPilot MCP MCP Server, which means it can create or modify data. Consider rate limits to prevent runaway writes.
add_contact accepts 6 parameters: tags, chain, label, notes, address, intendedChains. Required: chain, label, address. The full parameter table on this page comes from the server's own tool schema.
Register the VaultPilot MCP server in PolicyLayer and add a rule for add_contact: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches VaultPilot MCP. Nothing to install.
add_contact is a Write tool with medium risk. Write tools should be rate-limited to prevent accidental bulk modifications.
Yes. Add a rate_limit block to the add_contact rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.
Set action: deny in the PolicyLayer policy for add_contact. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.
add_contact is provided by the VaultPilot MCP server (vaultpilot-mcp). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.