@zktx.io/sui-mcp 0.6.2 → 0.8.0

package/docs/AGENT_BEHAVIOR.md

@@ -11,23 +11,23 @@ It is not the contributor rulebook and it is not enforcement. Development rules
 | Surface | Status | Behavior |
 | --- | --- | --- |
 | Sui mainnet state reads | Current | Use read tools for supported balances, DeepBook pools, token registry metadata, mid-price snapshots, orderbook context, raw-quantity quotes, and DeepBook account inventory. |
-| DeepBook USDC candle-history reads | Current DeepBookV3 official Indexer candle evidence | `read.get_deepbook_usdc_price_history` reads DeepBookV3 official Indexer USDC candles for the requested official interval. `read.get_deepbook_usdc_price_at_time` selects the candle for or nearest to one target UTC time and identifies `matchedCandle.close` as the representative price. Treat both as external official Indexer candle evidence, not a live quote, chain recomputation by Sui MCP, USD value, route choice, P&L, tax, transaction-building input, signing readiness, or user-account history. |
-| Account, Receipt and DeepBook USDC cards | Internal read-only MCP Apps | Use `ui.open_account`, `ui.open_receipt`, or `ui.open_chart` for an interactive read card. They display server-read facts and do not sign, submit transactions, rank routes, compute fiat USD value, P&L, tax or cost basis. |
+| DeepBook USDC candle-history reads | Current DeepBookV3 official Indexer candle evidence | `read_get_deepbook_usdc_price_history` reads DeepBookV3 official Indexer USDC candles for the requested official interval. `read_get_deepbook_usdc_price_at_time` selects the candle for or nearest to one target UTC time and identifies `matchedCandle.close` as the representative price. Treat both as external official Indexer candle evidence, not a live quote, chain recomputation by Sui MCP, USD value, route choice, P&L, tax, transaction-building input, signing readiness, or user-account history. |
+| Account, Receipt and DeepBook USDC cards | Internal read-only MCP Apps | Use `ui_open_account`, `ui_open_receipt`, or `ui_open_chart` for an interactive read card. They display server-read facts and do not sign, submit transactions, rank routes, compute fiat USD value, P&L, tax or cost basis. |
 | DeepBook swap review sessions | Internal Review card and backend WalletConnect | Account-bound review independently verifies stored material, digest, ownership, policy, human-readable facts, simulation and PTB evidence. An explicit app-only action and the wallet approval authorize one backend request. Ordinary MCP responses are facts, never signing authority or bytes. |
-| External proposal review sessions | Non-signable review in the current release | `action.prepare_external_proposal_review` can create an internal Review card from a structured external payment or Sui action proposal. Treat the proposal as untrusted display and review context only. It does not build, verify, simulate, sign, or execute transaction material. |
+| External proposal review sessions | Non-signable review in the current release | `action_create_proposal_review` can create an internal Review card from a structured external payment or Sui action proposal. Treat the proposal as untrusted display and review context only. It does not build, verify, simulate, sign, or execute transaction material. |
 | Wallet signing | User-approved WalletConnect request | The backend validates returned bytes and signer against the admitted review and submits once. The card and model never receive bytes or signatures. |
 | PTB visualization | Rendered with emitted wallet review contracts | `reviewState.ptbVisualization` can accompany an emitted wallet review contract as a Mermaid flowchart decoded from the stored transaction bytes with no AI or model input, shown only after those bytes recompute to the bound commitment. Treat it as visualization evidence only, not transaction-building input, wallet authorization, signing data, signing readiness, payment execution readiness, or route recommendation. |
 | Transaction material and execution | Verified supported swaps under user control | Stored mainnet material is used only after review and wallet approval. External proposals stay non-signable. Fiat cash-out, P&L, tax, cost-basis, route ranking and automatic settlement choice remain unsupported. |
 | Private-key custody, autonomous trading, fiat USD peg claims, and quote-only coverage or readiness claims | Unsupported safety and correctness boundary | Do not custody funds, hold private keys, or autonomously trade. Do not treat settlement assets as fiat USD, bank cash-out amounts, or peg guarantees. Do not turn quote-only conversion candidates into payment coverage, funding readiness, payment execution readiness, or signing readiness. |
 | Silent settlement-token selection and route ranking | Out of scope by current design | Do not silently choose USDC, USDT, or another settlement token for the user. Do not rank venues, choose routes, or make best-price recommendations. |
-| Other chains, autonomous trading, alerts, arbitrary Move calls, investment advice | Unsupported | Say the request is unsupported and redirect to available Sui mainnet read or review capabilities. |
+| Other-chain financial actions, autonomous trading, alerts, arbitrary Move calls, investment advice | Unsupported | Ethereum and Solana address management does not add other-chain asset reads, signing or execution. Say financial requests outside Sui are unsupported and redirect to available Sui mainnet read or review capabilities. |
 | Payment execution | Not a current capability | Intent evidence is separate from execution and does not build or execute payments. Do not describe payment execution as available. |
 | Lending, staking, relative balance actions | Unsupported | Do not describe executable actions for these categories as available product functionality. |
 
 ## Meta Principles
 
-- AI self-reports do not appear in user-facing checkout output.
-- User-facing checkout output should contain server-validated structured facts.
+- AI self-reports do not appear in user-facing review output.
+- User-facing review output should contain server-validated structured facts.
 - Ambiguous natural language is narrowed through structured evidence first, then clarification only where a user decision is required.
 - Important UX rules should move into schemas, UI, and tests when the implementation boundary exists.
 
@@ -47,13 +47,13 @@ When a tool response includes `userAnswerUse`, treat it as the response-local an
 When a USD-denominated settlement-asset response includes `toolAvailability`, check `toolAvailability.requiredToolsAvailable`.
 If it is `false`, say the current MCP server build cannot support the answer and do not use amount fields for the user-facing answer.
 
-If the user asks "What is 1 SUI worth?", answer with the current read context available to the tools. Do not ask for a wallet or create a checkout unless the user asks to prepare an action.
+If the user asks "What is 1 SUI worth?", answer with the current read context available to the tools. Do not ask for a wallet or create a Review card unless the user asks to prepare an action.
 
 For SUI price questions:
 
-- Call `read.get_deepbook_mid_price` with `poolKey: "SUI_USDC"` as the Sui MCP product source for supported SUI/DeepBook price context.
+- Call `read_get_deepbook_mid_price` with `poolKey: "SUI_USDC"` as the Sui MCP product source for supported SUI/DeepBook price context.
 - Present the result as "DeepBook SUI/USDC mid price at `fetchedAt`" and do not call it the global market price.
-- If the user asks for another stable pair or another token, use `read.list_deepbook_tokens` and `read.list_deepbook_pools` to find the registered pool, then call `read.get_deepbook_mid_price` for that pool.
+- If the user asks for another stable pair or another token, use `read_list_deepbook_tokens` and `read_list_deepbook_pools` to find the registered pool, then call `read_get_deepbook_mid_price` for that pool.
 - When multiple pools match and the user did not name the quote token, use this split:
   - For explicit pool-price questions, prefer a USDC-quoted pool, then USDT.
   - For USD-denominated payment, balance, shortfall, coverage, settlement, or cash-out wording, use the intent-evidence flow instead.
@@ -64,12 +64,12 @@ For SUI price questions:
 
 For DeepBook USDC candle-history questions:
 
-- Use `read.get_deepbook_usdc_price_at_time` when the user asks for one supported official USDC-quoted DeepBook pool price at one target time, such as "3 hours ago" after resolving the target to a canonical UTC timestamp.
-- Use `read.get_deepbook_usdc_price_history` when the user asks for observed DeepBook USDC historical candles, OHLCV-like bars, or a UTC range for a supported official USDC-quoted DeepBook pool.
-- If the user asks to view a chart, use `ui.open_chart`. For account assets or a transaction result card, use `ui.open_account` or `ui.open_receipt`. Use ordinary read tools for ordinary evidence answers. If the host returns `ui_unavailable`, explain the UI limitation; do not invent an external page URL. A still-valid unsubmitted card remains usable after chat navigation; the backend owns its state. An accepted, expired or invalidated input is not reactivated; request a new card for a different selection. If a submit reply is lost, read that card’s current state rather than asking to submit again. Missing permission or receipt display details are limitations, not evidence that the user supplied no input.
+- Use `read_get_deepbook_usdc_price_at_time` when the user asks for one supported official USDC-quoted DeepBook pool price at one target time, such as "3 hours ago" after resolving the target to a canonical UTC timestamp.
+- Use `read_get_deepbook_usdc_price_history` when the user asks for observed DeepBook USDC historical candles, OHLCV-like bars, or a UTC range for a supported official USDC-quoted DeepBook pool.
+- If the user asks to view a chart, use `ui_open_chart`. For account assets or a transaction result card, use `ui_open_account` or `ui_open_receipt`. Use ordinary read tools for ordinary evidence answers. If the host returns `ui_unavailable`, explain the UI limitation; do not invent an external page URL. A still-valid unsubmitted card remains usable after chat navigation; the backend owns its state. An accepted, expired or invalidated input is not reactivated; request a new card for a different selection. If a submit reply is lost, read that card’s current state rather than asking to submit again. Missing permission or receipt display details are limitations, not evidence that the user supplied no input.
 - Provide exactly one selector: `poolName`, `assetSymbol`, or `coinType`. For the at-time tool, provide `targetTime` as a canonical ISO 8601 UTC timestamp. For the range-history tool, provide `start` and `end` as canonical ISO 8601 UTC timestamps. Use `interval` only with the official values accepted by the tool schema; omitted `interval` uses `15m`.
-- For `read.get_deepbook_usdc_price_at_time`, answer from `target`, `match`, `matchedCandle`, `candleAvailability`, `source.candles`, `quantitySemantics`, and `responseSummary`. Use `match.representativePrice.value`, which is `matchedCandle.close`, as the representative target-time price. Say whether the match is `exact_bucket`, `nearest_before`, or `nearest_after`, and mention `match.distanceMinutes` when it is not zero.
-- For `read.get_deepbook_usdc_price_history`, answer from `bars`, `candleAvailability`, `source.candles`, `quantitySemantics`, and `responseSummary`.
+- For `read_get_deepbook_usdc_price_at_time`, answer from `target`, `match`, `matchedCandle`, `candleAvailability`, `source.candles`, `quantitySemantics`, and `responseSummary`. Use `match.representativePrice.value`, which is `matchedCandle.close`, as the representative target-time price. Say whether the match is `exact_bucket`, `nearest_before`, or `nearest_after`, and mention `match.distanceMinutes` when it is not zero.
+- For `read_get_deepbook_usdc_price_history`, answer from `bars`, `candleAvailability`, `source.candles`, `quantitySemantics`, and `responseSummary`.
 - Describe the result as DeepBookV3 official Indexer USDC candle evidence for the requested official interval.
 - Say that USDC is a token-denominated quote asset here, not fiat USD and not a USDC/USD peg guarantee.
 - If a tool returns `unsupported_pair`, `unsupported_range`, `source_unavailable`, or `no_price_in_search_window`, report that status and reason. Do not synthesize candles, interpolate missing bars, carry forward the previous bar, run an on-demand chain-history scan, or web-search a replacement unless the user explicitly asks for outside Sui MCP context.
@@ -78,7 +78,7 @@ For DeepBook USDC candle-history questions:
 
 For indicative quote questions such as "If I sell 10 SUI, how much dollar value do I get?":
 
-- Use `read.quote_deepbook_display_amount` only after the source asset, source input amount, pool or quote asset, and direction are known.
+- Use `read_quote_deepbook_display_amount` only after the source asset, source input amount, pool or quote asset, and direction are known.
 - A user saying "dollars" does not by itself select USDC, USDT, or another quote token.
 - If the user names a source asset and says dollars without naming a quote token, first distinguish the intent:
   - For USD-denominated payment coverage, balance total, shortfall, settlement, or cash-out wording, use settlement-asset-group intent evidence when account context is available.
@@ -92,7 +92,7 @@ For indicative quote questions such as "If I sell 10 SUI, how much dollar value
 - Treat `quantitySemantics.kind: "deepbook_quote_display_amount"` as exact decimal display quote strings only.
 - Treat `rawQuote.kind: "deepbook_quote_raw_u64"` as raw quote evidence before slippage policy.
 - Do not turn a quote into final min-out, effective price, price impact, route recommendation, funding source, fiat cash-out, P&L, cost basis, transaction-building input, signing data, or signing readiness.
-- Do not compare a DeepBook quote to `read.get_deepbook_mid_price` as user-facing slippage or price impact. Mid price is a pool snapshot, and current quote tools do not return price-impact evidence.
+- Do not compare a DeepBook quote to `read_get_deepbook_mid_price` as user-facing slippage or price impact. Mid price is a pool snapshot, and current quote tools do not return price-impact evidence.
 - Do not use quote proceeds as profit, P&L, tax, performance, or cost basis.
 - If the user asks for profit after a quote, say Sui MCP can report quote proceeds and raw activity evidence, but it does not compute P&L.
 - Do not provide profit formulas or hypothetical profit examples, even when the user supplies an assumed acquisition price.
@@ -101,25 +101,25 @@ For indicative quote questions such as "If I sell 10 SUI, how much dollar value
 
 Answer only from current tool evidence. For natural-language dollar, USD-like, stablecoin, or Korean dollar-word requests, use this flow:
 
-1. Call `read.get_server_status`; require the current evidence policy plus `read.list_settlement_asset_groups` and `read.preview_intent_evidence`.
-2. Call `read.list_settlement_asset_groups`.
-3. Call `read.preview_intent_evidence` for settlement-asset coverage, balance-total, or shortfall questions.
+1. Call `read_get_server_status`; require the current evidence policy plus `read_list_settlement_asset_groups` and `read_preview_intent_evidence`.
+2. Call `read_list_settlement_asset_groups`.
+3. Call `read_preview_intent_evidence` for settlement-asset coverage, balance-total, or shortfall questions.
 4. Confirm `toolAvailability.requiredToolsAvailable` is `true`.
 5. Use `userAnswerUse.answerFields` for the answer. Settlement-asset-only responses use `responseSummary`; selected-target responses also use `selectedTarget`, `candidateConversions`, and `requiredUserChoices` when those fields are listed.
 
 `responseSummary.answerCompleteness.answerCompleteFor` names the answer class. Use only the fields in `responseSummary.answerCompleteness.requiredAnswerFields` and `userAnswerUse.answerFields` for that class.
 
-For selected-target direct quote evidence, require both `responseEvidence.supportedResponseClaims: "direct_pool_quote_evidence"` and `userAnswerUse.canAnswer: "direct_pool_quote_evidence_for_user_selected_target"` in the same `read.preview_intent_evidence` response. If either entry is absent, do not say that direct pool quote evidence is available from that intent-evidence response.
+For selected-target direct quote evidence, require both `responseEvidence.supportedResponseClaims: "direct_pool_quote_evidence"` and `userAnswerUse.canAnswer: "direct_pool_quote_evidence_for_user_selected_target"` in the same `read_preview_intent_evidence` response. If either entry is absent, do not say that direct pool quote evidence is available from that intent-evidence response.
 
 Do not call quote tools for the same payment coverage, balance-total, or shortfall question when `responseSummary.doNotCallQuoteToolsForThisQuestion` is `true`.
 
-When `toolAvailability.requiredToolsAvailable` is `true` and `responseSummary.doNotCallQuoteToolsForThisQuestion` is `true`, answer from `responseSummary` and stop the same question flow. Do not call `read.classify_wallet_assets`, `read.summarize_wallet_assets`, or quote tools to look for other source tokens for that same coverage, balance-total, or shortfall question. Use those tools only when the user asks a separate inventory or conversion question.
+When `toolAvailability.requiredToolsAvailable` is `true` and `responseSummary.doNotCallQuoteToolsForThisQuestion` is `true`, answer from `responseSummary` and stop the same question flow. Do not call `read_classify_wallet_assets`, `read_summarize_wallet_assets`, or quote tools to look for other source tokens for that same coverage, balance-total, or shortfall question. Use those tools only when the user asks a separate inventory or conversion question.
 
 If quote tools were already called, do not use those quote numbers for the payment amount, coverage status, or shortfall. Use only the fields named by `responseSummary.amountsUsedForAnswer`.
 
-If `read.preview_intent_evidence.userAnswerUse` is present, its `answerFields` names the exact response fields to use for the answer.
+If `read_preview_intent_evidence.userAnswerUse` is present, its `answerFields` names the exact response fields to use for the answer.
 
-Use `read.summarize_settlement_asset_group_parity` and its `responseSummary` for stablecoin-like max, min, mean, median, or internal parity questions. A parity reference asset is a measurement basis, not a settlement choice.
+Use `read_summarize_settlement_asset_group_parity` and its `responseSummary` for stablecoin-like max, min, mean, median, or internal parity questions. A parity reference asset is a measurement basis, not a settlement choice.
 
 Selected-target evidence is allowed only when the user selected the target settlement asset in the current request or prior user context.
 
@@ -161,7 +161,7 @@ For token balances and quantities:
 
 If an action plan exposes `assetFlowPreview.amountKind: "display_intent"`, treat the amount as proposal/display context only. Do not convert it into a raw amount, minimum output, simulation fact, or signing input.
 
-For `action.prepare_external_proposal_review`, answer from
+For `action_create_proposal_review`, answer from
 `plans[].reviewModel` when the response `userAnswerUse.answerFields` lists that
 path. Use `proposedAction`, `assetFlow`, `recipients`, `targets`,
 `missingEvidence`, `requiredUserChoices`, `unsupportedClaims`, `freshness`,
@@ -170,7 +170,7 @@ transaction material. Do not treat it as route selection. Do not treat it as
 settlement-token selection. Do not treat it as payment execution readiness. Do
 not treat it as signing data or signing readiness.
 
-After a DeepBook review session is wallet-account bound, `session.get_review_status` can include review-state checks, `reviewState.adapterLifecycle`, `reviewState.humanReadableReview`, and `reviewState.simulation`. The Review card renders those fields as local review evidence.
+After a DeepBook review session is wallet-account bound, `session_get_review_status` can include review-state checks, `reviewState.adapterLifecycle`, `reviewState.humanReadableReview`, and `reviewState.simulation`. The Review card renders those fields as local review evidence.
 
 Use `reviewState.adapterLifecycle.stageCatalogId`, `completedStages`, and `missingStages` only to explain which account-bound DeepBook review evidence stage catalog is being used, which stages have run, and which required review evidence stages are still missing. If `transaction_material_build_or_verify` is completed, say only that the review server built local unsigned transaction material and kept bytes internal. If `digest_commitment` is completed, say only that the review server internally bound a Sui transaction digest to that stored local material. If `object_ownership` is completed, say only that the review server derived object ownership evidence from the stored local material and Sui owner/type reads. If `review_time_simulation` is completed, say only that the review server simulated the stored local unsigned material with checks enabled and exposed a redacted simulation summary. `reviewState.humanReadableReview` is valid only after `human_readable_review` is completed and not missing; `reviewState.simulation` is valid only after `review_time_simulation` is completed and not missing. Do not provide or infer transaction bytes, signing data, signing readiness, or execution readiness from those stages. The review lifecycle is pre-authorization evidence. The backend admits an explicit Review-card selection, requests approval in the wallet, verifies digest and signer, and records independently read mainnet effects separately from request status. Use those checks to explain what the local review layer verified before signing. Do not describe them as wallet readiness, signing readiness, route quality, execution safety, or public transaction bytes. The MCP layer never signs, executes, or returns transaction bytes.
 
@@ -221,11 +221,11 @@ readiness, not route quality, and not execution safety.
 
 Use these response fields:
 
-- wallet balance amounts: `read.summarize_wallet_assets`;
-- coin-balance classes: `read.classify_wallet_assets`;
-- USD-denominated coverage, total, or shortfall: fields listed by `read.preview_intent_evidence.userAnswerUse.answerFields`;
-- stablecoin-like parity: `read.summarize_settlement_asset_group_parity.responseSummary`;
-- DeepBook BalanceManager inventory: `read.summarize_deepbook_account_inventory`.
+- wallet balance amounts: `read_summarize_wallet_assets`;
+- coin-balance classes: `read_classify_wallet_assets`;
+- USD-denominated coverage, total, or shortfall: fields listed by `read_preview_intent_evidence.userAnswerUse.answerFields`;
+- stablecoin-like parity: `read_summarize_settlement_asset_group_parity.responseSummary`;
+- DeepBook BalanceManager inventory: `read_summarize_deepbook_account_inventory`.
 
 For USD-denominated coverage and shortfall, answer from `responseSummary.currentDisplayAmount`, `responseSummary.requiredDisplayAmount`, and `responseSummary.shortfallDisplayAmount` according to `responseSummary.amountsUsedForAnswer`.
 
@@ -242,10 +242,10 @@ Interpret common `quantitySemantics.kind` values this way:
 
 Use quote tools only for explicit source inputs:
 
-- Use `read.quote_deepbook_action` only when a raw integer amount is explicit.
-- Use `read.quote_deepbook_display_amount` when the user provides a decimal source input amount.
+- Use `read_quote_deepbook_action` only when a raw integer amount is explicit.
+- Use `read_quote_deepbook_display_amount` when the user provides a decimal source input amount.
 
-Do not use quote tools as a follow-up to a payment coverage, balance-total, or shortfall answer when `read.preview_intent_evidence.responseSummary.doNotCallQuoteToolsForThisQuestion` is `true`.
+Do not use quote tools as a follow-up to a payment coverage, balance-total, or shortfall answer when `read_preview_intent_evidence.responseSummary.doNotCallQuoteToolsForThisQuestion` is `true`.
 
 Treat DeepBook `rawQuote` fields as exact quote evidence from simulated `u64` return values.
 
@@ -293,45 +293,79 @@ For common USD-denominated evidence questions:
 
 | User asks | Tool input | User response field |
 | --- | --- | --- |
-| "Can I cover a 1000 dollar payment?" | `read.preview_intent_evidence` with `intentKind: "cover_payment_like_amount"`, `denomination: "dollar"`, `requiredDisplayAmount: "1000"` | `responseSummary` |
-| "How much are my USD-denominated assets together?" | `read.preview_intent_evidence` with `intentKind: "summarize_settlement_asset_group_balance"`, `denomination: "dollar"` | `responseSummary` |
+| "Can I cover a 1000 dollar payment?" | `read_preview_intent_evidence` with `intentKind: "cover_payment_like_amount"`, `denomination: "dollar"`, `requiredDisplayAmount: "1000"` | `responseSummary` |
+| "How much are my USD-denominated assets together?" | `read_preview_intent_evidence` with `intentKind: "summarize_settlement_asset_group_balance"`, `denomination: "dollar"` | `responseSummary` |
 | "What is the shortfall?" | Reuse the established target amount, or ask for the missing display target amount | `responseSummary` |
 
 Describe an active wallet account as read context, not login, proof of
 ownership, standing signature approval or custody. Explicit public-address
-reads do not set that context. Account clearing does not disconnect a wallet.
-
-- For current asset reads with no address supplied by the user, read `session.get_interaction_status` and use `assetReadAccount.account` only when its status is `available`. If that default is unavailable and the requested tool accepts `account`, ask for a Sui address in chat. For `read.summarize_deepbook_account_inventory`, a typed address is unsupported: follow its connection/account-selection guidance instead. Do not copy a remembered or stored active address into an explicit argument to bypass this condition. Explicit user-provided addresses remain public reads without a connected wallet. A stored active account is not proof of a current connection.
-- If a different saved connection remains after disconnection, matching addresses do not carry the old default selection into it. The user can choose Use address in Connect. Use the returned `assetReadAccount`, not a count of recorded connections or an address match, to describe the default. A stored connection past its expiry is not a current usable choice or proof of remote removal.
-- Before opening a connection card, use the same status response's `connections`, `connectionConflict` when present, and `walletAvailability`. For a connect request, if the requested wallet is already connected, report that fact without opening another card. For a disconnect request, if no connection is recorded and wallet state is available, report that there is no connection to disconnect. Unavailable wallet state does not prove no connection. Do not ask for another pairing when one is pending.
+reads do not set that context. Account clearing does not disconnect a wallet. Activity tools with an optional
+`account` use saved read context when it exists. If it is absent or cleared, ask
+for an explicit Sui address for that read; do not ask for a wallet connection
+merely to restore a read filter.
+
+- For current asset reads with no address supplied by the user, read `session_get_interaction_status` and use `assetReadAccount.account` only when its status is `available`. If that default is unavailable and the requested tool accepts `account`, ask for a Sui address in chat. For `read_summarize_deepbook_account_inventory`, a typed address is unsupported: follow its current connection or read-address-clearing guidance instead. Do not copy a remembered or stored active address into an explicit argument to bypass this condition. Explicit user-provided addresses remain public reads without a connected wallet. A stored active account is not proof of a current connection.
+- One current connection supplies one fixed address per approved chain. Other wallet/account/address choices require disconnecting and reconnecting. Never propose Add connection or a default-account switch. A stored expired record is not proof of remote removal.
+- Before opening a connection card, read `session_get_interaction_status.connection`, `requestedChains`, `canDisconnect` and `walletAvailability`. An already connected wallet needs no additional pairing. Missing/unavailable observation does not prove absence. Pending work must use its existing card and operation, not another pairing.
 - Collect a missing account address or transaction hash in chat before opening an Account or Receipt card. Use a hash already supplied for the requested transaction; do not ask for it again. If a tool returns `input_required`, ask for its named input without retrying or claiming a failure. These cards have no input forms.
 
-For a connected-account-only read, use `session.get_interaction_status` to distinguish an unavailable wallet service, pending operations, and missing connection/selection. Report wallet-service unavailability and recovery guidance without proposing another pairing. If an operation is pending, use its existing cardId with the connection get/wait tools. Otherwise, explain that the user must request connection or account selection to continue; do not start that operation automatically.
-
-1. `account.get_active_account` reports the stored selection, with `source` and `setAt`. For current assets without a user-provided address, use `session.get_interaction_status.assetReadAccount` to check whether that selection is a usable default. If not, request an address only for tools that accept `account`; connected-account-only tools require the connection/account-selection flow. Do not infer current connection from the stored selection.
-2. An explicit connect/reconnect/disconnect/account replacement request opens an internal
-   Connect card with `session.create_wallet_connection`: use `intent: connect` for requested pairing, `intent: disconnect` for requested disconnection, and `intent: manage` for inspection or account selection. The model must not call app-only actions on the user's behalf.
-For "disconnect my wallet", when the wallet service is available and the target is connected, open `session.create_wallet_connection` with `intent: disconnect`. For one connected target the card shows Confirm disconnect or Back directly; Back only returns to the connection view; it does not submit Cancel review or disconnect. The card starts no pairing. Do not substitute the Settings action to clear the default read address, claim disconnection is unsupported merely because there is no direct model-facing disconnect tool, or equate disconnection with revoking onchain permissions. If disconnection is already pending, read or wait on that exact card instead of opening another operation.
-
-3. `session.get_wallet_connection` and `session.wait_wallet_connection` use the
-   returned cardId. An unsubmitted card needs input; waiting does not create a
-   pairing. Pairing credentials/QR never belong in chat text.
-4. After connection/account selection, read `session.get_interaction_status` and confirm `assetReadAccount` is available before
-   stating which account is active. A connected session and active context are
-   separate facts, especially after clear or a multiple-account approval.
-5. A wait timeout does not prove failure, disconnection or a remote dialog's
-   cancellation. Report the actual stored outcome and pending user action.
-
-Use `session.get_interaction_status` for bounded pending interactions. A Review
+For a connected-account-only read, distinguish unavailable service, pending work,
+missing connection and explicit read-address clearing. Use the existing operation's
+cardId for get/wait while it is pending. Otherwise follow the user's connection
+request; do not initiate pairing automatically. Clearing read context is not a
+wallet disconnection or an invitation to bypass the read guard with a remembered address.
+
+1. `account_get_active_account` reports stored Sui read context, with its source
+   and time. Use `session_get_interaction_status.assetReadAccount` for current
+   asset eligibility. Tools with an `account` input accept a user-provided address;
+   connected-account-only tools do not. Stored context alone proves no connection.
+2. For an explicit connect request, open `session_open_wallet_connection_card`
+   with empty input. For disconnection, open `session_open_wallet_disconnection_card`.
+   The latter fixes the current exact session and shows Confirm disconnect and
+   Cancel. Cancel ends that card without disconnecting. Neither card can switch
+   purposes or act on a replacement session; another operation requires a new
+   user prompt and purpose card. The model must not call app-only actions for the
+   user. Disconnection does not revoke onchain permissions. If the requested wallet
+   is already connected, report current interaction status without another pairing.
+   A no-session-to-disconnect refusal needs no repeated status check or new Review.
+
+For "disconnect my wallet", open `session_open_wallet_disconnection_card` when the
+session is manageable. Confirm disconnect removes that exact session; Cancel ends
+only this card and leaves the session unchanged. The card starts no pairing.
+Do not substitute Clear saved read address or claim revocation of onchain permissions.
+If disconnection is already pending, read or wait on its exact card rather than
+creating another operation. For a connect request, if the requested wallet is already connected,
+report current interaction status without another pairing.
+
+3. `session_get_wallet_connection_card` and `session_wait_wallet_connection_card` use the
+   returned cardId. The response's fixed `card` is separate from its current exact
+   `operation`, service availability and evaluation time. Waiting does not create a
+   pairing or follow a later operation. Without an admitted operation, waiting ends immediately. Pairing
+   credentials and QR data never belong in chat text.
+4. Settings selects networks for the next connection, default Sui. Only returned
+   requested networks are usable. A single distinct address binds automatically;
+   several addresses make that chain unavailable, with no chooser. Reconnect to
+   change the address or scope. Changing Settings does not modify current approval.
+5. A timeout does not prove failure, removal or cancellation of a wallet dialog.
+   Read the saved outcome and pending cleanup separately. An approval or
+   disconnection recorded as completed remains completed while cleanup is pending;
+   do not describe that result as stopped. SDK exit and late
+   response processing must not be called user cancellation.
+6. Explicit Cancel or Stop permanently ends that card's input. Cleanup cannot
+   restore it. Open a new card only for a new user request. Settings Clear saved
+   read address suppresses implicit read context across restart of the same
+   connection; it does not cancel a request, change fixed addresses or disconnect.
+
+Use `session_get_interaction_status` for bounded pending interactions. A Review
 status of `ready_for_wallet_review` is displayed as Ready for your review: the
 review details are available to inspect. It does not mean that approval can be
 requested now or that the wallet has a pending signing request. Request status is
 reported separately. A completed request has independently observed chain
 success/failure. stopped, request_failed and outcome_unknown never imply chain
-failure or absence of execution. Use `session.get_execution_result` to read the
-known digest without resubmitting. `session.open_review_management` requires the
+failure or absence of execution. Use `session_get_execution_result` to read the
+known digest without resubmitting. `session_open_review_management` requires the
 exact reviewSessionId and attemptId and grants no new signing/refresh action.
-With one available wallet/account, the live Review card prepares and renews verified conditions automatically. The user inspects the PTB and amounts, then chooses Request wallet approval. Multiple valid connections must first be resolved through target-specific disconnection; several approved addresses belong to one connection. Failed preparation may need Retry review. Do not ask users to manually update after normal review-detail expiry; the card updates automatically when permitted. Receipt and completed Review show the actual transaction graph when private display metadata is available, followed by observed results. Additional facts are in Details; missing metadata means the graph is unavailable, not that the transaction has no inputs.
+A new Review fixes the current Sui account and connection before preparation. Its live card prepares and renews verified conditions automatically while that exact target qualifies. The user inspects the PTB and amounts, then chooses Request wallet approval. Use the exact fixed target. Reconnecting cannot retarget an existing Review; a replacement connection needs a new Review. Settings selects requested networks, default Sui; only a single valid returned address per chain is usable. Do not repeat already-determined chain/address choices in a card. Failed preparation may need Retry review. Do not ask users to manually update after normal review-detail expiry; the card updates automatically when permitted. Receipt and completed Review show the actual transaction graph when private display metadata is available, followed by observed results. Additional facts are in Details; missing metadata means the graph is unavailable, not that the transaction has no inputs.
 
 Frame recreation and chat navigation first reread the same DB state. Only a currently permitted live View can continue its backend-directed automatic preparation; completed, managed and public saved cards never restart it. SDK restoration does
 not replay a financial request or restore cleared read context.
@@ -339,38 +373,35 @@ not replay a financial request or restore cleared read context.
 Treat `walletAvailability` as the local connection service's state and
 `walletObservation` as its last confirmed observation, not the wallet app's live
 screen. `initializing` and `recovering` do not mean the user rejected anything.
-If `connectionConflict` is present, explain that several saved connections
-prevent using a wallet. On the user's request, open Connect/manage for them to
-confirm the connections they want to disconnect. Do not choose the first or
-most recent connection, change the default address or call `ui.act_card` for
-them. `allowedActions` describes permitted action types, not all buttons visible
-in a particular frame. In particular, a card without a target does not show
-Disconnect or Use account merely because a general action name was mentioned.
+One connection is current. Its fixed addresses, live grant and stored read context
+are separate facts. An old Review stays bound to its original account/connection;
+a replacement connection requires a new Review. `allowedActions` describes
+permitted app action types, never model authority or a mandatory visible button list.
 
 Connection-service recovery belongs to Settings. When the service is unavailable
 or a connection operation remains unresponsive, open
-`settings.create_local_settings_session` on the user's request and direct them
+`settings_create_local_settings_session` on the user's request and direct them
 to Troubleshooting. The user inspects the affected run/requests and explicitly
 confirms Restart connection service; do not call app-only actions for them.
 A new Settings card can explicitly supersede a startup still pending. Read the
 same operation's result; neither a new available run nor restart completion
 confirms an interrupted disconnect or a transaction result. Do not repeatedly
 request wallet approval or report recovery before its new run is observed.
-`manageableConnectionIds` names exact disconnect targets, not usable wallet
-choices. A terminal record may remain manageable when its SDK session is still
-present; do not describe the old failed operation as successful. If
+`canDisconnect` qualifies the current exact cleanup target, not financial usage.
+A terminal or older-data-generation record can remain disconnectable when its SDK
+session is still present or unusable; do not describe the old failed operation as successful. If
 `connectionReconciliationRequired` is true, explain that the service contains an
-unrecorded connection. Ask the user to remove that retained connection in the
-wallet app, then check its status. Settings/Troubleshooting can restart the
+unrecorded connection. New pairing and financial input are blocked. Ask the user
+to remove that retained connection in the wallet app, then check its status. Settings/Troubleshooting can restart the
 service to inspect it again; restarting does not approve an unrecorded session.
 Do not infer a free pairing slot from a failed or expired record.
 
 If the parent or Settings itself cannot be reached, explain the full app exit
-procedure in the setup guide. All participating apps must quit; closing a peer
-or window can leave the owner alive. Full app restart is also required for
-stored endpoint or installation changes. Do not kill another app's processes.
+procedure in the setup guide. All participating MCP connections must stop and the shared parent must exit;
+closing a peer or window can leave the owner alive. Follow the same parent
+stop/reopen procedure for stored endpoint or installation changes. Do not kill another app's processes.
 
-A failed `connectionAction: "disconnect"` means removal was not confirmed.
+A failed operation with `operation.action: "disconnect"` means removal was not confirmed.
 Direct the user to inspect/remove the retained connection in their wallet app.
 App restart does not prove remote revocation or cancel a transaction on Sui.
 Already submitted transactions keep their digest and remain readable; a new
@@ -381,9 +412,9 @@ no new action. Do not describe ordinary waiting as a failure.
 Display shortened lowercase addresses by default and full addresses when exact
 verification is needed. For user-requested local review history, use:
 
-- `read.list_review_activity`;
-- `read.summarize_review_funnel`;
-- `read.get_review_session_detail`.
+- `read_list_review_activity`;
+- `read_summarize_review_funnel`;
+- `read_get_review_session_detail`.
 
 The optional `account` input is a read filter. It does not change active account context.
 
@@ -393,11 +424,11 @@ Sui activity tools answer user-requested transaction questions from GraphQL read
 
 Use the summary path first:
 
-- `read.summarize_sui_activity_scan` for recent activity, latest activity, asset-flow summary, protocol summary, gas summary, or failure summary.
-- `read.scan_sui_account_activity` when the user asks for bounded transaction rows.
-- `read.inspect_sui_transaction` when the user provides one digest or asks for digest-level detail.
-- `read.summarize_sui_account_activity` only for stored local activity facts.
-- `read.get_account_asset_timeline` for stored account asset net-flow bars over a UTC range after relevant activity has been scanned and stored.
+- `read_summarize_sui_activity_scan` for recent activity, latest activity, asset-flow summary, protocol summary, gas summary, or failure summary.
+- `read_scan_sui_account_activity` when the user asks for bounded transaction rows.
+- `read_inspect_sui_transaction` when the user provides one digest or asks for digest-level detail.
+- `read_summarize_sui_account_activity` only for stored local activity facts.
+- `read_get_account_asset_timeline` for stored account asset net-flow bars over a UTC range after relevant activity has been scanned and stored.
 
 Important scan boundaries:
 
@@ -442,7 +473,7 @@ If returned evidence is incomplete or unverified, say so before using it. If a t
 
 ### Function Activity Diagnostics
 
-Use `read.scan_sui_function_activity` for transactions the selected account sent that called one exact Sui Move function. Use `read.summarize_sui_function_activity_scan` for the same sent-function scope when the user wants a summary.
+Use `read_scan_sui_function_activity` for transactions the selected account sent that called one exact Sui Move function. Use `read_summarize_sui_function_activity_scan` for the same sent-function scope when the user wants a summary.
 
 Rules:
 
@@ -454,9 +485,9 @@ Rules:
 
 Function activity facts are not route quality, P&L, wallet position inventory, transaction-building input, signing data, signing readiness, protocol support, or complete history.
 
-When the user asks for balances for a specific Sui address, call `read.summarize_wallet_assets` or `read.classify_wallet_assets` with `account`. Do not start wallet connection for that public-address read.
+When the user asks for balances for a specific Sui address, call `read_summarize_wallet_assets` or `read_classify_wallet_assets` with `account`. Do not start wallet connection for that public-address read.
 
-If the user asks for their balances without giving an address, use `session.get_interaction_status.assetReadAccount` only when it is `available`; otherwise ask for a Sui address. Open a wallet connection card only when the user requests connection.
+If the user asks for their balances without giving an address, use `session_get_interaction_status.assetReadAccount` only when it is `available`; otherwise ask for a Sui address. Open a wallet connection card only when the user requests connection.
 
 Explicit-address wallet asset reads are live read snapshots only. They do not prove ownership, create active account context, store the address as a known wallet, or enable signing.
 
@@ -464,9 +495,9 @@ Do not call stored Sui activity complete wallet history, P&L, balance history, c
 
 For account asset timeline questions:
 
-- Use `read.get_account_asset_timeline` only for stored local account activity evidence.
+- Use `read_get_account_asset_timeline` only for stored local account activity evidence.
 - If the response status is `scan_needed`, explain that no stored account activity scan proves the requested range yet, and use `userAnswerUse.followUp.tool` or `scanNeeded.tool` before claiming a timeline.
-- If the response status is `account_not_known`, say the explicit account is not a known local wallet in the activity store. Do not tell the user to run `read.scan_sui_account_activity` from that response unless `scanNeeded` or `userAnswerUse.followUp` is present.
+- If the response status is `account_not_known`, say the explicit account is not a known local wallet in the activity store. Do not tell the user to run `read_scan_sui_account_activity` from that response unless `scanNeeded` or `userAnswerUse.followUp` is present.
 - Use `netFlowBars` as observed raw integer token inflow/outflow bars only.
 - Do not call `netFlowBars` held balances, current balances, wallet total value, complete wallet history, P&L, tax, or cost basis.
 - `balanceStatus: "unavailable_no_balance_anchor"` means held-balance bars are not available. Say that explicitly if the user asks for balances over time.
@@ -480,31 +511,27 @@ Do not call the page provider-verified coverage when `orderingVerified: false`.
 
 When a review activity response has `lowSampleWarning: true`, do not infer a behavior pattern. Prefer wording like: "There are only N local review records in this scope, so this is not enough to infer a pattern. Here are the raw counts."
 
-For `read.list_review_activity`, `dataScope.recordCount` is the full matching local review count. The returned `activities` array can be shorter when `truncated.activities: true`.
+For `read_list_review_activity`, `dataScope.recordCount` is the full matching local review count. The returned `activities` array can be shorter when `truncated.activities: true`.
 
-For `read.get_review_session_detail`, transition rows with `isNoOp: true` are repeated lifecycle observations where the stored status did not change. Mention them only as audit details; do not count them as extra funnel progress.
+For `read_get_review_session_detail`, transition rows with `isNoOp: true` are repeated lifecycle observations where the stored status did not change. Mention them only as audit details; do not count them as extra funnel progress.
 
-For local settings, local records or connection-service recovery, call `settings.create_local_settings_session` to open the internal Settings card. Its name is unchanged; no external URL is returned. Explain Address for viewing assets, Local records, Troubleshooting or Advanced settings as needed and leave selection/confirmation to the user.
+For local settings, local records or connection-service recovery, call `settings_create_local_settings_session` to open the internal Settings card. No external URL is returned. Explain Address for viewing assets, Wallet networks, Local records, Troubleshooting or Advanced settings as needed and leave selection/confirmation to the user.
 
-For a backup, use the exact label Download backup in Local records. It prepares
-and verifies the snapshot internally and asks the app to save it in one user
-action. Do not instruct a separate Create backup step or confuse Download backup
-with Restore local records. If the actual download function is unsupported,
-the same file is saved once in the Sui MCP backup folder. Use the verified
-Backup saved result's Folder and File name for that local artifact. Do not
-describe that folder as the Host download destination. Suggested file name and Host acknowledgment do not establish where
-or whether a file was saved. Retry download is explicit and may create another
-copy after an unconfirmed earlier request. It uses the same snapshot only during
-its fixed transfer period; a new request after expiry or server restart captures
-current records. Cancel download does not delete a file already saved by the app.
-Use the same function-based product instructions across desktop apps. Missing
-advertisement is not proof of non-support, and timeout, cancellation or denial
-does not trigger local saving. Save a local copy is the explicit decision after
-an earlier possibly handled request. Retry save follows only a confirmed failure
-with no published file; Check status settles uncertain saving or cleanup without
-another file effect. Report saved-file and cleanup facts separately.
+For a backup, use Download backup in Settings → Local records. Do not request a
+separate Create backup step. Report only the returned saved-file and delivery
+facts: Host acknowledgment does not prove a saved file or its destination.
+A completed delivery card cannot retry. For a requested retry of a retained
+backup, open `settings_create_local_settings_session` with `backupDelivery` and
+the exact recorded operation/file identifiers; the user chooses one delivery or
+local-save attempt there. To check current delivery or cleanup, open the same
+tool with `operationStatus`. Do not ask the user to press a control in an ended
+card. Expired or invalidated backups require a new backup request. These three
+card purposes and file outcomes are defined in [Settings Tools](MCP_TOOLS.md#settings-tools).
+Use the same function-based instructions across apps. Neither missing capability
+advertisement nor timeout, denial or uncertain delivery means method-not-found.
+A local copy after a possibly handled delivery requires explicit user consent.
 
-Ordinary MCP tools never apply a Settings change. Do not call `ui.act_card` or `ui.read_settings_file` as model work. Never request/paste raw backup bytes or card permissions in chat. Clear default address only changes read context, not wallet connections or admitted transactions. Endpoint changes require quitting/reopening all apps; a connection-service restart does not apply them. Report operation result, temporary-file cleanup and Host download acknowledgment as separate facts. A saved result is not proof that the Host saved a downloaded file. For restore validation refusal, let the user correct input or choose another file and prepare a new confirmation; reading or returning to a frame never applies it.
+Ordinary MCP tools never apply a Settings change. Do not call `ui_act_card` or `ui_read_settings_file` as model work. Never request/paste raw backup bytes or card permissions in chat. Clear saved read address belongs to Settings. It suppresses implicit Sui read context, not fixed wallet addresses or admitted transactions. Endpoint changes require the shared parent to stop and reopen; a connection-service restart does not apply them. Report operation result, temporary-file cleanup and Host download acknowledgment as separate facts. A saved result is not proof that the Host saved a downloaded file. For restore validation refusal, let the user correct input or choose another file and prepare a new confirmation; reading or returning to a frame never applies it.
 
 ## User Vocabulary
 
@@ -532,22 +559,24 @@ Do not silently turn vague words into amounts.
 | "Do you think I should buy this?" | Do not give investment advice. Offer price, liquidity, quote, and risk-input facts when supported. |
 | "Tell me when the price drops." | Say alerts are unsupported. Offer a one-time price or quote check. |
 | "Let's buy Bitcoin too." | Say this toolkit only exposes Sui mainnet surfaces. |
-| "Am I connected? / Am I logged in?" | Read `session.get_interaction_status.connections` with `walletAvailability`. When unavailable, report that connection state cannot be confirmed. The stored active account is not proof of a connection or login. Do not say the user is connected to DeepBook or signed in. |
-| "Show my balances over time." | Held-balance history and P&L are not tool surfaces. Use `read.get_account_asset_timeline` only for stored raw net-flow bars over a UTC range; if `balanceStatus` is `unavailable_no_balance_anchor`, say held balances are unavailable. `read.summarize_wallet_assets` returns a current snapshot at `fetchedAt`. |
+| "Am I connected? / Am I logged in?" | Read `session_get_interaction_status.connection` with `walletAvailability`. When unavailable, report that connection state cannot be confirmed. The stored active account is not proof of a connection or login. Do not say the user is connected to DeepBook or signed in. |
+| "Show my balances over time." | Held-balance history and P&L are not tool surfaces. Use `read_get_account_asset_timeline` only for stored raw net-flow bars over a UTC range; if `balanceStatus` is `unavailable_no_balance_anchor`, say held balances are unavailable. `read_summarize_wallet_assets` returns a current snapshot at `fetchedAt`. |
 | "How much profit did I make?" | Profit, tax, performance, and cost-basis calculations are not Sui MCP surfaces. Offer raw activity, balance snapshots, or quote evidence instead; do not provide a profit formula or hypothetical profit example. |
 | "Can you calculate my profit if I bought 10 SUI for 10 USDC?" | An assumed acquisition price does not change the boundary. P&L and accounting calculations are unsupported; do not provide a formula, worked example, tax treatment, or performance result. |
-| "Did my swap go through?" | If the swap was signed through a Sui MCP review session, use `session.get_review_status` or `session.wait_execution_result`: a `completed` request with `executionResult.chainReceipt` has a server-verified chain result. Read `executionResult.status` for `success` or `failure`; a failed request without that result is not chain failure. Offer Sui Explorer for the digest. For transactions signed outside a review session, use `read.inspect_sui_transaction` with the user-provided digest instead; do not claim receipt evidence the session does not hold. |
-| "Show my transaction history." | Use `read.scan_sui_account_activity` only as a user-requested bounded scan. Explain the limit, continuation cursor, and `windowComplete` result. Do not call it complete wallet history. |
+| "Did my swap go through?" | If the swap was signed through a Sui MCP review session, use `session_get_review_status` or `session_wait_execution_result`: a `completed` request with `executionResult.chainReceipt` has a server-verified chain result. Read `executionResult.status` for `success` or `failure`; a failed request without that result is not chain failure. Offer Sui Explorer for the digest. For transactions signed outside a review session, use `read_inspect_sui_transaction` with the user-provided digest instead; do not claim receipt evidence the session does not hold. |
+| "Show my transaction history." | Use `read_scan_sui_account_activity` only as a user-requested bounded scan. Explain the limit, continuation cursor, and `windowComplete` result. Do not call it complete wallet history. |
 | "Cancel the transaction I just sent." | Say already-submitted onchain transactions cannot be canceled by this toolkit. |
 | "Can I trust this address?" | Say address reputation lookup is unsupported. Use only verified mainnet protocol surfaces when preparing reviews. |
 
 ## Comparisons
 
-Only compare options when the user asks for a criterion such as cheaper, lower slippage, or less SUI spent.
-
-State the checked scope and timestamp.
-
-Avoid unqualified words such as best, recommended, guaranteed, or safe. Prefer: "Among checked options, at this quote time..."
+Compare only response-local facts whose returned fields support the requested
+comparison, such as the settlement-asset parity summary. Name the source, units,
+checked scope and timestamp. A request for a cheaper venue or lower slippage does
+not create a supported comparison: do not rank venues or routes, infer price impact
+or slippage from quote-versus-mid values, or choose settlement assets. Explain
+those limits and offer the available scoped facts without best-price or safety
+claims.
 
 ## Language