@stelis/say-ur-intent 0.0.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/LICENSE +21 -0
- package/README.md +425 -0
- package/docs/AGENT_BEHAVIOR.md +462 -0
- package/docs/AGENT_DEVELOPMENT_POLICY.md +740 -0
- package/docs/FRONTEND_POLICY.md +234 -0
- package/docs/LOCAL_DB_ARCHITECTURE.md +85 -0
- package/docs/MCP_SETUP.md +496 -0
- package/docs/MCP_TOOLS.md +893 -0
- package/docs/SDK_API.md +116 -0
- package/docs/SIGNABLE_ADAPTER_CONTRACT.md +358 -0
- package/docs/TRANSACTION_ACTIVITY_LOG.md +182 -0
- package/docs/UTILITY_INDEX.md +180 -0
- package/docs/WALLET_IDENTITY.md +194 -0
- package/docs/golden-scenarios/BEHAVIOR_MATRIX.md +169 -0
- package/docs/golden-scenarios/INTENT_EVIDENCE_GOLDEN_ANSWERS.md +161 -0
- package/docs/golden-scenarios/INTENT_EVIDENCE_MATRIX.md +254 -0
- package/package.json +73 -0
- package/protocols/deepbook-margin.md +15 -0
- package/protocols/deepbook-v3.md +24 -0
|
@@ -0,0 +1,462 @@
|
|
|
1
|
+
# Agent Behavior Reference
|
|
2
|
+
|
|
3
|
+
This document is the MCP-exposed answer playbook for AI clients. It owns user-question flows, tool selection, and response wording boundaries.
|
|
4
|
+
|
|
5
|
+
It does not define tool schemas or field contracts. Use `docs/MCP_TOOLS.md` for the MCP API reference, response fields, statuses, and follow-up fields.
|
|
6
|
+
|
|
7
|
+
It is not the contributor rulebook and it is not enforcement. Development rules live in `AGENTS.md` and `docs/AGENT_DEVELOPMENT_POLICY.md`. Hard product boundaries live in code, schemas, allowlists, mainnet guards, and the local review layer.
|
|
8
|
+
|
|
9
|
+
## Support Matrix
|
|
10
|
+
|
|
11
|
+
| Surface | Status | Behavior |
|
|
12
|
+
| --- | --- | --- |
|
|
13
|
+
| 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. |
|
|
14
|
+
| DeepBook review sessions | Digest-gated handoff; user-controlled signing on the review page | A review URL can be created. The review URL displays the proposal and local review evidence. The account-bound review can build local unsigned DeepBook swap transaction material inside the review server, internally bind a Sui transaction digest to that stored material, and derive object ownership, quote/policy provenance, human-readable review facts, and review-time simulation evidence from the same private review artifacts. This release does not provide a sign action, signing data, MCP-visible transaction bytes, or signing readiness. The local review page requests a digest-gated byte handoff for a `ready_for_wallet_review` state, then the user signs in their own wallet and the page records the execution receipt. |
|
|
15
|
+
| External proposal review sessions | Non-signable review in the current release | `action.prepare_external_proposal_review` can create a review URL 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. |
|
|
16
|
+
| Wallet signing | User-controlled on the local review page | MCP tools do not return signing readiness, signing data, or executable transaction bytes. Signing and execution happen only in the user's wallet from the local review page after the digest-gated handoff; results are recorded as execution receipts keyed by the review session. |
|
|
17
|
+
| PTB visualization | Rendered with emitted wallet review contracts | `reviewState.ptbVisualization` can accompany an emitted wallet review contract as a Mermaid flowchart of the stored local transaction shape. Treat it as visualization evidence only, not transaction-building input, wallet authorization, signing data, signing readiness, payment execution readiness, or route recommendation. |
|
|
18
|
+
| Transaction material build, wallet execution, fiat cash-out, and P&L | Partly implemented for DeepBook review; execution unsupported | Account-bound DeepBook swap review can build local unsigned transaction material that remains internal to the review server, internally bind a Sui transaction digest to that stored material, project human-readable review facts from material-bound quote policy and object ownership evidence, and summarize review-time simulation of the stored material. Wallet signature requests and execution remain unavailable; the byte handoff is gated on recomputed-digest equality with the reviewed contract. Fiat cash-out, P&L, tax, and cost-basis support are not part of the current release. |
|
|
19
|
+
| 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. |
|
|
20
|
+
| 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. |
|
|
21
|
+
| 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. |
|
|
22
|
+
| Payment execution | Not yet available in the current release (sequenced later) | Intent evidence is separate from execution and does not build or execute payments. Do not describe payment execution as available until a reviewed implementation and response-local guidance exist. |
|
|
23
|
+
| Lending, staking, relative balance actions | Unsupported | Do not describe executable actions for these categories as available product functionality. |
|
|
24
|
+
|
|
25
|
+
## Meta Principles
|
|
26
|
+
|
|
27
|
+
- AI self-reports do not appear in user-facing checkout output.
|
|
28
|
+
- User-facing checkout output should contain server-validated structured facts.
|
|
29
|
+
- Ambiguous natural language is narrowed through structured evidence first, then clarification only where a user decision is required.
|
|
30
|
+
- Important UX rules should move into schemas, UI, and tests when the implementation boundary exists.
|
|
31
|
+
|
|
32
|
+
## Question First
|
|
33
|
+
|
|
34
|
+
Answer the user's question before moving toward an action.
|
|
35
|
+
|
|
36
|
+
When a tool response includes `userAnswerUse`, treat it as the response-local answer guide:
|
|
37
|
+
|
|
38
|
+
- check `userAnswerUse.preconditionFields` before using answer fields;
|
|
39
|
+
- use `userAnswerUse.answerFields` for the user-facing answer;
|
|
40
|
+
- apply `userAnswerUse.conclusionRuleFields` as limits on the final conclusion;
|
|
41
|
+
- use `userAnswerUse.diagnosticOnlyFields` only for source, limitation, pagination, or troubleshooting context;
|
|
42
|
+
- do not answer claims listed in `userAnswerUse.cannotAnswer`;
|
|
43
|
+
- when present, use `userAnswerUse.followUp.inputFields` as the fields to pass into `userAnswerUse.followUp.tool`, then use `userAnswerUse.followUp.answerFields` in that follow-up response.
|
|
44
|
+
|
|
45
|
+
When a USD-denominated settlement-asset response includes `answerSourceStatus`, check `answerSourceStatus.canUseThisResponseForUserAnswer`.
|
|
46
|
+
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.
|
|
47
|
+
|
|
48
|
+
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.
|
|
49
|
+
|
|
50
|
+
For SUI price questions:
|
|
51
|
+
|
|
52
|
+
- Call `read.get_deepbook_mid_price` with `poolKey: "SUI_USDC"` as the Say Ur Intent product source for supported SUI/DeepBook price context.
|
|
53
|
+
- Present the result as "DeepBook SUI/USDC mid price at `fetchedAt`" and do not call it the global market price.
|
|
54
|
+
- 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.
|
|
55
|
+
- When multiple pools match and the user did not name the quote token, use this split:
|
|
56
|
+
- For explicit pool-price questions, prefer a USDC-quoted pool, then USDT.
|
|
57
|
+
- For USD-denominated payment, balance, shortfall, coverage, settlement, or cash-out wording, use the intent-evidence flow instead.
|
|
58
|
+
- Name the pool checked and state that this is pool quote-token context, not settlement-token selection.
|
|
59
|
+
- If the token or pool is not in the pinned DeepBook registry, or the tool returns `quote_unavailable` or `registry_miss`, say DeepBook cannot provide that price from the current registry.
|
|
60
|
+
- Use external web data only if the user explicitly asks for non-product market context. Label it as outside Say Ur Intent verified state.
|
|
61
|
+
- If the tool returns `internal_error`, retry the same DeepBook price tool once. Do not retry more than once; if it still fails, say DeepBook read failed and do not present a price as Say Ur Intent verified state.
|
|
62
|
+
|
|
63
|
+
For indicative quote questions such as "If I sell 10 SUI, how much dollar value do I get?":
|
|
64
|
+
|
|
65
|
+
- Use `read.quote_deepbook_display_amount` only after the source asset, source input amount, pool or quote asset, and direction are known.
|
|
66
|
+
- A user saying "dollars" does not by itself select USDC, USDT, or another quote token.
|
|
67
|
+
- If the user names a source asset and says dollars without naming a quote token, first distinguish the intent:
|
|
68
|
+
- For USD-denominated payment coverage, balance total, shortfall, settlement, or cash-out wording, use settlement-asset-group intent evidence when account context is available.
|
|
69
|
+
- If account or target evidence is missing, ask only for that missing evidence.
|
|
70
|
+
- For a wallet-free market quote, ask which registered DeepBook quote asset or pool they want, such as SUI/USDC or SUI/USDT.
|
|
71
|
+
- Disclose the exact pool and `fetchedAt` after the user selects it.
|
|
72
|
+
- Do not silently choose a quote token.
|
|
73
|
+
- Do not web-search or finance-query a USDC/USD conversion unless the user explicitly asks for outside Say Ur Intent market context.
|
|
74
|
+
- Treat `amountDisplay` as the source input amount for the chosen direction. Do not use it as an output target amount.
|
|
75
|
+
- If the user asks how much source asset is needed to make a target output amount, say inverse quotes are unsupported in this release and ask for a source input amount instead.
|
|
76
|
+
- Treat `quantitySemantics.kind: "deepbook_quote_display_amount"` as exact decimal display quote strings only.
|
|
77
|
+
- Treat `rawQuote.kind: "deepbook_quote_raw_u64"` as raw quote evidence before slippage policy.
|
|
78
|
+
- 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.
|
|
79
|
+
- 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.
|
|
80
|
+
- Do not use quote proceeds as profit, P&L, tax, performance, or cost basis.
|
|
81
|
+
- If the user asks for profit after a quote, say Say Ur Intent can report quote proceeds and raw activity evidence, but it does not compute P&L.
|
|
82
|
+
- Do not provide profit formulas or hypothetical profit examples, even when the user supplies an assumed acquisition price.
|
|
83
|
+
|
|
84
|
+
## Current Release Evidence
|
|
85
|
+
|
|
86
|
+
Answer only from current tool evidence. For natural-language dollar, USD-like, stablecoin, or Korean dollar-word requests, use this flow:
|
|
87
|
+
|
|
88
|
+
1. Call `read.get_server_status`; require the current evidence policy plus `read.list_settlement_asset_groups` and `read.preview_intent_evidence`.
|
|
89
|
+
2. Call `read.list_settlement_asset_groups`.
|
|
90
|
+
3. Call `read.preview_intent_evidence` for settlement-asset coverage, balance-total, or shortfall questions.
|
|
91
|
+
4. Confirm `answerSourceStatus.canUseThisResponseForUserAnswer` is `true`.
|
|
92
|
+
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.
|
|
93
|
+
|
|
94
|
+
`responseSummary.answerCompleteness.answerCompleteFor` names the answer class. Use only the fields in `responseSummary.answerCompleteness.requiredAnswerFields` and `userAnswerUse.answerFields` for that class.
|
|
95
|
+
|
|
96
|
+
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.
|
|
97
|
+
|
|
98
|
+
Do not call quote tools for the same payment coverage, balance-total, or shortfall question when `responseSummary.doNotCallQuoteToolsForThisQuestion` is `true`.
|
|
99
|
+
|
|
100
|
+
When `answerSourceStatus.canUseThisResponseForUserAnswer` 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.
|
|
101
|
+
|
|
102
|
+
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`.
|
|
103
|
+
|
|
104
|
+
If `read.preview_intent_evidence.userAnswerUse` is present, its `answerFields` names the exact response fields to use for the answer.
|
|
105
|
+
|
|
106
|
+
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.
|
|
107
|
+
|
|
108
|
+
Selected-target evidence is allowed only when the user selected the target settlement asset in the current request or prior user context.
|
|
109
|
+
|
|
110
|
+
When that is true, use `targetAssetSelectionSource: "user_explicit"` or `"prior_user_explicit_context"` and answer from the returned selected-target fields. Do not set a target source for an AI-inferred target.
|
|
111
|
+
|
|
112
|
+
For shortfall questions without an established target amount, ask for the missing display target amount. Do not narrow the question to USDC/USDT, choose source assets, or merge non-group quote outputs into payment coverage.
|
|
113
|
+
|
|
114
|
+
Partial wallet context is allowed only when an active account is already set or the user gives an explicit Sui address.
|
|
115
|
+
|
|
116
|
+
Use supported reads to expose only returned facts:
|
|
117
|
+
|
|
118
|
+
- current coin-balance classes;
|
|
119
|
+
- supported settlement-asset-group balances;
|
|
120
|
+
- required user choices;
|
|
121
|
+
- uninspected inventory blockers.
|
|
122
|
+
|
|
123
|
+
Do not turn partial context into route recommendation, payment support, portfolio planning, P&L, transaction-building input, signing data, or signing readiness.
|
|
124
|
+
|
|
125
|
+
## Read Vs Action
|
|
126
|
+
|
|
127
|
+
Read-only requests split into address-free reads and address-scoped reads.
|
|
128
|
+
|
|
129
|
+
- Address-free reads include pool lists, orderbook context, mid prices, and quote facts.
|
|
130
|
+
- Address-scoped reads include explicit public-address snapshots and active-account reads.
|
|
131
|
+
- Use the explicit address when the user asks about a specific Sui address.
|
|
132
|
+
- Use wallet identity only when the request needs active account context.
|
|
133
|
+
- Action-preparation requests use words such as prepare, review, swap, buy, sell, or sign.
|
|
134
|
+
|
|
135
|
+
When an action is unsupported or blocked, say so plainly and offer the closest read-only information.
|
|
136
|
+
|
|
137
|
+
For token balances and quantities:
|
|
138
|
+
|
|
139
|
+
- Do not infer decimals from token symbols or common defaults.
|
|
140
|
+
- Use a returned `display` amount only when the tool provides it.
|
|
141
|
+
- If a result exposes only a raw amount or reports `unit.status: "unavailable"`, say display conversion is unavailable.
|
|
142
|
+
- Wallet balance reads are current coin-balance snapshots only.
|
|
143
|
+
- Transaction activity fields named `amountRaw`, `increaseRaw`, `decreaseRaw`, or `netRaw` are raw integer facts.
|
|
144
|
+
- Do not divide raw amounts into display units unless the same response provides verified decimals or a display amount for that asset.
|
|
145
|
+
|
|
146
|
+
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.
|
|
147
|
+
|
|
148
|
+
For `action.prepare_external_proposal_review`, answer from
|
|
149
|
+
`plans[].reviewModel` when the response `userAnswerUse.answerFields` lists that
|
|
150
|
+
path. Use `proposedAction`, `assetFlow`, `recipients`, `targets`,
|
|
151
|
+
`missingEvidence`, `requiredUserChoices`, `unsupportedClaims`, `freshness`,
|
|
152
|
+
`blockingChecks`, and `nonSignableReason`. Do not treat the proposal as trusted
|
|
153
|
+
transaction material. Do not treat it as route selection. Do not treat it as
|
|
154
|
+
settlement-token selection. Do not treat it as payment execution readiness. Do
|
|
155
|
+
not treat it as signing data or signing readiness.
|
|
156
|
+
|
|
157
|
+
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 page renders those fields as local review evidence.
|
|
158
|
+
|
|
159
|
+
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. This lifecycle stops at review-time simulation; the digest-gated byte handoff follows an emitted contract, while wallet signing and execution receipt happen on the local review page under the user's control. 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.
|
|
160
|
+
|
|
161
|
+
Use `reviewState.humanReadableReview` only as displayable review facts projected
|
|
162
|
+
from verified local review evidence. Its `kind` currently identifies the first
|
|
163
|
+
swap review projection. Its `assetFlow` raw amounts, coin types, decimals,
|
|
164
|
+
minimum output, fee facts, target pool, and direction are derived from the
|
|
165
|
+
material-bound quote policy evidence, while object ownership is cited only as
|
|
166
|
+
review evidence from stored transaction material and Sui owner/type reads.
|
|
167
|
+
Do not use `reviewState.humanReadableReview` as transaction bytes, a public transaction digest, signing data, signing readiness, route quality, wallet handoff, or execution readiness.
|
|
168
|
+
Treat any display amount in this field as presentation context only, not as a
|
|
169
|
+
signing or review-time simulation input.
|
|
170
|
+
|
|
171
|
+
Use `reviewState.simulation` only as a public summary of server-side
|
|
172
|
+
review-time simulation evidence for the stored local material. It can explain
|
|
173
|
+
provider, enabled checks, success, raw Sui gas cost summary components, balance
|
|
174
|
+
changes, and object changes when those fields are returned. It is not
|
|
175
|
+
transaction bytes, not a public transaction digest, not signing data, not
|
|
176
|
+
signing readiness, not wallet handoff, not execution readiness, not execution
|
|
177
|
+
receipt evidence, and not proof that a wallet signed or submitted a transaction.
|
|
178
|
+
|
|
179
|
+
`reviewState.walletReviewAdapterContract` is present only on a
|
|
180
|
+
`ready_for_wallet_review` state (or a stored legacy
|
|
181
|
+
`wallet_handoff_not_implemented` record), after every review evidence stage
|
|
182
|
+
completed and contract assembly passed schema validation. Use it only as
|
|
183
|
+
pre-signing review evidence that binds the human-readable review and the
|
|
184
|
+
review-time simulation to one transaction commitment hash. It is not
|
|
185
|
+
transaction bytes, not signing data, not signing readiness, not wallet
|
|
186
|
+
handoff, not execution readiness, and not a route recommendation. If the
|
|
187
|
+
review is blocked on `wallet_review_contract_emit_missing`, say that contract
|
|
188
|
+
assembly declined and use the failed
|
|
189
|
+
`deepbook_wallet_review_contract_emit_missing` check message for the concrete
|
|
190
|
+
reason.
|
|
191
|
+
|
|
192
|
+
If a response includes a `PtbVisualizationArtifact`, answer from its Mermaid
|
|
193
|
+
text, diagnostics, `generatedAt`, `source`, and `unsupportedUse` fields only
|
|
194
|
+
when the response-local guide lists them as answer fields. Do not treat a PTB
|
|
195
|
+
graph as transaction material, raw transaction bytes, or wallet authorization.
|
|
196
|
+
A PTB graph is not signing data, not signing readiness, not payment execution
|
|
197
|
+
readiness, not route quality, and not execution safety.
|
|
198
|
+
|
|
199
|
+
Use these response fields:
|
|
200
|
+
|
|
201
|
+
- wallet balance amounts: `read.summarize_wallet_assets`;
|
|
202
|
+
- coin-balance classes: `read.classify_wallet_assets`;
|
|
203
|
+
- USD-denominated coverage, total, or shortfall: fields listed by `read.preview_intent_evidence.userAnswerUse.answerFields`;
|
|
204
|
+
- stablecoin-like parity: `read.summarize_settlement_asset_group_parity.responseSummary`;
|
|
205
|
+
- DeepBook BalanceManager inventory: `read.summarize_deepbook_account_inventory`.
|
|
206
|
+
|
|
207
|
+
For USD-denominated coverage and shortfall, answer from `responseSummary.currentDisplayAmount`, `responseSummary.requiredDisplayAmount`, and `responseSummary.shortfallDisplayAmount` according to `responseSummary.amountsUsedForAnswer`.
|
|
208
|
+
|
|
209
|
+
Use `responseSummary.separateQuoteOutputs` to explain separate quote calls. When it returns `usedForPaymentAnswer: false` or `usedForShortfallAnswer: false`, do not add those quote outputs to the payment amount or shortfall amount.
|
|
210
|
+
|
|
211
|
+
Use `responseSummary.doNotUseForConclusion` and `responseSummary.excludedFromConclusion` as exclusion rules for the final conclusion. If those fields name separate quote results, outside-settlement-group assets, or route-dependent payment support, do not write a conclusion such as "including other assets", "if everything is converted", "combined", or "still short" from quote outputs.
|
|
212
|
+
|
|
213
|
+
Interpret common `quantitySemantics.kind` values this way:
|
|
214
|
+
|
|
215
|
+
- `sui_wallet_balance_snapshot`: current coin-balance snapshot only.
|
|
216
|
+
- `sui_intent_evidence_report`: pre-transaction evidence summary only.
|
|
217
|
+
- `deepbook_display_number`: display-like account inventory only.
|
|
218
|
+
|
|
219
|
+
Use quote tools only for explicit source inputs:
|
|
220
|
+
|
|
221
|
+
- Use `read.quote_deepbook_action` only when a raw integer amount is explicit.
|
|
222
|
+
- Use `read.quote_deepbook_display_amount` when the user provides a decimal source input amount.
|
|
223
|
+
|
|
224
|
+
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`.
|
|
225
|
+
|
|
226
|
+
Treat DeepBook `rawQuote` fields as exact quote evidence from simulated `u64` return values.
|
|
227
|
+
|
|
228
|
+
Do not turn quote evidence into:
|
|
229
|
+
|
|
230
|
+
- final min-out;
|
|
231
|
+
- effective price;
|
|
232
|
+
- price impact;
|
|
233
|
+
- venue comparison;
|
|
234
|
+
- best route;
|
|
235
|
+
- fiat cash-out;
|
|
236
|
+
- unsupported P&L or cost basis;
|
|
237
|
+
- signing input.
|
|
238
|
+
|
|
239
|
+
Treat `uninspectedAssetClasses` as explicit classifier-uninspected boundaries, not as zero balances.
|
|
240
|
+
|
|
241
|
+
Inventory facts do not imply:
|
|
242
|
+
|
|
243
|
+
- spendability;
|
|
244
|
+
- funding availability;
|
|
245
|
+
- route liquidity;
|
|
246
|
+
- payment readiness;
|
|
247
|
+
- portfolio completeness;
|
|
248
|
+
- transaction-building inputs;
|
|
249
|
+
- signing data;
|
|
250
|
+
- not signing readiness.
|
|
251
|
+
|
|
252
|
+
Treat `quantitySemantics.kind: "settlement_asset_group_parity_snapshot"` as internal settlement-asset-group parity evidence only.
|
|
253
|
+
|
|
254
|
+
The returned `responseSummary.referenceAssetRole: "measurement_reference_not_settlement_choice"` means the reference is a measurement basis, not the user's settlement token.
|
|
255
|
+
|
|
256
|
+
The summary exposes min, max, mean, and median parity from available direct DeepBook mid-price snapshots.
|
|
257
|
+
|
|
258
|
+
Do not treat parity output as fiat USD value, USDC/USD peg assumption, payment readiness, route recommendation, transaction building, signing readiness, P&L, or cost basis.
|
|
259
|
+
|
|
260
|
+
If a wallet read returns `metadata_cache_unavailable`, retry the same wallet read once.
|
|
261
|
+
|
|
262
|
+
If it repeats, say the local coin metadata cache is unavailable and the wallet display-unit read cannot be completed right now.
|
|
263
|
+
|
|
264
|
+
Treat `details.operation` as diagnostic context, not as a user action field.
|
|
265
|
+
|
|
266
|
+
When the user says only `$1000`, "1000 dollars", "stablecoins", or Korean dollar-word wording, do not choose USDC, USDT, source assets, or routes. Use the intent-evidence flow and ask only for `responseSummary.requiredUserChoices`.
|
|
267
|
+
|
|
268
|
+
For common USD-denominated evidence questions:
|
|
269
|
+
|
|
270
|
+
| User asks | Tool input | User response field |
|
|
271
|
+
| --- | --- | --- |
|
|
272
|
+
| "Can I cover a 1000 dollar payment?" | `read.preview_intent_evidence` with `intentKind: "cover_payment_like_amount"`, `denomination: "dollar"`, `requiredDisplayAmount: "1000"` | `responseSummary` |
|
|
273
|
+
| "How much are my USD-denominated assets together?" | `read.preview_intent_evidence` with `intentKind: "summarize_settlement_asset_group_balance"`, `denomination: "dollar"` | `responseSummary` |
|
|
274
|
+
| "What is the shortfall?" | Reuse the established target amount, or ask for the missing display target amount | `responseSummary` |
|
|
275
|
+
|
|
276
|
+
Describe a connected wallet identity as active account context for local reads.
|
|
277
|
+
|
|
278
|
+
Do not call the user logged in, authenticated for transactions, signed in, connected for signing, or permanently authorized. The active account context can be cleared at any time and disappears if the local MCP server is reinstalled.
|
|
279
|
+
|
|
280
|
+
For wallet identity:
|
|
281
|
+
|
|
282
|
+
- First call `account.get_active_account` when a wallet-account read can use existing context.
|
|
283
|
+
- If it is `set`, use that account.
|
|
284
|
+
- Mention `source` and `setAt` when the account may have been set by an earlier session or another MCP client.
|
|
285
|
+
- Ask for confirmation when the user wants a different address.
|
|
286
|
+
- If the user explicitly asks to connect, reconnect, or replace wallet context, create a new wallet identity session even when an active account is already set.
|
|
287
|
+
|
|
288
|
+
When a new wallet identity session is needed:
|
|
289
|
+
|
|
290
|
+
1. Call `session.create_wallet_identity`.
|
|
291
|
+
2. Tell the user to open `walletUrl` in the same machine's system browser.
|
|
292
|
+
3. Immediately call `session.wait_wallet_identity` in the same turn after giving the URL; do not stop and wait for the user to say they connected. If the wait tool is unavailable, poll `session.get_wallet_identity` about every 5 seconds.
|
|
293
|
+
4. When the wallet status is `connected`, call `account.get_active_account` again before telling the user which account is currently active.
|
|
294
|
+
5. If `session.wait_wallet_identity` returns `timed_out`, say the wallet connection is still pending; do not treat it as failure.
|
|
295
|
+
6. If the wallet status is `rejected`, `failed`, or `expired`, tell the user that concrete outcome and do not claim an active account was set.
|
|
296
|
+
|
|
297
|
+
The URL contains a short-lived fragment token. Do not tell the user to copy it to another device, share it, or open it in a client webview.
|
|
298
|
+
|
|
299
|
+
Display addresses in shortened lowercase form by default: `0x` plus the first 4 hex characters, `...`, and the last 4 hex characters, such as `0xabcd...1234`. Show the full address only when the user asks or when exact verification is needed.
|
|
300
|
+
|
|
301
|
+
Pending wallet identity and review waits are local process memory only.
|
|
302
|
+
|
|
303
|
+
- If the local MCP server restarts, call `account.get_active_account` before creating a new wallet identity session.
|
|
304
|
+
- Use `session.get_interaction_status` to inspect active account context and pending in-memory interactions.
|
|
305
|
+
- In `session.get_interaction_status`, `pendingReviewSessions` includes non-final review sessions whose `statusCategory` is `non_terminal`, `awaiting_chain_result`, or `user_action_required`.
|
|
306
|
+
- `session.get_review_status` returns `pollingStatus` and `statusCategory`; use both fields when explaining whether a review is final, still pending, waiting for a chain result, or waiting for user or review-flow action.
|
|
307
|
+
- `session.wait_execution_result` observes review-server/browser transitions only.
|
|
308
|
+
- `timed_out` means the step is still pending.
|
|
309
|
+
- `signed_pending_result` means signing already happened and the tool is waiting for the chain result; do not ask the user to sign again.
|
|
310
|
+
- `blocked` means user action or refresh is required, not final success or failure.
|
|
311
|
+
- execution waits stop at `blocked` only while required review evidence is missing; after user signing on the local review page they progress through `signed_pending_result` to `success` or `failure`.
|
|
312
|
+
|
|
313
|
+
Local review activity tools summarize Say Ur Intent review-session records only. They are separate from user-requested Sui activity scans.
|
|
314
|
+
|
|
315
|
+
If the user asks about Say Ur Intent reviews, use one of these tools:
|
|
316
|
+
|
|
317
|
+
- `read.list_review_activity`;
|
|
318
|
+
- `read.summarize_review_funnel`;
|
|
319
|
+
- `read.get_review_session_detail`.
|
|
320
|
+
|
|
321
|
+
The optional `account` input is a read filter. It does not change active account context.
|
|
322
|
+
|
|
323
|
+
`accountSource` reports how the read scope was selected, not proof of wallet ownership.
|
|
324
|
+
|
|
325
|
+
Sui activity tools answer user-requested transaction questions from GraphQL read results and stored normalized facts.
|
|
326
|
+
|
|
327
|
+
Use the summary path first:
|
|
328
|
+
|
|
329
|
+
- `read.summarize_sui_activity_scan` for recent activity, latest activity, asset-flow summary, protocol summary, gas summary, or failure summary.
|
|
330
|
+
- `read.scan_sui_account_activity` when the user asks for bounded transaction rows.
|
|
331
|
+
- `read.inspect_sui_transaction` when the user provides one digest or asks for digest-level detail.
|
|
332
|
+
- `read.summarize_sui_account_activity` only for stored local activity facts.
|
|
333
|
+
|
|
334
|
+
Important scan boundaries:
|
|
335
|
+
|
|
336
|
+
- Scans are bounded to at most 100 results per call and are not background indexing.
|
|
337
|
+
- `orderingVerified: false` means provider ordering was not proven.
|
|
338
|
+
- `continuationCursor` is best-effort provider pagination, not a durable index cursor.
|
|
339
|
+
- Use live scan evidence for "latest N" unless the user asks for stored facts.
|
|
340
|
+
|
|
341
|
+
Wallet-specific balance evidence must come from requested-account fields:
|
|
342
|
+
|
|
343
|
+
- `requestedAccountTransactionFacts`;
|
|
344
|
+
- `requestedAccount.coinFlows`;
|
|
345
|
+
- `transactions[].requestedAccountEffect`.
|
|
346
|
+
|
|
347
|
+
Do not use transaction-level context as wallet-specific balance evidence. `transactionContext` intentionally has no transaction-wide balance-change aggregate in live scan rows. Use `transactionContext`, `compact`, `details`, `execution`, or `requestedAccountEffect` in an answer only when the same response returns that field and lists it in `userAnswerUse.answerFields`.
|
|
348
|
+
|
|
349
|
+
For Sui activity array paths, `userAnswerUse.answerFields` lists `transactions[].transactionContext`, `transactions[].compact`, or `transactions[].details` only when every returned `transactions` row has that field. When `transactionDetailAvailability.detailAvailability: "some"`, some rows have details and some do not; use `transactionDetailAvailability` in the answer and inspect the specific row or follow-up digest lookup before using row details.
|
|
350
|
+
|
|
351
|
+
Incomplete balance evidence means unknown, not zero:
|
|
352
|
+
|
|
353
|
+
- `accountBalanceChangeEvidence: "incomplete_account_balance_changes"` is not zero-balance evidence.
|
|
354
|
+
- `account_balance_changes_unavailable` is not zero-balance evidence.
|
|
355
|
+
- `accountBalanceChangeInferencePolicy: "do_not_infer_from_transaction_context"` means do not infer the requested account amount from transaction context, visible recipient patterns, current wallet balances, compact counts, or aggregate analysis.
|
|
356
|
+
- Only `accountBalanceChangeAbsenceProven: true` supports saying no requested-account balance change was returned.
|
|
357
|
+
|
|
358
|
+
Compact and analysis fields are transaction or page facts:
|
|
359
|
+
|
|
360
|
+
- `compact.factScope: "transaction"` means compact fields summarize the transaction, not the requested wallet.
|
|
361
|
+
- `analysis.coinFlows` is a transaction/page aggregate, not wallet-specific evidence.
|
|
362
|
+
- `protocolMatches` are conservative activity labels derived from normalized facts.
|
|
363
|
+
- `mvrName` is package-resolution evidence, not protocol support, P&L, route quality, transaction-building input, signing data, or signing readiness.
|
|
364
|
+
|
|
365
|
+
Raw amount handling:
|
|
366
|
+
|
|
367
|
+
- Balance-change quantities are raw integer strings.
|
|
368
|
+
- There is no `details.balanceChanges[].amount` field.
|
|
369
|
+
- Do not coerce missing fields to `number`.
|
|
370
|
+
- Gas raw quantities use MIST.
|
|
371
|
+
- Prefer returned `gasCost.display` or `analysis.gas.netGasCost.display` over manual gas conversion.
|
|
372
|
+
|
|
373
|
+
If returned evidence is incomplete or unverified, say so before using it. If a transaction or explicit address scan is unrelated to a known local wallet, say it was not saved locally and use the ephemeral result only for the current answer.
|
|
374
|
+
|
|
375
|
+
### Function Activity Diagnostics
|
|
376
|
+
|
|
377
|
+
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.
|
|
378
|
+
|
|
379
|
+
Rules:
|
|
380
|
+
|
|
381
|
+
- The `function` input must be a full `package::module::function` string.
|
|
382
|
+
- Do not pass package-only, package-and-module-only, generic/type-argument forms, or a bare function name.
|
|
383
|
+
- Describe the result as "transactions this account sent that called this function."
|
|
384
|
+
- Do not describe it as every affected transaction, every touched object, or complete dApp history.
|
|
385
|
+
- Empty results mean the bounded page returned no matching sent rows; they do not prove no matching activity exists.
|
|
386
|
+
|
|
387
|
+
Function activity facts are not route quality, P&L, wallet position inventory, transaction-building input, signing data, signing readiness, protocol support, or complete history.
|
|
388
|
+
|
|
389
|
+
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 identity for that public-address read.
|
|
390
|
+
|
|
391
|
+
If the user asks for the active wallet's balances without giving an address, use active account context. Create a wallet identity session only when no active account is set.
|
|
392
|
+
|
|
393
|
+
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.
|
|
394
|
+
|
|
395
|
+
Do not call stored Sui activity complete wallet history, P&L, balance history, complete gas history, portfolio analysis, tax data, or proof of ownership.
|
|
396
|
+
|
|
397
|
+
If the user wants a time range, explain that the tool requests bounded recent-to-older pages and can continue page by page.
|
|
398
|
+
|
|
399
|
+
Do not claim a time window is complete unless `windowComplete: true`.
|
|
400
|
+
|
|
401
|
+
Do not call the page provider-verified coverage when `orderingVerified: false`.
|
|
402
|
+
|
|
403
|
+
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."
|
|
404
|
+
|
|
405
|
+
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`.
|
|
406
|
+
|
|
407
|
+
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.
|
|
408
|
+
|
|
409
|
+
For local settings or local data management, call `settings.create_local_settings_session` and tell the user to open the returned settings URL in the same machine's system browser.
|
|
410
|
+
|
|
411
|
+
Do not call MCP tools to mutate settings directly; direct settings mutator tools are not exposed. Do not call clearing active account a wallet disconnect. Endpoint changes apply after MCP server restart.
|
|
412
|
+
|
|
413
|
+
## User Vocabulary
|
|
414
|
+
|
|
415
|
+
Do not silently turn vague words into amounts.
|
|
416
|
+
|
|
417
|
+
| User phrase | Response |
|
|
418
|
+
| --- | --- |
|
|
419
|
+
| `a little`, `some`, `roughly` | Ask for an amount and offer examples such as `1 SUI`, `10%`, or `25%`. |
|
|
420
|
+
| `half` | Explain that active account context is needed to calculate spendable balance. If none is set, ask for wallet identity connection. Do not ask for manual address entry. |
|
|
421
|
+
| `all`, `everything` | Explain that gas reserve and spendable balance must be calculated before an action can be prepared. |
|
|
422
|
+
| Number only, such as `5` | Ask which unit the user means: SUI, another asset, or a USD-denominated amount. If they mean dollars or stablecoins, use settlement-asset-group evidence before asking for a specific token. |
|
|
423
|
+
|
|
424
|
+
## Clarification Templates
|
|
425
|
+
|
|
426
|
+
- Amount: "What amount do you want to use? Examples: `1 SUI`, `10 SUI`, or `$10 worth`."
|
|
427
|
+
- Unit: "When you say `5`, do you mean 5 SUI, another asset amount, or $5 through the supported USD-denominated settlement asset group?"
|
|
428
|
+
- Balance-dependent amount: "Half or all depends on your spendable balance. I need active account context before I calculate wallet-account amounts."
|
|
429
|
+
- Unsupported action: "That action is not currently supported. I can help with supported Sui mainnet reads or DeepBook quotes instead."
|
|
430
|
+
|
|
431
|
+
## Unsupported Redirects
|
|
432
|
+
|
|
433
|
+
| Request | Response pattern |
|
|
434
|
+
| --- | --- |
|
|
435
|
+
| "Is this transaction safe?" | Do not guarantee safety. Summarize concrete facts: assets, amount, venue, freshness, and current blocked/readiness status. |
|
|
436
|
+
| "Do you think I should buy this?" | Do not give investment advice. Offer price, liquidity, quote, and risk-input facts when supported. |
|
|
437
|
+
| "Tell me when the price drops." | Say alerts are unsupported. Offer a one-time price or quote check. |
|
|
438
|
+
| "Let's buy Bitcoin too." | Say this toolkit only exposes Sui mainnet surfaces. |
|
|
439
|
+
| "Am I connected? / Am I logged in?" | Say the toolkit has active wallet-account read context for the address, not a login. Use `account.get_active_account` to confirm the address. Do not say the user is connected to DeepBook or signed in. |
|
|
440
|
+
| "Show my balances over time." | Balance history and P&L are not tool surfaces. `read.summarize_wallet_assets` returns a snapshot at `fetchedAt`. Each call is independent. |
|
|
441
|
+
| "How much profit did I make?" | Profit, tax, performance, and cost-basis calculations are not Say Ur Intent surfaces. Offer raw activity, balance snapshots, or quote evidence instead; do not provide a profit formula or hypothetical profit example. |
|
|
442
|
+
| "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. |
|
|
443
|
+
| "Did my swap go through?" | If the swap was signed through a Say Ur Intent review session, use `session.get_review_status` or `session.wait_execution_result`: `success` with `txDigest` is the recorded receipt evidence, and `failure` carries the failure reason. 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. |
|
|
444
|
+
| "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. |
|
|
445
|
+
| "Cancel the transaction I just sent." | Say already-submitted onchain transactions cannot be canceled by this toolkit. |
|
|
446
|
+
| "Can I trust this address?" | Say address reputation lookup is unsupported. Use only verified mainnet protocol surfaces when preparing reviews. |
|
|
447
|
+
|
|
448
|
+
## Comparisons
|
|
449
|
+
|
|
450
|
+
Only compare options when the user asks for a criterion such as cheaper, lower slippage, or less SUI spent.
|
|
451
|
+
|
|
452
|
+
State the checked scope and timestamp.
|
|
453
|
+
|
|
454
|
+
Avoid unqualified words such as best, recommended, guaranteed, or safe. Prefer: "Among checked options, at this quote time..."
|
|
455
|
+
|
|
456
|
+
## Language
|
|
457
|
+
|
|
458
|
+
This reference document stays in English. Reply in the user's language. Translate response patterns as needed, but keep SDK names, tool names, object IDs, package IDs, and token symbols in their original form.
|
|
459
|
+
|
|
460
|
+
## Golden Scenarios
|
|
461
|
+
|
|
462
|
+
Detailed expected response classes live in `docs/golden-scenarios/BEHAVIOR_MATRIX.md`. They are documentation for release review, not automated cross-client results.
|