@continuumdao/continuum-node-sdk 1.3.0 → 1.3.1

package/dist/mcp/resources/management-signer.md

@@ -0,0 +1,110 @@
+# Management Signer
+
+This server signs management actions with Ed25519 keys. Management signer tools configure authorized keys on the node and ensure matching local private key material is available for agent-signed requests.
+
+## Goal
+
+Maintain usable local signer keys and keep authorized public keys in sync with the node.
+
+## MCP tools
+
+- `get_management_signers`
+  - List allowed management signers configured on the node (`managementKeys` entries with labels and validity).
+- `has_management_signer`
+  - Check whether the node has an Ed25519 management signer configured (`hasEdDSAKey`).
+- `list_management_signers_detailed`
+  - List allowed signers with preferred signer, per-key nonce, local file name, and local private-key availability.
+- `get_preferred_management_signer`
+  - Read the resolved preferred management signer public key.
+- `get_management_signer`
+  - Read the preferred signer with `nonce` and `nodeKey` (signing context for the active signer).
+- `set_preferred_management_signer`
+  - Set the preferred management signer (signs internally with Ed25519).
+- `add_management_signer`
+  - Add a new Ed25519 management signer on the node; the server generates the key pair and writes files under `mpcConfigPath/added_keys` (Docker: `/app/added_keys/added_key_<N>`). Requires an existing authorized signer with a local private key.
+- `create_management_signer_keypair`
+  - **Deprecated.** Generates a local keypair only (does not register on the node). Prefer `add_management_signer`.
+
+Low-level SDK helpers (`buildManagementPostRequest`, `managementSign`, `buildAddManagementSigner`, and similar build/sign/post steps) are **not** registered as MCP tools. Clients must use the tools above or route tools that sign internally.
+
+## Key lifecycle
+
+1. Check whether any Ed25519 management signer is configured
+   - `has_management_signer`
+2. Inspect current signer state
+   - `get_management_signers` for node authorization list
+   - `list_management_signers_detailed` before signed workflows (preferred signer, nonce, local key status)
+3. Add a new authorized signer (normal path)
+   - `add_management_signer` — node generates the key pair server-side
+4. Set default signer for signed tools
+   - `set_preferred_management_signer` with a 64-character hex Ed25519 public key
+5. (Optional) read signing context
+   - `get_management_signer` for `publicKey`, `nonce`, and `nodeKey`
+
+## `list_management_signers_detailed` output use
+
+Response fields:
+
+- `preferredSigner` (top-level, when resolvable)
+- Per key in `keys`:
+  - `localFileName`
+  - `kind` (`EdDSA`)
+  - `value` (public key)
+  - `nonce`
+  - `label`
+  - `localPrivateKeyAvailable`
+  - `localPrivateKeyError` (when missing or unusable)
+
+Use this as the source of truth before any signed operation.
+
+## Adding a management signer
+
+`add_management_signer`:
+
+- takes no arguments
+- signs `{ nonce, clientSig: "", nodeKey }` with an existing authorized management key (Ed25519)
+- POST `/addManagementKey`
+- returns `publicKey`, `nodeKey`, and optionally `keySlot`, `fileName`, `privateKeyPath`, `publicKeyPath` from the node response
+
+The node writes key files under `mpcConfigPath/added_keys`. Use this for normal operation.
+
+## Deprecated local keypair generation
+
+`create_management_signer_keypair`:
+
+- writes files under `mpcConfigPath/added_keys`
+- labels file as `added_key_{N}` based on current key count
+- returns generated public key and file paths
+- does **not** authorize the new key on the node
+
+Use only when you need a local key file before node authorization is possible (bootstrap / offline generation).
+
+## Preferred signer rules
+
+`set_preferred_management_signer`:
+
+1. Requested public key must already be in allowed management keys.
+2. Matching local private key must exist and be readable (bootstrap key or `added_keys` entry).
+3. Private key must derive to the same Ed25519 public key.
+
+If any check fails, the tool returns a clear error and does not call `/setPreferredSigner`.
+
+Signer resolution for signed route tools (server-side):
+
+1. If a preferred signer is set: it must be allowed and have a usable local keypair.
+2. Otherwise: the server uses the first allowed key with a usable local private key.
+3. If none qualify: the tool fails with an explicit error.
+
+## Operational checks
+
+- If only a bootstrap key exists, ensure its private key is present locally under `mpcConfigPath/bootstrap_key`.
+- If preferred signer is set to a key not available locally, signed tools will fail.
+- If key files are moved or renamed manually, local key matching can fail.
+- If `localPrivateKeyAvailable` is false, signing tools will fail for that key.
+
+## Recommended client behavior
+
+- Refresh `list_management_signers_detailed` before each signed workflow.
+- Show preferred signer and nonce when asking for approval.
+- Prefer explicit error surfacing (missing private key, unauthorized key, nonce mismatch, parse errors).
+- Load `sign.md` for how signed route tools use the preferred signer internally.

package/dist/mcp/resources/mpc.md

@@ -0,0 +1,227 @@
+# MPC Operations
+
+This document covers MPC multi-sign request creation, agreement, Get Sig, Execute, and related workflows exposed through this server.
+
+## Purpose
+
+After KeyGen completes, group members use MPC keys to propose and execute on-chain actions via `multiSignRequest`. This server wraps those flows as MCP tools: building proposals, submitting sign requests, coordinating multi-agree approval, triggering MPC signatures (Get Sig), broadcasting transactions (Execute), and managing MPA wallet setup on Linea.
+
+Most create tools return a new `requestId`. Lifecycle and execution tools operate on that ID through pending → ready → signed → executed states.
+
+Prerequisites: a formed group, completed KeyGen (`fetch_key_gen_result`), configured chain registry entries where needed, and available management signing (`management-signer.md`). The EVM **executor** address for a KeyGen is **`ethereumaddress`** on the KeyGen result (`secp256k1`); resolve preferred id via `get_preferred_key_gen` then `fetch_key_gen_result` — see `keygen.md` (**EVM executor address**).
+
+## MCP tools
+
+### Gas options (create + Get Sig)
+
+- `get_multi_sign_gas_options`
+  - Resolve Custom Gas Config and fee tier choices before creating or triggering Get Sig.
+  - Input: `chainId` (for create planning) and/or `requestId` (for Get Sig planning).
+  - Returns `chainRegistryCustomGas`, `defaultGetSigFeeSpeed`, `proposalUsedCustomGas` / `proposalCustomGas` when the sign request used `useCustomGas`, plus guidance for `useCustomGas` and `feeSpeedTier`.
+
+### MultiSign request creation
+
+All create tools below return `{ requestId }` unless noted.
+
+Shared optional fields on most create inputs: `purpose`, `useCustomGas`, `startingNonce` (all require `keyGenId`).
+
+- **`useCustomGas`** (default `false`): `false` = live RPC gas at proposal time; `true` = apply Custom Gas Config from the chain registry. Call `get_multi_sign_gas_options({ chainId })` and ask the user before creating.
+  - **Omitted `baseFee` / `priorityFee`** in the chain registry Custom Gas Config is valid when `useCustomGas: true` — the builder uses live RPC fees at proposal; configured values are optional floors/multipliers only.
+  - **`proposalTxParams`** on the sign request records gas limit and fee snapshot at create time.
+  - **Get Sig** (`trigger_sign_result`) refreshes fees via `feeSpeedTier` (default from `defaultGetSigFeeSpeed`).
+- **MCP `build_*_multisign` tools** auto-submit and return `{ requestId }`. Treat `requestId` as success — do not call the same build tool again; use `list_sign_requests` to verify duplicates.
+
+- `register_key_gen_on_linea`
+  - Register KeyGen with MultiSignAgentWallet on Linea (59144) via `register(string,string)` (keyGenId + address kind `ethereum`).
+  - Input: `keyGenId`; optional `purpose`, `useCustomGas`, `startingNonce`.
+- `transfer_native_gas`
+  - Native gas transfer (send gas).
+  - Input: `keyGenId`, `chainId`, `toAddress`, `amountWei`; optional shared fields.
+- `transfer_erc20`
+  - ERC-20 transfer.
+  - Input: `keyGenId`, `chainId`, `tokenAddress`, `toAddress`, `amountWei`; optional `transferSig` and shared fields.
+- `transfer_erc721`
+  - ERC-721 `transferFrom`.
+  - Input: `keyGenId`, `chainId`, `tokenAddress`, `toAddress`, `tokenId`; optional `fromAddress`, `transferSig`, and shared fields.
+- `transfer_ctm_erc20`
+  - Same-chain Continuum ERC-20 transfer.
+  - Input: same shape as `transfer_erc20`.
+- `transfer_ctm_erc20_cross_chain`
+  - Cross-chain `c3transfer`.
+  - Input: `keyGenId`, `chainId`, `tokenAddress`, `toStr`, `amountWei`, `toChainIdStr`; optional `transferSig` and shared fields.
+- `create_compose_multi_sign_request`
+  - Build a request from one or more compose actions (custom contract calls).
+  - Input: `keyGenId`, `chainId`, `actions[]` (`signature`, `contractAddress`, `args[]`, optional `valueWei`); optional shared fields.
+- `create_forge_multi_sign_request`
+  - Build a request from Foundry broadcast JSON.
+  - Input: `keyGenId`, `broadcast` (`transactions[]` with `transaction` or `tx` objects); optional `destinationChainID`, `overrideSender`, `startingNonce`, and shared fields.
+- `create_joined_multi_sign_request`
+  - Join two multiSignRequest helper payloads (single or batch each) into one batch on the same chain; reassigns nonces from `firstNonce`. Gas/fees are taken from each input’s serialized txs (not re-estimated). Both inputs must share the same `keyList` / `pubKey`. Chain longer flows by reusing prior join output as `payloadA` or `payloadB`.
+  - Input: `payloadA`, `payloadB` (helper JSON with `bodyForSign` or raw body), `firstNonce`; optional `purpose` override (default merges both purposes with ` | `).
+  - Returns `{ requestId }`.
+
+### MPA wallet (Linea)
+
+- `get_mpa_wallet_status`
+  - Read MPA wallet registration and signing credits for a KeyGen.
+  - Input: `keyGenId`.
+  - Returns registration state, free transactions, deposit info, fee token, nonces, and optional error.
+- `create_mpa_top_up_multi_sign_request`
+  - Create batch `multiSignRequest` (USDC `approve` on Linea fee token when needed + `deposit(string,string,uint256,uint256)` with deposit-only sentinel) to top up MPA KeyGen credits on Linea.
+  - Input: `keyGenId`, `amountWei`; optional shared fields.
+  - Fee token must be on the KeyGen executor. Does not activate the billing month.
+- `create_mpa_sync_billing_multi_sign_request`
+  - Activate KeyGen MPA billing month via `syncBilling(string,string,uint256)` when the credit pool covers the monthly fee.
+  - Input: `keyGenId`; optional `globalNonce`, shared fields.
+  - Uses node-reported global nonce or chain pending nonce when `globalNonce` is omitted.
+- `create_mpa_overage_purchase_multi_sign_request`
+  - Purchase extra signing credits via `purchaseOverageSignatures(string,string,uint256)` after the billing month is active.
+  - Input: `keyGenId`, `signatureCount`; optional shared fields.
+  - Withdraw authority debits the credit pool; non-authority executors include USDC `approve` for the overage fee.
+- `register_vpn_on_linea`
+  - Register VPN billing via `registerVpn(string,bytes32)` on Linea.
+  - Input: `keyGenId`, `hostIpAddress`; optional `nodeKey` (defaults to this node's `/getNodeKey`), shared fields.
+  - `hostBinding` = `keccak256(encodePacked(nodeKey, hostIpAddress))`.
+- `create_mpa_vpn_deposit_multi_sign_request`
+  - Deposit VPN credits via `depositVpn(string,bytes32,uint256,bool)` (approve + deposit when needed).
+  - Input: `keyGenId`, `hostIpAddress`, `amountWei`; optional `activateOnDeposit`, `nodeKey`, shared fields.
+- `create_mpa_sync_vpn_billing_multi_sign_request`
+  - Activate VPN billing month via `syncVpnBilling(string,bytes32)` when the VPN credit pool covers the monthly fee.
+  - Input: `keyGenId`, `hostIpAddress`; optional `nodeKey`, shared fields.
+  - KeyGen executor must be the VPN withdraw authority.
+- `get_mpa_vpn_status`
+  - Read on-chain VPN billing registration and credit pool for a host IP.
+  - Input: `hostIpAddress`; optional `nodeKey`.
+  - Returns registration state, credit pool, monthly fee, and active month info.
+
+### Sign request lifecycle
+
+List/get tools return **compact summaries** by default (small fields: `requestId`, status, purpose, chain, keyGenId, timestamps). Use `get_sign_request_by_id({ requestId, compact: false })` only when you need the full API record.
+
+**Request IDs** always include the `Sign` prefix (e.g. `Sign202605311437369991f054aa2`). Tools accept the 25-character hex suffix alone and add `Sign` automatically. Do not truncate IDs when copying from the UI.
+
+- `list_sign_requests`
+  - List sign requests with optional filter and pagination (Join/History tab).
+  - Input: optional `filter`, `pagenum` (**zero-based** — first page is `0`), `pagesize` (default 20, max 50), `fromTime`, `toTime`.
+  - Returns compact `requests[]` summaries and optional `total`.
+  - **Do not use `filter: "pending"` alone to find Join Accept/Reject work** — the node app merges **`live` + `pending`**. New requests are usually status **`live`**. Use `list_sign_requests_awaiting_join` instead.
+  - Join agreement progress uses **`ClientSigs`** (management Accept/Reject), not **`SigList`** (MPC shares).
+- `list_sign_requests_awaiting_join`
+  - Join tab list: merges `live` + `pending`, keeps rows where this node is in `KeyList`, excludes `success`.
+  - Input: none.
+  - Returns `{ localNodeId, requests[], joinAgreementChecks[] }`.
+  - When the user asks for sign requests waiting to be agreed, call this tool and filter where **`localAgreementPending: true`**, then `sign_request_agree`.
+- `get_sign_request_by_id`
+  - Fetch a sign request by ID.
+  - Input: `requestId`; optional `compact` (default `true`), `txParams: true` to include transaction params from the API.
+  - Returns a compact summary by default, or the full sign request record when `compact: false`.
+- `get_sign_request_status`
+  - Combined lifecycle + broadcast readiness (preferred status check).
+  - Input: `requestId`.
+  - Returns `{ lifecycleStatus, getSigTriggered, hasSignature, executedOnChain, readyToBroadcast, ... }`.
+  - **`lifecycleStatus: "success"` means MPC quorum agreed — not on-chain executed.** Use `executedOnChain` and `readyToBroadcast` before calling `broadcast_sign_result`.
+- `tx_params_from_get_sign_request_id_data`
+  - Parse tx params from GET `/getSignRequestById` data.
+  - Input: `requestId`; optional `txParams`.
+  - Returns `{ txParams }` with `nonce`, `gasLimit`, `txType` (`eip1559` or `legacy`), and fee fields.
+- `sign_request_agree`
+  - Agree to or reject a multi-agree sign request.
+  - Input: `requestId`; optional `accept` (default agree), `thoughts` (max 256 chars).
+  - **Always ask the user “Any thoughts to attach?” before calling** — wait for their reply, then pass it in `thoughts` or omit if they have none. Do not skip this prompt.
+  - Signs internally with Ed25519 management signing.
+  - Returns `{ message }`.
+- `shelve_sign_request`
+  - Shelve a sign request (originator only).
+  - Before Get Sig: sets sign request lifecycle to shelved via `POST /shelveSignRequest`.
+  - After Get Sig (signature ready to broadcast): sets sign result status to shelved via `POST /updateSignResultStatusById`, then best-effort `POST /shelveSignRequest` (same as the node app Shelve button).
+  - Input: `requestId`.
+  - Signs internally with Ed25519 management signing.
+  - Returns `{ message }`.
+
+### Get Sig / Execute
+
+- `list_sign_requests_ready`
+  - List sign requests ready for Get Sig / Execute.
+  - Input: optional `pagenum`, `pagesize`.
+  - Returns compact `{ requests[] }` summaries.
+- `wait_for_sign_request_ready`
+  - Poll until a sign request appears in the ready list.
+  - Input: `requestId`; optional `pollMs`, `timeoutMs`.
+  - Returns `{ ready, detail? }` where `detail` is a compact summary when ready.
+- `trigger_sign_result`
+  - Get Sig: trigger MPC signing with fresh tx params (does **not** broadcast). **Originator node only** — verify via the sign request `Purpose` key / originator fields, not merely `node_id`.
+  - Input: `requestId`; optional `feeSpeedTier` (`slow`, `normal`, `fast`, `advanced`; default = chain `defaultGetSigFeeSpeed` from `get_multi_sign_gas_options`) and advanced fee overrides in gwei when tier is `advanced`.
+  - Call `get_multi_sign_gas_options({ requestId })` first to show the user Custom Gas / default tier choices.
+  - Returns `{ requestId, signResultSummary }` (compact — not the full sign result blob).
+- `get_sign_result_summary`
+  - Fetch a compact sign-result summary for broadcast planning.
+  - Input: `requestId`.
+  - Returns `{ requestId, signResultSummary }` with `executedOnChain`, `readyToBroadcast`, `hasSignature`, optional `transactionHashes`.
+  - **`readyToBroadcast: true` and `executedOnChain: false`** → call `broadcast_sign_result`.
+- `broadcast_sign_result`
+  - Execute: broadcast signed tx(s) and mark sign result executed.
+  - Input: `requestId` only in most cases; optional `signResultId`, `slowBatch`.
+  - After Get Sig succeeds, call **only** `broadcast_sign_result({ requestId })` — do not re-load full sign requests/results unless debugging.
+  - Returns `{ requestId, txHashes, status: "executed" }`.
+- `bump_or_cancel_sign_result`
+  - Bump or cancel stuck pending txs by creating a new `multiSignRequest`.
+  - Input: `sourceRequestId`, `keyGenId`; optional `purposeNote`, `cancelPendingTx`.
+  - Returns `{ requestId }`.
+
+## Typical multi-sign flow
+
+1. Create a proposal — call a create tool (e.g. `transfer_erc20`, `create_compose_multi_sign_request`) with a completed `keyGenId`.
+2. Coordinate agreement — if the KeyGen uses multi-agree policy, peers call `sign_request_agree` until enough members accept (gate threshold applies to signing, not unanimous keygen-style agreement). **Before each agree/reject call, ask “Any thoughts to attach?”** and include the user’s reply in `thoughts` when non-empty.
+3. Track status — `list_sign_requests`, `get_sign_request_by_id`, or `get_sign_request_status`.
+4. After Join quorum (may take days) — before Get Sig, optionally `list_sign_requests_ready` once; **do not** poll `wait_for_sign_request_ready` right after create.
+5. Get Sig — `trigger_sign_result` (optionally tune fee tier). Use the returned `signResultSummary`; avoid pulling full sign-result payloads into chat context.
+6. Execute — `broadcast_sign_result({ requestId })` only. Use `get_sign_result_summary` if you need execution details before broadcasting.
+7. If txs are stuck — `bump_or_cancel_sign_result` to submit a replacement/cancel request.
+
+## MPA on Linea flow
+
+1. Complete KeyGen and fetch the result (`fetch_key_gen_result`).
+2. Register on Linea — `register_key_gen_on_linea`.
+3. Check wallet — `get_mpa_wallet_status`.
+4. Top up credits if needed — `create_mpa_top_up_multi_sign_request`, then run the multi-sign flow above for that new request.
+
+## List filters
+
+`list_sign_requests` accepts optional `filter`:
+
+- `all`, `live`, `pending`, `success`, `blocked`, `shelved`
+
+Use `live` for recently created requests. The create tools return `{ requestId }` directly — do not rely on listing to discover a new request ID.
+
+**Join tab (Accept/Reject):** use `list_sign_requests_awaiting_join`, not `list_sign_requests` with `filter: "pending"`. The node app loads **`live` and `pending` together**; most new proposals have lifecycle status **`live`**. Check `localAgreementPending` on each summary (or `joinAgreementChecks`) — that uses **`ClientSigs`**, not `SigList`.
+
+Optional pagination: `pagenum`, `pagesize`. Optional time range: `fromTime`, `toTime` (Unix timestamps).
+
+## Transfer recipients
+
+For `transfer_erc20`, `transfer_native_gas`, and `transfer_erc721`, prefer registry names over raw IDs/addresses:
+
+- `chainName` (as stored in `get_chain_registry`) instead of guessing `chainId`
+- `toContactName` instead of `toAddress`
+- `tokenSymbol` and `amount` on `transfer_erc20` instead of `tokenAddress` and `amountWei`
+
+Exactly one of each pair is required where pairs are listed. Call `get_chain_registry` with `{}` or `{ chainName }` to resolve the correct chain before transfers.
+
+## Validation and behavior notes
+
+- Create tools validate inputs against strict schemas (EVM addresses as `0x` + 40 hex chars, positive `chainId`, non-empty wei amounts as strings).
+- `sign_request_agree` and `shelve_sign_request` use Ed25519 management signing internally; other create/execute tools build and submit `multiSignRequest` payloads through the MPC API layer.
+- `trigger_sign_result` refreshes fee params and triggers MPC signing but does not broadcast on-chain.
+- `broadcast_sign_result` submits signed transactions and marks the sign result executed.
+- Shelving is restricted to the request originator. After Get Sig, shelving marks the sign result as shelved (will not broadcast) rather than only cancelling the pre-sign request.
+
+## Client guidance
+
+- Always retain `requestId` from create tools for lifecycle, Get Sig, and Execute steps.
+- Resolve `keyGenId` from KeyGen tools before any MPC create call.
+- Prefer compact list/get tools and `get_sign_result_summary` in agent flows; use `get_sign_request_by_id({ compact: false })` only when debugging.
+- Inspect `tx_params_from_get_sign_request_id_data` before Get Sig when showing users nonce/gas details.
+- Do not poll `wait_for_sign_request_ready` immediately after create — Join agreement may take days. Use `list_sign_requests_ready` for a one-shot quorum check before Get Sig.
+- Load `keygen.md` for KeyGen setup and `registry/networks.md` for chain configuration dependencies.
+- Load `management-signer.md` if management-signed agree/shelve operations fail.
+- Before `sign_request_agree`, always ask **“Any thoughts to attach?”** — never call agree/reject without that user prompt (omit `thoughts` only when the user explicitly has none).

package/dist/mcp/resources/overview.md

@@ -0,0 +1,64 @@
+# Continuum MCP Server Overview
+
+This server helps an MCP client operate a Continuum node through safe, structured tools over the management API.
+
+## MCP convention (prompt vs resource)
+
+- MCP servers do not typically force a universal "system prompt" into every client session.
+- The standard pattern is to expose guidance as MCP resources and let the client load them at startup.
+- For this server, `overview.md` is the high-level onboarding resource, while other resource files contain step-specific detail.
+
+## What this server is for
+
+- Discover node state and health (`version`, `get_machine_info`, `get_node_id`, `health`, `connectivity_health`, `logs`).
+- Manage EdDSA management keys and signer selection (`list_management_keys`, `create_eddsa_management_keypair`, `add_eddsa_management_key`, `set_preferred_management_key`, `get_preferred_management_key`).
+- Coordinate group lifecycle (`list_available_node_ids`, `list_valid_group_node_sets`, `create_group_request`, `accept_group_request`).
+- Coordinate MPC key generation (`create_key_gen_request`, `accept_key_gen_request`, `list_key_gen_requests`, `fetch_key_gen_result`, `get_preferred_key_gen`, `post_preferred_key_gen`, and related tools in `keygen.md`).
+- KeyGen channel messaging (`send_key_gen_message`, `list_key_gen_messages`, `get_key_gen_message_by_id`, `get_key_gen_message_thread`, `mark_key_gen_message_read`, `multi_mark_key_gen_messages_read`, `delete_key_gen_message`, `multi_delete_key_gen_messages`) — see `keygen.md`.
+- Manage the address book registry (`get_address_book_registry`, `add_to_address_book_registry`, `remove_from_address_book_registry`).
+- Manage the token registry (`get_token_registry`, `add_to_token_registry`, `remove_from_token_registry`).
+- Manage the chain registry (`get_chain_registry`, `add_to_chain_registry`, `remove_from_chain_registry`).
+- Manage agent MCP servers on the node (`list_mcp_servers`, `add_mcp_server_from_catalog`, `get_mcp_server`, `add_mcp_server`, `remove_mcp_server`) — see `agent-mcp-servers.md`.
+- Compute technical indicators from price/volume arrays (`list_technical_indicators`, `calculate_technical_indicator`) — see `technical-indicators.md`.
+- Provide signed management route tools that handle signing internally (never expose manual signing/plan steps to clients).
+
+## Common node-operator loop
+
+1. Ensure management signing is available.
+   - Use `list_management_keys`.
+   - If needed: generate and add a key via `create_eddsa_management_keypair` + `add_eddsa_management_key`.
+   - Optionally pin default signer via `set_preferred_management_key`.
+   - If EdDSA is not configured yet, configure bootstrap management key material via node setup/browser flow.
+
+2. Form a group with other nodes (unanimous agreement required).
+   - Discover candidates with `list_available_node_ids` or `list_valid_group_node_sets`.
+   - Submit with `create_group_request`.
+   - Other members confirm with `accept_group_request` (originator is auto-agreed).
+
+3. Generate one or more MPC keys in that group (unanimous agreement required).
+   - Start with `create_key_gen_request`.
+   - Other members confirm with `accept_key_gen_request` (originator is auto-agreed).
+   - For the preferred KeyGen’s EVM executor address: `get_preferred_key_gen` then `fetch_key_gen_result` (see `keygen.md`).
+
+4. Use generated MPC key(s) for transaction signing workflows.
+   - Members propose sign requests.
+   - At least `gate` members must agree/sign for MPC SIGNATURE generation (with API threshold = gate - 1). This gate applies to sign requests only; group creation and keygen creation require all requested members to agree.
+
+5. Repeat for additional groups, keys, and signing operations.
+
+## Client orchestration guidance
+
+- Keep user interaction simple: fetch options first, then ask for concrete selection, then execute.
+- Prefer explicit tool inputs for business data (e.g., concrete node IDs), not signer index.
+- For signed tools, rely on preferred signer (or automatic local-key fallback) rather than requesting signer selection each time.
+- Use one route tool per signed action. Do not call `build_signed_request_plan` or `sign_management_message` (not available on this server).
+- Treat tool output as source of truth; avoid guessing route payload shape.
+- Load detailed docs by topic:
+  - keygen (including EVM executor address): `keygen.md`
+  - signing: `sign.md`
+  - groups: `group.md`
+  - management signer: `management-signer.md`
+  - address book: `registry/address-book.md`
+  - tokens: `registry/tokens.md`
+  - chains: `registry/networks.md`
+  - MPC operations: `mpc.md`

package/dist/mcp/resources/registry/address-book.md

@@ -0,0 +1,53 @@
+# Address Book Registry
+
+This document covers the known-address registry (address book) managed through this server.
+
+## Purpose
+
+The address book stores operator-curated recipient and contract addresses with optional labels and chain scope. The node uses these entries in MPC signing workflows.
+
+Read operations are unsigned GETs. Add and remove operations sign and POST internally with Ed25519 management signing.
+
+## MCP tools
+
+- `get_address_book_registry`
+  - Get known addresses from the address book registry.
+  - Optional query: `chain_type`, `chain_id`, `is_contract` (`"0"` or `"1"`).
+  - Returns entries keyed by chain type (each entry includes `address`, optional `name`, `chainIds`, `isContract`, `updatedAt`).
+- `add_to_address_book_registry`
+  - Add an address to the address book registry.
+  - Input: `chainType`, `address`; optional `name`, `chainIds`, `isContract`.
+  - Signs and POSTs to `/addKnownAddress`.
+  - Returns `message`, `selectedSigningKey`, and `signingMessage`.
+- `remove_from_address_book_registry`
+  - Remove an address from the address book registry.
+  - Input: `chainType`, `address`.
+  - Signs and POSTs to `/removeKnownAddress`.
+  - Returns `message`, `selectedSigningKey`, and `signingMessage`.
+
+SDK-only helpers (`buildAddToAddressBookRegistry`, `buildRemoveFromAddressBookRegistry`) are **not** registered as MCP tools.
+
+## Address book flow
+
+1. (Optional) set preferred signer — `set_preferred_management_signer`.
+2. List current entries — `get_address_book_registry` (optionally filter by `chain_type` / `chain_id`).
+3. Add or remove — `add_to_address_book_registry` or `remove_from_address_book_registry`.
+4. Verify — `get_address_book_registry` with the same filters.
+
+## Validation rules enforced
+
+- Query fields must match schema (`is_contract` only `"0"` or `"1"` when provided).
+- `chainType` and `address` are required for add/remove.
+- `chainType` is normalized to lowercase. Addresses are normalized per chain type before POST.
+
+## Signing behavior
+
+`add_to_address_book_registry` and `remove_from_address_book_registry` sign and submit internally. Clients pass business arguments only; do not orchestrate signing manually.
+
+Successful responses may include `selectedSigningKey` (the Ed25519 key used) and `signingMessage` (canonical JSON that was signed).
+
+## Client guidance
+
+- Fetch registry state before add/remove to avoid duplicate entries or stale assumptions.
+- Pass concrete `chainType` and `address` values from user selection or prior GET responses.
+- Load `management-signer.md` if signed operations fail due to missing or unavailable local keys.

package/dist/mcp/resources/registry/networks.md

@@ -0,0 +1,59 @@
+# Chain Registry
+
+This document covers the chain (network) configuration registry managed through this server.
+
+## Purpose
+
+The chain registry stores RPC endpoints, block explorers, and gas/fee defaults for EVM-compatible chains. The node uses these entries when resolving chain context for signing and transaction workflows.
+
+Read operations are unsigned GETs. Add and remove operations sign and POST internally with Ed25519 management signing.
+
+## MCP tools
+
+- `get_chain_registry`
+  - Get chain registry entries.
+  - Optional query: `chain_id`, `chainName` (case-insensitive name filter — preferred over guessing IDs).
+  - Call with no args to list all configured chains.
+  - Returns `chains` (array of chain configuration records).
+- `add_to_chain_registry`
+  - Add chain details to the chain registry.
+  - Input: `chainName`, `chainId`, `rpcGateway`; optional `explorer`, `legacy`, `testnet`, gas/fee fields (see below).
+  - Signs and POSTs to `/postChainDetails`.
+  - Returns `message`, `selectedSigningKey`, and `signingMessage`.
+- `remove_from_chain_registry`
+  - Remove chain details from the chain registry.
+  - Input: `chainId`.
+  - Signs and POSTs to `/removeChainDetails`.
+  - Returns `message`, `selectedSigningKey`, and `signingMessage`.
+
+SDK-only helpers (`buildAddToChainRegistry`, `buildRemoveFromChainRegistry`, `resolveChainRegistryEntry`) are **not** registered as MCP tools.
+
+## Chain registry flow
+
+1. (Optional) set preferred signer — `set_preferred_management_signer`.
+2. List configured chains — `get_chain_registry` (optionally filter by `chain_id`).
+3. Add chain — `add_to_chain_registry` with required fields:
+   - `chainName`, `chainId`, `rpcGateway`
+   - optional: `explorer`, `legacy` (default `false`), `testnet` (default `false`)
+   - optional gas/fee tuning: `gasName`, `gasLimit`, `baseFee`, `priorityFee`, `baseFeeMultiplier` (min 100), `gasMultiplier`, `gasPrice`, `defaultGetSigFeeSpeed` (`slow`, `normal`, or `fast`)
+4. Remove chain — `remove_from_chain_registry` with `chainId`.
+5. Verify — `get_chain_registry`.
+
+## Validation rules enforced
+
+- `chainName`, `chainId`, and `rpcGateway` are required on add.
+- `chainId` must be a non-empty string or non-negative integer on add/remove.
+- `baseFeeMultiplier`, when provided, must be ≥ 100.
+
+## Signing behavior
+
+`add_to_chain_registry` and `remove_from_chain_registry` sign and submit internally. Clients pass business arguments only; do not orchestrate signing manually.
+
+Successful responses may include `selectedSigningKey` (the Ed25519 key used) and `signingMessage` (canonical JSON that was signed).
+
+## Client guidance
+
+- Fetch registry state before add/remove to avoid duplicate entries or stale assumptions.
+- Pass concrete `chainId` and RPC values from user selection or prior GET responses.
+- Configure chain registry entries before token or signing workflows that depend on RPC/gas defaults.
+- Load `management-signer.md` if signed operations fail due to missing or unavailable local keys.

package/dist/mcp/resources/registry/tokens.md

@@ -0,0 +1,63 @@
+# Token Registry
+
+This document covers the saved token registry managed through this server.
+
+## Purpose
+
+The token registry stores saved token contract metadata (ERC-20, ERC-721, and Continuum token types) keyed by chain type and chain ID. The node uses these entries in MPC signing workflows.
+
+Read operations are unsigned GETs. Add and remove operations sign and POST internally with Ed25519 management signing.
+
+## MCP tools
+
+- `get_token_registry`
+  - Get token registry entries.
+  - Optional query: `chainType`, `chain_id`, `symbol` (case-insensitive symbol filter).
+  - Returns token lists keyed by chain type (array of token records).
+- `add_to_token_registry`
+  - Add a token to the token registry.
+  - Input: `chainType`, `chainId`, `tokenType`, `contract`; optional `transferSig`, `transferNames`.
+  - Signs and POSTs to `/addToken`.
+  - Returns `message`, `selectedSigningKey`, and `signingMessage`.
+- `remove_from_token_registry`
+  - Remove a token from the token registry.
+  - Input: `chainType`, `chainId`, `tokenType`, `contractAddress`; optional `tokenId`.
+  - Signs and POSTs to `/removeToken`.
+  - Returns `message`, `selectedSigningKey`, and `signingMessage`.
+
+SDK-only helpers (`buildAddToTokenRegistry`, `buildRemoveFromTokenRegistry`) are **not** registered as MCP tools.
+
+## Token registry flow
+
+1. (Optional) set preferred signer — `set_preferred_management_signer`.
+2. List current tokens — `get_token_registry` (optionally filter by `chainType` / `chain_id`).
+3. Add token — `add_to_token_registry` with:
+   - `chainType` — use `ethereum` for EVM tokens (ERC-20, ERC-721, etc.); the MCP tool maps `evm` to `ethereum` before POST
+   - `chainId` — string or non-negative integer
+   - `tokenType` — `ERC20`, `ERC721`, `CTMERC20`, or `CTMRWA1`
+   - `contract` — at minimum `contractAddress`; optional `name`, `symbol`, `symbolURL`, `decimals`, `tokenURI`, `tokenId`, and passthrough fields
+   - optional `transferSig`, `transferNames`
+4. Remove token — `remove_from_token_registry` with matching `chainType`, `chainId`, `tokenType`, and `contractAddress`.
+5. Verify — `get_token_registry`.
+
+## Validation rules enforced
+
+- `tokenType` must be one of: `ERC20`, `ERC721`, `CTMERC20`, `CTMRWA1`.
+- `contract.contractAddress` is required on add.
+- On remove, `tokenId` is **required** when `tokenType` is `ERC721`.
+- The MCP `add_to_token_registry` / `remove_from_token_registry` tools map `chainType` `evm` to `ethereum` before calling the node.
+- Ethereum contract addresses are normalized to lowercase `0x…` form when `chainType` is `ethereum`.
+
+## Signing behavior
+
+`add_to_token_registry` and `remove_from_token_registry` sign and submit internally. Clients pass business arguments only; do not orchestrate signing manually.
+
+Successful responses may include `selectedSigningKey` (the Ed25519 key used) and `signingMessage` (canonical JSON that was signed).
+
+## Client guidance
+
+- Fetch registry state before add/remove to avoid duplicate entries or stale assumptions.
+- Pass concrete `chainType`, `chainId`, and contract values from user selection or prior GET responses.
+- For ERC-721 tokens, always include `tokenId` on remove (and in `contract` on add when applicable).
+- Configure chain registry entries (`registry/networks.md`) before workflows that depend on chain configuration.
+- Load `management-signer.md` if signed operations fail due to missing or unavailable local keys.