Lukka Digital Assets Intel

View saved version →

---
name: asset-activity
description: "Activity-focused asset report with trends, volume, and recent events"
---

## OpenAI connection notes

Tool identifiers below are raw operation names. The host may add a namespace;
use the matching advertised Global MCP tool. Resolve `<resolved-package-root>`
to this plugin's installed directory before using paths. Workflow names identify
packaged skills; they are not literal Claude slash commands.

Original procedure tool scope: `pricing___get_candles`, `pricing___get_latest_market_caps`, `pricing___get_market_capitalization`, `pricing___get_market_depth`, `pricing___get_vwap`, `refdata___get_asset_by_id`, `refdata___get_asset_crypto_actions`, `refdata___get_asset_mappings`.

# asset-activity workflow

> See [CONNECTORS.md](../../CONNECTORS.md) for tool details.

## Usage

asset-activity workflow <user input>

## Flow

1. **Resolve code -> assetLid**: `refdata___get_asset_mappings({ lukkaAssetCode: "<user input>", mappingStatus: "Active", limit: 5 })`  -> take `lukkaAssetId` from first row
   - Name lookups resolve through RefData mappings; translate free-form names to canonical codes first; `list_assets` filters by `lukkaAssetIds` / `assetGroupId`, code resolution goes through `get_asset_mappings`
2. **Metadata**: `refdata___get_asset_by_id({ assetLid })` 
3. **Price trend**: `pricing___get_candles({ sourceId: 4002, pairCode: "{code}-USD", interval: 86400000, from: 30d_ago, to: now })`  (sourceId 4002 = Coinbase Pro, schema default)
   - 30d change % = `(last_close - first_open) / first_open * 100`
4. **VWAP (7d)**: `pricing___get_vwap({ pairCode: "{code}-USD", sourceIds: top_exchange_ids, from: 7d_ago, to: now })` 
   - max 7-day range per call
5. **Market cap + rank**:
   - `pricing___get_market_capitalization({ pairCode: "{code}-USD", limit: 1 })`  -> USD cap. Takes single `pairCode` (BASE-USD), NOT `assetCodes`.
   - `pricing___get_latest_market_caps({ limit: 100, order: "DESC" })`  -> find position of `{code}` in list; if not present, rank is "100+"
6. **Liquidity** (deterministic exchange selection: top 5 from `get_pair_mappings` where exchange is in {KRAK, CPRO, BINA, BFNX, GMNI}):
   Per exchange: `pricing___get_market_depth({ sourceIds: "{single}", baseAssetCodes: "{code}", counterAssetCodes: "USD" })` 
7. **Exchange coverage**: `refdata___get_asset_mappings({ lukkaAssetCode: "{code}", mappingStatus: "Active" })` 
8. **Recent events**: `refdata___get_asset_crypto_actions({ assetLid: "{LID}", domain: "assets" })`  - takes `assetLid` (LA-code), NOT `assetCode`; `domain` required.

## Output

### Activity Report: {asset_name} ({code})

**Price Trend (30d)**
- Current: ${price}
- 30d high: ${high}
- 30d low: ${low}
- 30d change: {pct}%

**Volume (7d)**
- 7d avg daily: ${vol}
- 7d VWAP: ${vwap}
- VWAP deviation: {bps} bps

**Market Cap**: ${cap} (rank #{rank})

**Liquidity Snapshot**
| Exchange | Bid Depth | Ask Depth | Spread |
|----------|-----------|-----------|--------|

**Exchange Coverage**: {count} active listings

**Recent Events**
| Date | Event | Description |
|------|-------|-------------|

View saved version →

---
name: asset-discovery
description: "Cross-MCP asset resolution and enrichment agent. Finds assets by direct code, resolves Lukka IDs, gathers metadata from refdata, and fetches pricing."
---

## OpenAI connection notes

Tool identifiers below are raw operation names. The host may add a namespace;
use the matching advertised Global MCP tool. Resolve `<resolved-package-root>`
to this plugin's installed directory before using paths. Workflow names identify
packaged skills; they are not literal Claude slash commands.

Original procedure tool scope: `refdata___list_assets`, `refdata___get_asset_by_id`, `refdata___get_sectors`, `refdata___get_core_asset_scores`, `refdata___get_asset_mappings`, `refdata___get_asset_crypto_actions`, `refdata___get_crypto_actions`, `refdata___get_reference_assets`, `pricing___get_latest_prices`, `pricing___get_market_capitalization`, `pricing___get_latest_market_caps`, `pricing___get_candles`, `pricing___get_historical_prices`.

You are an asset discovery and enrichment agent. Your job is to find digital assets across Lukka's hosted data and build complete profiles.

## Tool Naming

All tools use the triple-underscore wire format:
- `refdata___*`
- `pricing___*`

Resolution path on this surface: alias map -> get_asset_mappings(entityAssetCode) -> get_asset_by_id. Use direct code lookup and the known canonical-code map (`XBT`, `ETH`, `SOLN`, `USDC`, `USDT`, ...).

## Algorithm

### Phase 1: Asset Discovery

1. `refdata___get_asset_mappings({ lukkaAssetCode: "{input}", mappingStatus: "Active", limit: 10 })`
   - If input is a free-form name (e.g. "Solana"), translate to canonical code (`SOLN`) first
   - `list_assets` filters by `lukkaAssetIds` / `assetGroupId`; code resolution goes through `get_asset_mappings`
2. Select the best match (most active mappings)
3. Extract: `lukkaAssetId` (use as `assetLid`), `lukkaAssetCode`; pull `blockchain` + `assetType` via step 2 below.

### Phase 2: Metadata Enrichment (parallel)

With the `assetLid`:
1. `refdata___get_asset_by_id({ assetLid })` - full metadata
2. `refdata___get_sectors({ assetLid })` - LDACS 5-tier
3. `refdata___get_core_asset_scores({ assetLid, fromDate, toDate })` - LCAS (REQUIRES both dates)
4. `refdata___get_asset_mappings({ lukkaAssetCode, mappingStatus: "Active", limit: 50 })` - coverage
5. `refdata___get_asset_crypto_actions({ assetLid, domain: "assets" })` - events (takes `assetLid`, NOT `assetCode`; `domain` required)

### Phase 3: Pricing Data (parallel)

Form pairCode as `{lukkaAssetCode}-USD`:
1. `pricing___get_latest_prices({ sourceId: 1000, pairCodes: "{code}-USD" })` (sourceId 1000 = Lukka Prime EOD)
2. `pricing___get_market_capitalization({ pairCode: "{code}-USD", limit: 1 })` (single pairCode, NOT assetCodes)
3. `pricing___get_candles({ sourceId: 4002, pairCode: "{code}-USD", interval: 86400000 })` (sourceId 4002 = Coinbase Pro)

### Phase 4: Return Complete Profile

Return a structured asset profile with identity, classification, scores, mappings, price + cap, and recent events.

## Quality Standards

- Always resolve the code to `assetLid` before calling refdata tools that need an ID
- Pair format: `XBT-USD` (never `BTC-USD`). Solana = `SOLN-USD`
- Intervals in milliseconds (`86400000` = 1 day)
- `get_core_asset_scores` requires BOTH `fromDate` + `toDate`
- If asset not found, try alternative canonical aliases before giving up
- For multi-chain assets, iterate known suffix variants (`USDC`, `USDC.SOL`, `USDC.POLY`) - name lookups resolve through RefData mappings

View saved version →

---
name: asset-report
description: "Comprehensive asset deep dive with classification, scores, and exchange coverage"
---

## OpenAI connection notes

Tool identifiers below are raw operation names. The host may add a namespace;
use the matching advertised Global MCP tool. Resolve `<resolved-package-root>`
to this plugin's installed directory before using paths. Workflow names identify
packaged skills; they are not literal Claude slash commands.

Original procedure tool scope: `pricing___get_latest_prices`, `pricing___get_market_capitalization`, `refdata___get_asset_by_id`, `refdata___get_asset_crypto_actions`, `refdata___get_asset_mappings`, `refdata___get_core_asset_scores`, `refdata___get_sectors`.

# asset-report workflow

> See [CONNECTORS.md](../../CONNECTORS.md) for tool details.

## Usage

asset-report workflow <user input>

## Flow

1. **Resolve ticker -> assetLid** (resolution path: alias map -> `get_asset_mappings(entityAssetCode)` -> `get_asset_by_id`; `list_assets` filters by `lukkaAssetIds` / `assetGroupId`). The input is a **street ticker**, not a `lukkaAssetCode` - on collisions the bare code is the oldest (often inactive) asset (e.g. `lukkaAssetCode:"TKN"` returns the older migrated asset, never the current one). Resolve via the **asset-resolver** skill:
   - If input is a name (e.g. "Solana") or a known major, translate via the alias map (`XBT`, `ETH`, `SOLN`, `USDC`, `USDT`, ...) - aliased codes are unique, query `lukkaAssetCode` directly.
   - Otherwise treat as a raw ticker: `refdata___get_asset_mappings({ entityAssetCode: "<user input>", mappingStatus: "Active", limit: 200 })` 
   - Collect distinct `lukkaAssetId` values. For each, `get_asset_by_id` -> drop `Inactive`/`Contract Migrated`, collapse chain-variants to the group `isPrimaryAsset: true` LID.
   - **One** active asset survives -> use its LID as `assetLid`. **More than one** (e.g. a large fund vs a same-ticker token on another chain vs an unrelated same-ticker token) -> list candidates and ask the user to pick; do not auto-resolve.
2. **Full metadata**: `refdata___get_asset_by_id({ assetLid })` 
   - Includes `assetDetails` (stakeable, minable, stable, wrapped, governanceToken), `blockchainDetails`, `governanceDetails`, `participantDetails`
3. **Classification**: `refdata___get_sectors({ assetLid })`  - 5-tier LDACS
4. **Quality score**: `refdata___get_core_asset_scores({ assetLid, fromDate: 30d_ago, toDate: today })` 
   - **REQUIRED**: both `fromDate` + `toDate` (ISO 8601), else returns empty
5. **Exchange coverage**: `refdata___get_asset_mappings({ entityCode: <optional>, lukkaAssetCode, mappingStatus: "Active", limit: 50 })` 
6. **Crypto Actions** (past + future): `refdata___get_asset_crypto_actions({ assetLid: "{LID}", domain: "assets" })` 
   - Takes `assetLid` (the LA-code resolved in step 1-2), NOT `assetCode`. `domain` is required (`assets`|`derivatives`|`assetMappings`|`pairMappings`).
   - Sort results by date descending (newest first)
7. **Price + market cap**: `pricing___get_latest_prices({ sourceId: 1000, pairCodes: "{code}-USD" })` + `pricing___get_market_capitalization({ pairCode: "{code}-USD", limit: 1 })`  (sourceId 1000 = Lukka Prime EOD). NOTE `get_market_capitalization` takes a single `pairCode` (BASE-USD), NOT `assetCodes`; for a top-N multi-asset snapshot use `get_latest_market_caps`.

## Output

### Asset Report: {asset_name} ({lukka_code})

**Identity**
- Lukka ID: {assetLid}
- Lukka Code: {lukkaAssetCode}
- Blockchain: {blockchain}
- Type: {assetType}
- Token Standard: {tokenStandard}

**Classification (LDACS)**
- Super Sector > Macro > Mid > Sub > Category

**Scores**
- LCAS: {score}/100 ({rating})

**Market Data**
- Price: ${price} (Lukka Prime EOD)
- Market Cap: ${marketCap}

**Exchange Coverage** ({count} active mappings)
| Exchange | Mapping Code | Status |
|----------|-------------|--------|

**Governance**
- Open Source: {yes/no/Not disclosed}
- Bug Bounty: {yes/no/Not disclosed}
- Foundation: {yes/no/Not disclos

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: asset-resolver
description: "Resolve customer-provided white paper codes (ticker symbols like BTC, ETH, GALA) to Lukka asset codes and retrieve Lukka Prime prices. Use when: (1) customer provides white paper codes / ticker symbols and needs prices, (2) mapping white paper codes to Lukka asset codes, (3) identifying the correct asset among duplicates, (4) bulk asset resolution for client deliverables, (5) user says \"resolve\" + asset/ticker/code."
---

## OpenAI connection notes

Tool identifiers below are raw operation names. The host may add a namespace;
use the matching advertised Global MCP tool. Resolve `<resolved-package-root>`
to this plugin's installed directory before using paths. Workflow names identify
packaged skills; they are not literal Claude slash commands.

# Asset Resolver

**STANDALONE**: This skill provides the white paper code to Lukka canonical code mapping (BTC->XBT, SOL->SOLN, GALA->GALAT3) and resolution workflow logic. **SUPERCHARGED**: When Lukka-RefData and Lukka-Pricing MCP servers are connected, it resolves codes live with exchange mapping counts, status validation, and real-time Lukka Prime prices.

Resolve white paper codes to Lukka asset codes and fetch Lukka Prime prices using the hosted Lukka-RefData and Lukka-Pricing MCP servers.

Resolution path on this surface: alias map -> get_asset_mappings(entityAssetCode) -> get_asset_by_id.

## Critical: the input is a STREET TICKER, not a `lukkaAssetCode`

User input (`TKN`, `GALA`, `BTC`) is a **street ticker**. `lukkaAssetCode` is Lukka's **internal canonical code** - these are NOT the same. On ticker collisions Lukka keeps the bare code on the **oldest** asset and **suffixes** every newer one. Example - a collided ticker `TKN`:

| lukkaAssetCode | Asset | Status |
|---|---|---|
| `TKN` | older asset holding the bare code | **Inactive / Contract Migrated** |
| `TKN01` (group primary) | current asset (multi-chain) | Active |
| `TKNA1C`, `TKN289`, ... | current asset (per chain) | Active |

So `get_asset_mappings({ lukkaAssetCode: "TKN" })` silently returns the **older inactive asset** (status Inactive / Contract Migrated, no price) - never the current one. **Never resolve a raw ticker through `lukkaAssetCode`.** Resolve through `entityAssetCode` (the street-ticker side of the mapping).

> `whitepaperCode` / `commonStreetCode` are NOT filterable on `get_asset_mappings` in this hosted environment - they live only in `get_asset_by_id` -> `nameDetails[]` and are used to **confirm** a candidate after you have its LID, not to search.

## Workflow: Resolve Street Ticker to Lukka Prime Price

### Step 1: Translate known aliases (fast path for majors)

A handful of majors have a clean, unique canonical code. If the input is in this map, the alias IS a unique `lukkaAssetCode` and you may skip straight to Step 3 with it:

| Street ticker | Lukka code | Notes |
|-------------|------------|-------|
| BTC | XBT | ISO 4217 |
| SOL | SOLN | NOT "SOL" - a name search on "SOL" returns unrelated ERC-20 tokens sharing the ticker |
| GALA | GALAT3 | Contract migrated from GALAG |
| MATIC | MATIC (watch for POL) | Polygon migration possible |
| ETH, ADA, DOGE, USDT, USDC | same | Straightforward |

**Canonical Lukka Asset IDs (LIDs) for majors**: XBT=LA6EV2NKQ95, ETH=LA8VRAGEMT1, SOLN=LA1DB6PX4M7.

If the input is **not** in this map, treat it as a raw street ticker and go to Step 2.

### Step 2: Find candidates by street ticker

```
refdata___get_asset_mappings({
  entityAssetCode: "{ticker}",
  mappingStatus: "Active",
  limit: 200
})
```

`entityAssetCode` is the exchange/blockchain-side ticker - this is the only filterable street-ticker field. Collect the **distinct `lukkaAssetId` values** from the rows (one real asset spans many mapping rows - e.g. a multi-chain fund can have 10+ chain mappings).

(For an aliased major from Step 1, you may instead query `lukkaAssetCode: "{alias}"` directly - the alias is unique so no collision risk.)

### Step 3: Validate 

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: briefing
description: "Daily macro market overview with top assets, prices, volume, and sentiment"
---

## OpenAI connection notes

Tool identifiers below are raw operation names. The host may add a namespace;
use the matching advertised Global MCP tool. Resolve `<resolved-package-root>`
to this plugin's installed directory before using paths. Workflow names identify
packaged skills; they are not literal Claude slash commands.

Original procedure tool scope: `pricing___get_candles`, `pricing___get_latest_market_caps`, `pricing___get_latest_prices`, `news___getDailySummaries`, `prediction-markets___GetMarketRecap`, `prediction-markets___GetPredictionMarkets`.

# briefing workflow

> See [CONNECTORS.md](../../CONNECTORS.md) for tool details.

## Usage

briefing workflow

## Flow

0. **Read preferences (optional)**: if `<resolved-package-root>/settings/preferences.local.md` exists, read `Top N` and use it as the market-cap limit in steps 1-2 below. Rules:
   - No file, or key absent -> default **20**.
   - Non-numeric / unparseable value (e.g. `abc`) -> fall back to **20** (do not error).
   - Value above **50** -> clamp to **50** (the documented max) and note the clamp to the user.
   - `Top N` is the only preference key currently consumed; other keys in the example file are placeholders (not yet wired).

1. **Top N by market cap (current)** (always pass `order:"DESC"` explicitly):
   `pricing___get_latest_market_caps({ limit: {TopN}, order: "DESC" })` 
2. **Top N by market cap (24h ago)** - for cap delta:
   `pricing___get_latest_market_caps({ limit: {TopN}, order: "DESC", asOf: "{24h_ago_ISO}" })` 
3. **Current prices** (realtime): `pricing___get_latest_prices({ sourceId: 2000, pairCodes: top20_pairs })`  (sourceId 2000 = Lukka Prime Intraday)
4. **24h candles for top 5**: Per asset, `pricing___get_candles({ sourceId: 4002, pairCode, interval: 86400000, from: 24h_ago, to: now })`  (sourceId 4002 = Coinbase Pro, schema default)
   - Extract `openPrice`/`closePrice` for 24h change: `(close - open) / open * 100`
   - Extract `volume` for 24h volume
5. **Prediction market sentiment**: `prediction-markets___GetPredictionMarkets({ search: "bitcoin", sort_by: "total_volume_usd_1hr", sort_dir: "desc", limit: "5" })` 
6. **Market recap**: `prediction-markets___GetMarketRecap({})` 
7. **News Digest** (today's or most recent): `news___getDailySummaries({ limit: 1 })` 
   - If today is Monday, summary covers Saturday + Sunday (weekend digest).
   - Summaries available from 2026-04-08.

> Implied rates and volatility surface are available via `Lukka-Analytics` server. Optionally include if user requests rate/vol context.

## Output

### Market Briefing - {date}

**Top 5 by Market Cap** (full analytics)

| # | Asset | Price (USD) | 24h Change | 24h Volume | Market Cap | Cap Change 24h |
|---|-------|------------|------------|------------|------------|----------------|
| 1 | XBT | $XX,XXX | +X.X% | $X.XB | $X.XT | +X.X% |

- 24h Change = from candles `(closePrice - openPrice) / openPrice * 100`
- 24h Volume = from candles `volume` field
- Cap Change 24h = `(current_cap - cap_24h_ago) / cap_24h_ago * 100` (from step 1 vs step 2)

**Rank 6-20** (snapshot only - no candle data fetched for these)

| # | Asset | Price (USD) | Market Cap |
|---|-------|------------|------------|
| 6 | ... | $X,XXX | $X.XB |

**24h Highlights** (derived from top 5 candles only)
- Top gainer: {asset} (+X.X%)
- Top loser: {asset} (-X.X%)
- Volume leader: {asset} ($X.XB)

**Market Sentiment** (Prediction Markets)
- {event}: {probability}%
  - Probability = `yes.latest_price * 100` for binary markets

**News Digest**
- Overall sentiment: {overallSentiment}
- Articles today: {articleCount}
- Top headlines: {notableEvents[0..2] titles}
- Key themes: {keyThemes[0..2]}

## Pagination

`get_latest_market_caps` returns up to `limit` rows per call. If you need beyond top 100, use cursor-based pagination: pass `cursor` from previous response's `nextCursor` field. For

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: compliance-patterns
description: "AML and VASP due diligence workflow patterns for digital asset compliance against the Lukka hosted MCP surface. Use when user asks about: AML risk, OFAC, VASP, due diligence, compliance review, address investigation, exchange compliance, or regulatory status."
---

## OpenAI connection notes

Tool identifiers below are raw operation names. The host may add a namespace;
use the matching advertised Global MCP tool. Resolve `<resolved-package-root>`
to this plugin's installed directory before using paths. Workflow names identify
packaged skills; they are not literal Claude slash commands.

# Compliance Patterns

**STANDALONE**: This skill provides AML/VASP compliance workflow patterns, risk categories, and exchange code conventions useful for structuring compliance reviews. **SUPERCHARGED**: When Lukka-AML, Lukka-RefData, and Lukka-UDA MCP servers are connected, it orchestrates live AML scoring, counterparty graph analysis, and VASP due diligence.

Workflow patterns against the hosted Lukka MCP servers: **Lukka-AML**, **Lukka-RefData**, **Lukka-UDA**. All tool names use the production wire format `<group>___<tool>`.

> The hosted surface provides report generation (scoring, standard, enhanced, simplified) plus UDA on-chain data via Lukka-UDA.

## Pattern 1: Address Investigation (default)

```
1. UDA___get_address_balance({ blockchain: "eth", address })         -> current holdings
2. UDA___get_address_assets({ blockchain: "eth", address })          -> token coverage
3. UDA___get_address_transactions({ blockchain, address,
                                                    verbose:"1", limit: 100,
                                                    get_newest:"1" })                -> recent activity preview
4. AML___generateAmlScoringReport({ address, address_type: "ETH" })    -> light risk assessment
```

**Blockchain case**: Lukka-UDA uses lowercase (`eth`), Lukka-AML uses UPPERCASE (`ETH`).

## Pattern 2: Deep AML Review (on request)

Always pipe Standard / Enhanced reports through the `large-data-processing` skill's `process_aml_report.py` - raw responses are 300-500 KB+ and overflow context.

```
1. cp "<resolved-package-root>/skills/large-data-processing/references/process_aml_report.py" /tmp/
2. AML___generateAmlStandardReport({ address, address_type: "ETH" })   -> 325 KB report
3. Save raw JSON to /tmp/aml_report.json
4. python3 /tmp/process_aml_report.py /tmp/aml_report.json                            -> 2-3 KB summary
5. (optional) AML___generateAmlEnhancedReport                         -> deepest detail (same pipe)
```

## Pattern 3: Counterparty Exposure

For counterparty exposure, use `generateAmlStandardReport` / `generateAmlEnhancedReport`
(pipe through `process_aml_report.py`) - their payloads carry counterparty reasons with USD
values. For raw address assets, use `UDA___get_address_assets`.

## Pattern 4: VASP / Exchange Due Diligence

Use canonical Lukka exchange codes. **Never** `COINBASE` - it is not a canonical code and does not resolve to the exchange. Use `CPRO` (Coinbase Pro), `CBSE` (Coinbase parent), `CPRM` (Coinbase Prime), `KRAK` (Kraken), `BINA` (Binance), `GMNI` (Gemini), etc.

```
# Build exchange profiles from get_entity_by_code + list_vasps + get_asset_mappings.
1. refdata___get_entity_by_code({ code: "CPRO" })                 -> basic entity info
2. refdata___list_vasps({ mappingStatus: "Active" })              -> VASP data, licenses
   # filter client-side for lukkaEntityCode == CPRO (entityCode filter not reliably honored)
3. refdata___get_asset_mappings({ entityCode: "CPRO",
                                                       mappingStatus: "Active" })    -> listed assets + supportedFunctionList
4. Per row: refdata___get_asset_by_id({ assetLid: "{lukkaAssetId}" })
             -> inspect assetDetails.potentiallySuspicious / potentiallyMemeCoin
```

To find suspicious listings, iterate `get_asset_mappings` results and inspect `potentiallySuspicious

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: compliance-scanner
description: "AML and VASP compliance agent. Runs AML report generation, counterparty flow lookups, and exchange due diligence against the hosted Lukka-AML and Lukka-RefData MCP servers."
---

## OpenAI connection notes

Tool identifiers below are raw operation names. The host may add a namespace;
use the matching advertised Global MCP tool. Resolve `<resolved-package-root>`
to this plugin's installed directory before using paths. Workflow names identify
packaged skills; they are not literal Claude slash commands.

Original procedure tool scope: `AML___generateAmlScoringReport`, `AML___generateAmlSimplifiedReport`, `AML___generateAmlStandardReport`, `AML___generateAmlEnhancedReport`, `refdata___list_vasps`, `refdata___get_entity_by_code`, `news___getNews`.

You are a compliance scanning agent working against the Lukka hosted MCP surface.

## Tool Surface (production-only)

The hosted Lukka-AML server exposes report generation only.

- Reports: `generateAmlScoringReport` (any chain), `generateAmlStandardReport` / `generateAmlEnhancedReport` (30 chains), `generateAmlSimplifiedReport` (80 chains)
- Report tier availability: SCORING is available on all supported chains. STANDARD/ENHANCED available on: `ADA, AVAX, BCH, BSV, BTC, CC, DASH, DOGE, DOT, DOT_AH, ETC, ETH, FIL, ICP, IOTA_MAINNET, IOTAEVM, LTC, MATIC, NEAR, NEO, RSK, SOL, TRX, VET, XDAI, XLM, XRP, XTZ, ZEC, ZKS`. SIMPLIFIED available on: `ALGO, APT, ARBITRUM, ATOM, AZERO, BASE, BNB, BSC, CANTO, CELO, CHZ, CKB, COTI, CRO, CRONOS, DCR, DGB, DOGECHAIN, ECS, EGLD, EOS, ETHW, EVMOS, FET, FLOW, FTM, FUSE, GLMR, GRAM, HASH, HBAR, HT, IMX, IOTA, IOTX, KAVA, KCS, KDA, KLAY, KSM, LINEA, LSK, LUNA, LUNC, MINA, MNT, MOVR, NEO3, ONE, ONT, OP, PALM, PLS, QTUM, REEF, RON, ROOT, RUNE, SDN, SEI, SMR, STX, SUI, TAO, THETA, TLOS, TON, VIC, WAN, WAVES, WAX, XDC, XEC, XEM, XNO, XVG, XYM, ZEN, ZIL, ZKEVM`. Default to `generateAmlScoringReport`.
- For counterparty exposure data, use `generateAmlStandardReport` (pipe through processor). For address assets, use `UDA___get_address_assets`.

## Algorithm

### Address Checks (wallet-scan)

#### Phase 1: Light AML (default)

`AML___generateAmlScoringReport({ address: "{address}", address_type: "{UC}" })`

IMPORTANT: Lukka-AML report tools take `address_type` (NOT `blockchain`) as UPPERCASE values (`ETH`, `BTC`, `SOL`, `TRX`). `address` must be the RAW address only - extract the bare hex/base58 string from the user's request; a phrase like `0x... on Ethereum` in the `address` field returns HTTP 422 (the hosted API does not parse natural language).

Returned payload fits in context. Extract: risk score, letter grade, top factors.

#### Phase 2 (optional, on explicit user request): Full / Enhanced AML

NEVER call `generateAmlStandardReport` or `generateAmlEnhancedReport` without the processor pipeline from the `large-data-processing` skill - their payloads (300 KB - 500 KB+) overflow context.

Workflow:
1. `cp "<resolved-package-root>/skills/large-data-processing/references/process_aml_report.py" /tmp/`
2. Call report tool, save raw JSON to `/tmp/aml_report.json`
3. `python3 /tmp/process_aml_report.py /tmp/aml_report.json`
4. Read the ~2-3 KB summary back into context

#### Phase 3 (optional): counterparty exposure

For counterparty exposure data, use `generateAmlStandardReport` / `generateAmlEnhancedReport` (pipe through processor). For address assets, use `UDA___get_address_assets`.

### Exchange Checks (exchange-diligence)

Use canonical Lukka exchange codes. Never `COINBASE` - use `CPRO` (Coinbase Pro), `CBSE` (Coinbase parent), or `CPRM` (Coinbase Prime).

#### Phase 1: Parallel Entity Lookups

Run simultaneously:
1. `refdata___get_entity_by_code({ code: "{code}" })` - basic info
2. `refdata___list_vasps({ limit: 100 })` - VASP data (VASPs are NOT filterable by `entityCode` - it only bridges to mappings; filter client-side for `lukkaEntityCode` == code, paginate via `offset` if needed)

Build exchange profiles from `get

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: deriv-spot-compare
description: "Derivatives vs spot comparison (basis, VWAP, derivative trade prints)"
---

## OpenAI connection notes

Tool identifiers below are raw operation names. The host may add a namespace;
use the matching advertised Global MCP tool. Resolve `<resolved-package-root>`
to this plugin's installed directory before using paths. Workflow names identify
packaged skills; they are not literal Claude slash commands.

Original procedure tool scope: `pricing___get_derivative_source_details`, `pricing___get_historical_derivative_trades`, `pricing___get_latest_derivative_trades`, `pricing___get_latest_prices`, `pricing___get_vwap`, `pricing___list_sources_by_product`, `analytics___getImpliedRates`, `analytics___getImpliedVolatilitySurface`.

# deriv-spot-compare workflow

> See [CONNECTORS.md](../../CONNECTORS.md) for tool details.

## Usage

deriv-spot-compare workflow <user input>

## Scope

Implied rates, volatility surface, and OTC FX rates are available via `Lukka-Analytics` server (`analytics___*`).

Lukka Reference Rate (sourceId 5001) and Median Reference Rate (5002) may return 404 - use the fallback below. Fallback: `get_latest_prices({ sourceId: 1000 })` (EOD) or `({ sourceId: 2000 })` (Intraday).

## Flow

1. **Spot price**: `pricing___get_latest_prices({ sourceId: 2000, pairCodes: "<user input>" })`  (sourceId 2000 = Lukka Prime Intraday)
2. **VWAP (24h)**: `pricing___get_vwap({ pairCode: "<user input>", sourceIds: "<comma_top_exchanges>", from: 24h_ago, to: now })` 
3. **List derivative sources**: `pricing___list_sources_by_product({ productType: "trades" })` , then pick Deribit (typically 4022). NOTE param is `productType` with enum `prices|trades|candles|mvwaps|market-caps|variances` - there is NO `derivatives` value and NO `product` param.
4. **DISCOVER the derivative pricing code (never construct it)**:
   `pricing___get_derivative_source_details({ sourceId: "{deribit_id}", productType: "trades" })` 
   - **This response is ~1.5 MB (3800+ pairs). Pipe through a processor (see `large-data-processing`) - do NOT load into context.** Grep the `pairs[]` for the target: match `underlyingAssetCode` == the Lukka canonical of the pair base (e.g. XBT) AND `derivativePricingCode` contains `PERPETUAL`.
   - **CRITICAL - the code you need is `derivativePricingCode`, and it uses the EXCHANGE-NATIVE ticker + `.DERI` suffix, NOT the Lukka canonical.** Do NOT build it from the Lukka code. Native != canonical for many assets: XBT->`BTC`, SOLN->`SOL`, XLT->`LTC`, PDT->`DOT`, HYPE22->`HYPE`, UNISW->`UNI`, TRUMPOFF->`TRUMP`. Example results: `BTC-PERPETUAL.DERI` (USD-settled) and `BTC_USDC-PERPETUAL.DERI` (USDC-settled) both have `underlyingAssetCode=XBT`. Perpetual pattern is `{NATIVE}-PERPETUAL.DERI` or `{NATIVE}_USDC-PERPETUAL.DERI`. Options carry strike/expiry: `{NATIVE}_USDC-9JUL26-89-C.DERI`.
5. **Derivative trades**: `pricing___get_latest_derivative_trades({ sourceId: "{deribit_id}", lukkaDerivativeCode: "{derivativePricingCode from step 4}" })`  - pass the discovered code verbatim (e.g. `BTC-PERPETUAL.DERI`), never a code you assembled from the Lukka canonical.
6. **Historical context**: `pricing___get_historical_derivative_trades({ sourceId: "{deribit_id}", lukkaDerivativeCode: "{discovered code}", from: 1h_ago, to: now, limit: 100 })` 
   - **WARNING: `limit` is enforced per time-page, not per-record - a 1h window still returns 300 KB+ (hundreds of trades). Use the SMALLEST window you need and pipe the response through a processor. A 24h window will overflow context - never request it raw.**
   - 24h volume = sum of `size` field across all returned trades (compute in the processor)
   - 24h trade count = number of rows returned
7. **Implied forward curve**: `analytics___getImpliedRates({ pairCode: "<user input>", lukkaEntityCode: "LUKKA", timeFrom: "24h_ago", timeTo: "now", curveType: "INST_FWD", modelType: "NSS", source: "FUTURES", rateType: "BASIS" })` 
   - Data available from T-1. Returns tenor 

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: digital-asset-market-knowledge
description: "Domain knowledge for digital asset market data queries. Loaded as base context for all Lukka tools. Covers pair formats, source IDs, interval conventions, blockchain symbols, top asset codes, and response modes."
---

## OpenAI connection notes

Tool identifiers below are raw operation names. The host may add a namespace;
use the matching advertised Global MCP tool. Resolve `<resolved-package-root>`
to this plugin's installed directory before using paths. Workflow names identify
packaged skills; they are not literal Claude slash commands.

# Digital Asset Market Knowledge

**STANDALONE**: This skill provides digital asset market conventions (pair formats, source IDs, interval units, blockchain symbols, asset codes) useful for any digital asset data work. **SUPERCHARGED**: When Lukka MCP servers are connected, these conventions prevent common API errors (wrong intervals, wrong pair codes, wrong blockchain case).

Base domain knowledge for working with Lukka's digital asset data infrastructure.

## Pair Format

Lukka uses canonical asset codes, NOT white paper codes:
- Bitcoin: `XBT` (not BTC) - LID `LA6EV2NKQ95`
- Ethereum: `ETH` is canonical (LID `LA8VRAGEMT1`, name "Ether") - `XET` is NOT the canonical code
- Solana: `SOLN` (not `SOL` - `SOL` is an unrelated ERC-20 token sharing the ticker)
- Pairs: `XBT-USD`, `ETH-USD`, `SOLN-USD`, `ADA-USD`

## Intervals (MILLISECONDS)

| Duration | Milliseconds | Common mistake |
|----------|-------------|----------------|
| 1 minute | 60000 | 60 (seconds) |
| 1 hour | 3600000 | 3600 (seconds) |
| 1 day | 86400000 | 86400 (seconds) |

**`get_historical_prices`**: 1min (60000), 1hr (3600000), 1day (86400000) all work.
**`get_candles`**: 1min, 1hr (3600000), 1day. Use candles when you need OHLCV instead of a single price.

## Source IDs

| ID | Name | Use case |
|----|------|----------|
| 1000 | Lukka Prime EOD | End-of-day prices, market cap |
| 2000 | Intraday | Real-time/intraday prices |
| 2100 | Lukka Prime Global Intraday | Intraday candles |
| 3000 | Hourly Prices | Hourly aggregated prices (NOT the reference rate) |
| 5001 | Lukka Reference Rate | Reference Rate (may return 404 - use the fallback below) |
| 5002 | Lukka Median Reference Rate | Median Reference Rate |
| 4001-4999 | Exchanges | Per-exchange data |

Discover exchange sourceIds: `list_pricing_sources({})`

## Blockchain Symbols

| Context | Format | Examples |
|---------|--------|----------|
| Lukka-UDA (on-chain) | lowercase | `btc`, `eth`, `sol`, `trx` |
| Lukka-AML (compliance) | UPPERCASE | `BTC`, `ETH`, `SOL`, `TRX` |

## Top Assets by Lukka Code

| Lukka Code | Asset | White Paper Code |
|------------|-------|------------------|
| XBT | Bitcoin | BTC |
| ETH | Ethereum | ETH |
| SOLN | Solana | SOL |
| ADA | Cardano | ADA |
| XRP | XRP | XRP |
| BNB | BNB | BNB |
| PDT | Polkadot | DOT |
| AVAX | Avalanche | AVAX |
| MATIC | Polygon | MATIC |
| LINK | Chainlink | LINK |
| UNISW | Uniswap | UNI |

Canonical codes: Ethereum = `ETH` (LID LA8VRAGEMT1), Polkadot = `PDT` (LA8FGEG06T7), Uniswap = `UNISW` (LA79U4XBU94). The entity/whitepaper ticker (DOT, UNI) resolves to these via `get_asset_mappings(entityAssetCode:...)`.

**TRAP: "SOL" in Lukka is NOT Solana** -- Lukka code for Solana is `SOLN`. Pair: `SOLN-USD`.
To resolve on the hosted surface, use `get_asset_mappings({ entityAssetCode: "SOL", mappingStatus: "Active" })` and collapse LID groups - the real Solana asset dominates by mapping count. Name lookups resolve through RefData mappings.

## Response Modes

| Mode | Parameter | Returns |
|------|-----------|---------|
| Summary (default) | none | Aggregated stats + samples |
| Detailed | `detailed: true` | Paginated raw data (100/page) |
| Export | `export: true` | CSV content |

## Pagination

- **Lukka-Pricing**: Cursor-based (`cursor` + `hasMore`) on some endpoints; `get_latest_market_caps` returns `{data:[...]}` with no cursor
- **Lukka-RefData**: Offset-ba

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: exchange-diligence
description: "Exchange compliance profile with jurisdiction, VASP status, and services"
---

## OpenAI connection notes

Tool identifiers below are raw operation names. The host may add a namespace;
use the matching advertised Global MCP tool. Resolve `<resolved-package-root>`
to this plugin's installed directory before using paths. Workflow names identify
packaged skills; they are not literal Claude slash commands.

Original procedure tool scope: `refdata___get_asset_by_id`, `refdata___get_asset_mappings`, `refdata___get_entity_by_code`, `refdata___list_vasps`.

# exchange-diligence workflow

> See [CONNECTORS.md](../../CONNECTORS.md) for tool details.

## Usage

exchange-diligence workflow <user input>

### Canonical codes (IMPORTANT)

Do **not** pass free-form names. `COINBASE` is not a canonical code and does not resolve to the exchange. Use canonical Lukka codes:

| Venue | Code |
|-------|------|
| Coinbase Pro | `CPRO` |
| Coinbase (parent) | `CBSE` |
| Coinbase Prime | `CPRM` |
| Kraken | `KRAK` |
| Binance | `BINA` |
| Binance US | `BIUS` |
| Gemini | `GMNI` |
| Bitstamp | `BSTP` |
| OKX | `OKX` |

If the user types a free-form name, translate it to the code above before calling.

## Flow

> **NOTE:** This command builds the exchange profile from entity + VASP + asset-mapping data.

1. **Entity info**: `refdata___get_entity_by_code({ code: "<user input>" })` 
2. **VASP data**: `refdata___list_vasps({ limit: 100 })`  -> find the row where `lukkaEntityCode` == `<user input>`. VASPs are NOT filterable by `entityCode` (it only bridges to mappings, not VASPs) - filter client-side on `lukkaEntityCode`; paginate via `offset` if not on the first page.
3. **Asset listings + services**: `refdata___get_asset_mappings({ entityCode: "<user input>", mappingStatus: "Active", limit: 100 })` 
   - Count active listings
   - Aggregate `supportedFunctionList` across all mappings: for each flag (`tradingSupported`, `custodySupported`, `lendingSupported`, `savingsSupported`, `stakingSupported`), set to "yes" if *any* mapping has it `true`

### Optional: `--flag-risky` mode (expensive - user must explicitly request)

4. **Flag risky assets**: iterate mappings from step 3 and per row call `refdata___get_asset_by_id({ assetLid: "{lukkaAssetId}" })`  to inspect `assetDetails.potentiallySuspicious` / `potentiallyMemeCoin` flags.
   - Do NOT run by default (100+ calls for large exchanges)

## Output

### Exchange Due Diligence: {exchange_name}

**Entity Profile**
- Code: {entityCode}
- Type: {entityType}
- Country: {country}
- Status: {status}

**Regulatory**
- Jurisdiction: {jurisdiction} (primary; subsidiaries not enumerated)
- AML/KYC Process: {amlKycProcess}
- VASP Registration: {status from list_vasps} or "N/A" if no VASP registration found
- Note: Regulatory registrations per jurisdiction are provided via `list_vasps` (match `lukkaEntityCode` client-side).

**Services** (aggregated from `supportedFunctionList` across all active mappings)
- Spot trading: {yes/no}
- Derivatives: {yes/no}
- Lending: {yes/no}
- Staking: {yes/no}
- Custody: {yes/no}
- Savings: {yes/no}
- Note: based on supported asset function flags aggregated across listings

**Asset Coverage**
- Active listings: {count} (from step 3 `get_asset_mappings`)

> Suspicious/meme coin counts are not resolved by default (requires N individual asset lookups). Use `--flag-risky` to iterate all mappings and check `potentiallySuspicious` / `potentiallyMemeCoin` flags.

**Risk Flags**
- {flag descriptions from entity/VASP data}

View saved version →

---
name: health
description: "Ping each hosted MCP server with one cheap tool, report auth, dispatch, and known drift."
---

## OpenAI connection notes

Tool identifiers below are raw operation names. The host may add a namespace;
use the matching advertised Global MCP tool. Resolve `<resolved-package-root>`
to this plugin's installed directory before using paths. Workflow names identify
packaged skills; they are not literal Claude slash commands.

Original procedure tool scope: `AML___generateAmlScoringReport`, `UDA___Get_newest_block_blockheight`, `pricing___get_latest_index_prices`, `pricing___list_pricing_sources`, `refdata___get_asset_mappings`, `refdata___get_entity_by_code`, `analytics___getImpliedRates`, `news___getDailySummaries`, `prediction-markets___GetExchanges`.

# health workflow

> See [CONNECTORS.md](../../CONNECTORS.md) for server details.

## Usage

health workflow

## Purpose

Smoke-test the seven hosted MCP servers and flag known drift conditions in under 10 seconds. Use this:
- Right after installing this plugin in the OpenAI host + OAuth authentication, to confirm every server is reachable
- Before starting a long session, to catch availability changes early
- When a downstream command fails mysteriously, to isolate server-level issues from flow-level issues

## Flow (parallel where possible)

### Phase A - Server reachability (7 smoke calls, parallel)

Run the cheapest dispatchable tool per server. Every call should return a shaped payload without ValidationException.

1. `pricing___list_pricing_sources({})` 
2. `refdata___get_asset_mappings({ lukkaAssetCode: "XBT", mappingStatus: "Active", limit: 1 })` 
3. `AML___generateAmlScoringReport({ address: "0x13203aB9C9f054fe8B4671bC0EEC3ab26D2f3477", address_type: "ETH" })` 
4. `UDA___Get_newest_block_blockheight({ blockchain: "eth" })` 
5. `prediction-markets___GetExchanges({ limit: "1", offset: "0", primary_location: "", vasp_classification: "", vast_type: "" })` 
6. `news___getDailySummaries({ limit: 1 })` 
7. `analytics___getImpliedRates({ pairCode: "XBT-USD", lukkaEntityCode: "LUKKA", curveType: "INST_FWD", modelType: "NSS", source: "FUTURES", rateType: "BASIS", timeRange: "1D", timeTo: "{now}", limit: 1 })`  - note `timeRange` MUST be anchored with `timeTo` (or `timeFrom`); an un-anchored `timeRange` returns HTTP 400 by design.

Record per server: dispatched (yes/no), response shape ok (yes/no), latency.

### Phase B - Known-drift checks (3 targeted calls, parallel)

8. `refdata___get_entity_by_code({ code: "COINBASE" })`  - `COINBASE` is NOT a canonical code and MUST NOT resolve to an Exchange record; the canonical Coinbase code is `CPRO`. Assert the result is not type `Exchange` (routing correctness check). If it now returns a canonical exchange record, flag as a data change and prompt the user to re-validate canonical codes.
9. `refdata___get_entity_by_code({ code: "CPRO" })`  - MUST return Coinbase Pro (type `Exchange`, jurisdiction `USA`, amlKycProcess `Y`).
10. `pricing___get_latest_index_prices({ sourceId: 3000, pairCodes: "XBT-USD" })`  - index-price availability probe (sourceId 3000 = Hourly; Reference Rate = 5001/5002, requires access). Two acceptable outcomes: (a) payload -> access enabled; (b) 404 -> use EOD/Intraday path. Any other error (401/403/5xx) is a drift signal.

### Phase C - Processor sanity (local, no MCP)

11. Run `process_aml_report.py` against the bundled synthetic fixture `<resolved-package-root>/tests/fixtures/aml/scoring_sample.raw` and confirm output > 100 bytes and contains `cscore`. This verifies the processor works without depending on external state.

## Output

```
Lukka Plugin Health - {date} {time}

Server availability (Phase A)
| # | Server | Tool | Dispatched | Shape OK | Notes |
|---|--------|------|-----------|----------|-------|
| 1 | Lukka-Pricing | list_pricing_sources | YES / NO | YES / NO | {count} active sources |
| 2 | Lukka-RefData | get_asset_mappings(XBT) | YES / NO | YES / NO | lukkaAssetId = {lid} |

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: investigate-price
description: "Deep price investigation at specific timestamp with exchange breakdown"
---

## OpenAI connection notes

Tool identifiers below are raw operation names. The host may add a namespace;
use the matching advertised Global MCP tool. Resolve `<resolved-package-root>`
to this plugin's installed directory before using paths. Workflow names identify
packaged skills; they are not literal Claude slash commands.

Original procedure tool scope: `UDA___get_block`, `pricing___get_candles`, `pricing___get_historical_prices`, `pricing___get_latest_prices`, `pricing___get_market_depth`, `pricing___get_market_variances`, `pricing___get_order_book_snapshot`, `pricing___list_pricing_sources`.

# investigate-price workflow

> See [CONNECTORS.md](../../CONNECTORS.md) for tool details.

## Usage

investigate-price workflow <user input>

Parse <user input> for pair code and optional timestamp (default: latest).

## Flow

1. **Discover sources**: `pricing___list_pricing_sources({})` 
2. **Price at time**: `pricing___get_latest_prices({ sourceId: 1000, pairCodes: "{pair}", asOf: "{timestamp}" })` or `pricing___get_historical_prices({ pairCode: "{pair}", from, to, interval: 60000 })`  (sourceId 1000 = Lukka Prime EOD)
   - Note: price returned is the latest available *on or before* `asOf`. For exact minute-precision use `get_historical_prices({ interval: 60000 })`.
3. **Exchange variance**: `pricing___get_market_variances({ pairCode: "{pair}", from: "{ts-1h}", to: "{ts}" })` 
   - Provides per-exchange deviation from composite
4. **Candles per exchange**: For top exchanges, `pricing___get_candles({ pairCode: "{pair}", sourceId: {id}, from: "{ts-2h}", to: "{ts}", interval: 3600000 })` 
   - Provides per-exchange volume
   - **Merge step 3 + step 4** on `pairCode + sourceId`: variance fills Deviation column, candle fills Volume column
5. **Order book snapshot**: `pricing___get_order_book_snapshot({ sourceIds: "{single_sourceId}", pairCodes: "{pair}", asOf: "{timestamp}" })` 
   - Top exchange sourceId (e.g. 4002 Coinbase Pro or 4005 Binance), one at a time
6. **Market depth per top exchange**: `pricing___get_market_depth({ sourceIds: "{single_sourceId}", baseAssetCodes: "{base}", counterAssetCodes: "USD" })` 
   - **CRITICAL**: one sourceId per call + base/counter filters (avoids 6.8 MB full exchange dump)

## Output

### Price Investigation: {pair} at {timestamp}

**Lukka Prime Price**: ${price}

**Exchange Contributions**
| Exchange | Price | Share % | Volume | Deviation |
|----------|-------|---------|--------|-----------|

- Share % = `volume_exchange / total_volume_across_exchanges * 100` (computed from candles volume)

**Hourly Candles (leading 2h)**
| Time | Exchange | Open | High | Low | Close | Volume |
|------|----------|------|------|-----|-------|--------|

**Order Book Snapshot**
- Best Bid: ${bid} ({bid_size})
- Best Ask: ${ask} ({ask_size})
- Spread: ${spread} ({spread_bps} bps)

**Analysis**: {Describe deviation pattern, liquidity concentration, any outliers across exchanges}

> **Block-level analysis**: if the user wants on-chain context around the timestamp, use `UDA___get_block` and the `large-data-processing` skill's `process_block.py`.

View saved version →

---
name: large-data-processing
description: "Process large MCP responses (>100KB) locally instead of loading into context. Covers market depth (6.8MB+), bulk address transactions (150KB+), block batch analysis (675KB+), and AML standard/enhanced reports (300-500KB+). Deploy Python processors to /tmp, pipe raw JSON through them, read concise output (~2-3KB) back into context."
---

## OpenAI connection notes

Tool identifiers below are raw operation names. The host may add a namespace;
use the matching advertised Global MCP tool. Resolve `<resolved-package-root>`
to this plugin's installed directory before using paths. Workflow names identify
packaged skills; they are not literal Claude slash commands.

# Large Data Processing

**STANDALONE**: This skill provides Python processor scripts (stdlib only) that summarize large JSON files locally -- market depth, transactions, blocks, AML reports. Works on any JSON data matching the expected schemas. **SUPERCHARGED**: When Lukka MCP servers are connected, these processors prevent context overflow from oversized API responses (6.8MB market depth, 500KB AML reports).

**Problem**: Some MCP responses are too large for context (6.8MB market depth, 1000 decoded txs).
**Solution**: Save raw JSON to /tmp, process locally with Python scripts, read summary.

## When to Use

| Endpoint | Trigger | Size |
|---|---|---|
| `get_market_depth` without pair filter | Full exchange dump | 6.8MB, 1500+ pairs |
| `get_order_book_snapshot` (single pair) | L2 book snapshot | ~3MB EVEN WITH pair filter - always pipe |
| `get_derivative_source_details` | Derivative pair catalog | ~1.5MB (3800+ pairs) - grep for the target code, never load raw |
| `get_historical_derivative_trades` | Derivative trade prints | 300KB+ per 1h; `limit` is per-time-page NOT per-record, so it does NOT cap size. Use smallest window + pipe |
| `getImpliedRatesOtcFx` | OTC FX term structure | 400KB+; `limit` caps time-pages not rows (all tenors x all hours return). Narrow window + pipe |
| `get_asset_by_id` (hosted) | Full asset detail | ~54KB raw (hosted has no summary mode) - fits context but trim if batching |
| `get_address_transactions` verbose, limit>100 | Bulk wallet analysis | 150KB+ |
| `get_block` + batch decode | Block-level forensics | 675KB+ (135 txs) |
| `generateAmlStandardReport` | Full AML report | 300-500KB (ALWAYS pipe) |
| `generateAmlEnhancedReport` | Deepest AML report | 500KB+ (ALWAYS pipe) |
| Any MCP response | Response feels truncated or huge | >50KB |

## Workflow

### Step 1: Detect large response risk

Before calling, check if the query will return bulk data:
- `get_market_depth` without `baseAssetCodes`/`counterAssetCodes` = 6.8MB
- `get_order_book_snapshot` = ~3MB even with a single pair filter
- `get_derivative_source_details` = ~1.5MB (grep for the pair, never load raw)
- `get_historical_derivative_trades` / `getImpliedRatesOtcFx` = 300-400KB+; `limit` does NOT cap total size (it pages by time), so shrink the from/to window
- `get_address_transactions` with `limit: 1000` + `verbose: "1"` = 150KB+
- Batch decoding >50 transactions = 250KB+

### Step 2: Deploy processor script

Copy the appropriate script from this skill's references to /tmp. When invoked as a plugin skill, use `<resolved-package-root>` to resolve the plugin install path:

```bash
# Market depth
cp "<resolved-package-root>/skills/large-data-processing/references/process_market_depth.py" /tmp/

# Transactions
cp "<resolved-package-root>/skills/large-data-processing/references/process_transactions.py" /tmp/

# Block data
cp "<resolved-package-root>/skills/large-data-processing/references/process_block.py" /tmp/

# AML standard/enhanced report
cp "<resolved-package-root>/skills/large-data-processing/references/process_aml_report.py" /tmp/
```

### Step 3: Call MCP and save raw output

Call the MCP tool with `format_response: false` or `detailed: true` where available.
Save the raw JSON response to /tmp:

```bash
# Example: save market dep

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 5 — file references are metadata, not package contents.

View saved version →

---
name: liquidity-scan
description: "Cross-exchange liquidity analysis with depth, spread, and VWAP"
---

## OpenAI connection notes

Tool identifiers below are raw operation names. The host may add a namespace;
use the matching advertised Global MCP tool. Resolve `<resolved-package-root>`
to this plugin's installed directory before using paths. Workflow names identify
packaged skills; they are not literal Claude slash commands.

Original procedure tool scope: `pricing___get_candles`, `pricing___get_market_depth`, `pricing___get_vwap`, `pricing___list_pricing_sources`, `refdata___get_pair_mappings`.

# liquidity-scan workflow

> See [CONNECTORS.md](../../CONNECTORS.md) for tool details.

## Usage

liquidity-scan workflow <user input>

## Flow

1. **Find exchanges for pair**: `refdata___get_pair_mappings({ lukkaPairCode: "{pair}", mappingStatus: "Active", limit: 1000 })`  -> list of entityCodes trading this pair
   - **Page fully** (a flagship pair has 80+ venues). If `next` is non-null, keep paging - a truncated page silently drops exchanges (e.g. wrongly concluding BINA does not trade XBT-USD when it does). Never treat an exchange as absent from a partial page.
2. **Map to sourceIds**: `pricing___list_pricing_sources({})`  -> filter ACTIVE sources; match entityCodes to sourceIds
3. **Parallel per exchange** (via the `market-data-gatherer` skill) - one call per sourceId:
   - `pricing___get_market_depth({ sourceIds: "{single_sourceId}", baseAssetCodes: "{base}", counterAssetCodes: "USD" })` 
     **CRITICAL**: base/counter filters mandatory (omitting returns 6.8 MB exchange dump). `sourceIds` accepts comma-separated values (one record per source) - you may batch several exchanges into one `get_market_depth` call to cut round-trips
   - `pricing___get_vwap({ pairCode: "{pair}", sourceIds: "{single_sourceId}", from: 24h_ago, to: now })` 
   - `pricing___get_candles({ pairCode: "{pair}", sourceId: "{single_sourceId}", interval: 86400000 })` 
4. **Aggregate and rank** by: total depth (bids_1 + asks_1 within 1% of mid), spread, volume

> **Full exchange depth** (optional - very large responses): use `large-data-processing` skill.
> `cp "<resolved-package-root>/skills/large-data-processing/references/process_market_depth.py" /tmp/`
> `python3 /tmp/process_market_depth.py /tmp/depth.json --top 20 --min-depth 50000`

## Output

### Liquidity Scan: {pair}

**Exchange Ranking** (by total depth within 1% of mid)

| # | Exchange | Bid Depth (1%) | Ask Depth (1%) | Bid Depth (5%) | Ask Depth (5%) | Spread (bps) | 24h Volume | VWAP |
|---|----------|---------------|---------------|---------------|---------------|--------------|------------|------|

- Bid/Ask Depth (1%) = `bids_1` / `asks_1` fields (liquidity within 1% of mid price)
- Bid/Ask Depth (5%) = `bids_5` / `asks_5` fields (liquidity within 5% of mid - for larger orders)

**Best Execution**
- Tightest spread: {exchange} ({bps} bps)
- Deepest book (1%): {exchange} (${depth})
- Highest volume: {exchange} (${vol})
- Recommended max order (1% slippage): ${size}
  - Formula: `min(bids_1 * mid_price, asks_1 * mid_price) * 0.8` (20% safety buffer)
- Recommended max order (5% slippage): ${size_5pct}
  - Formula: `min(bids_5 * mid_price, asks_5 * mid_price) * 0.8`

View saved version →

---
name: lukka-data-routing
description: "Route digital asset and blockchain data queries to the correct Lukka MCP tool across 7 hosted servers. Use when user asks about: digital asset prices, OHLCV candles, market cap, VWAP, order book depth, trading pairs, exchange sources, derivatives, implied rates, volatility surface, OTC FX, reference data, asset taxonomy, sector classifications, entity/custodian/VASP lookups, asset mappings, AML reports, wallet balances, on-chain transactions, block data, digital asset news, daily summaries, sentiment analysis, or prediction markets."
---

## OpenAI connection notes

Tool identifiers below are raw operation names. The host may add a namespace;
use the matching advertised Global MCP tool. Resolve `<resolved-package-root>`
to this plugin's installed directory before using paths. Workflow names identify
packaged skills; they are not literal Claude slash commands.

# Lukka Data Routing

**STANDALONE**: This skill provides routing knowledge and domain conventions that help answer digital asset data questions from general knowledge. **SUPERCHARGED**: When the 7 Lukka MCP servers are connected, this skill routes queries to the exact right tool with correct parameters, avoiding common API pitfalls.

Seven hosted MCP servers. Pick the right one on the first try.

## Tool Naming Convention

Production tools are exposed with the prefix `<group>___<tool>` (triple underscore before the tool name). Always call tools with the full wire name - use the matching operation advertised by the host.

| Server | Prefix |
|--------|--------|
| Lukka-Pricing | `pricing___*` |
| Lukka-RefData | `refdata___*` |
| Lukka-AML | `AML___*` |
| Lukka-UDA | `UDA___*` |
| Lukka-Analytics | `analytics___*` |
| Lukka-News | `news___*` |
| Lukka-Predmar | `prediction-markets___*` |

## Resolution and matching approach

- **Asset/pair/market resolution**: use direct filters on refdata tools (`list_assets`, `get_asset_mappings`, `get_pair_mappings`).
- **Derivative instrument matching**: use `get_derivative_source_details` with client-side string match.

## Route the Query

| User asks about | Server | Tool | Ref |
|---|---|---|---|
| Current price | Lukka-Pricing | `get_latest_prices` | [pricing](references/pricing.md) |
| Price history / charts | Lukka-Pricing | `get_historical_prices` or `get_candles` | [pricing](references/pricing.md) |
| Index / reference rate | Lukka-Pricing | `get_latest_index_prices` (Reference Rate access; standard path: sourceId 1000/2000) | [pricing](references/pricing.md) |
| Market cap / top N | Lukka-Pricing | `get_latest_market_caps` with `order:"DESC"` | [pricing](references/pricing.md) |
| VWAP | Lukka-Pricing | `get_vwap` | [pricing](references/pricing.md) |
| Order book / depth | Lukka-Pricing | `get_market_depth` | [pricing](references/pricing.md) |
| Order book snapshot | Lukka-Pricing | `get_order_book_snapshot` | [pricing](references/pricing.md) |
| Spot trades | Lukka-Pricing | `get_spot_trades` | [pricing](references/pricing.md) |
| Exchange sources | Lukka-Pricing | `list_pricing_sources` | [pricing](references/pricing.md) |
| Derivatives trades | Lukka-Pricing | `get_latest_derivative_trades` | [pricing](references/pricing.md) |
| Derivative source detail | Lukka-Pricing | `get_derivative_source_details` | [pricing](references/pricing.md) |
| What is asset X | Lukka-RefData | `get_asset_mappings(lukkaAssetCode)` -> `get_asset_by_id(assetLid)` | [refdata](references/refdata.md) |
| Find assets by trait | Lukka-RefData | `list_assets` + client-side filter | [refdata](references/refdata.md) |
| Exchange mappings | Lukka-RefData | `get_asset_mappings` | [refdata](references/refdata.md) |
| Sectors / taxonomy | Lukka-RefData | `get_sectors` | [refdata](references/refdata.md) |
| LCAS quality scores | Lukka-RefData | `get_core_asset_scores` | [refdata](references/refdata.md) |
| Entities / exchanges | Lukka-RefData | `get_entity_by_code` / `list_entities` | [refdata](references/refdata.m

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 8 — file references are metadata, not package contents.

View saved version →

---
name: market-data-gatherer
description: "Parallel exchange data collection agent for liquidity, pricing, and analytics. Queries market depth, VWAP, candles, spot trades, implied rates, and volatility surface across multiple exchanges simultaneously."
---

## OpenAI connection notes

Tool identifiers below are raw operation names. The host may add a namespace;
use the matching advertised Global MCP tool. Resolve `<resolved-package-root>`
to this plugin's installed directory before using paths. Workflow names identify
packaged skills; they are not literal Claude slash commands.

Original procedure tool scope: `pricing___get_market_depth`, `pricing___get_vwap`, `pricing___get_candles`, `pricing___get_spot_trades`, `pricing___get_order_book_snapshot`, `pricing___get_latest_prices`, `pricing___list_pricing_sources`, `pricing___get_market_variances`, `analytics___getImpliedRates`, `analytics___getImpliedRatesOtcFx`, `analytics___getImpliedVolatilitySurface`.

You are a market data collection agent. Your job is to gather exchange-level pricing and liquidity data efficiently from the Lukka-Pricing hosted MCP server.

## Tool Naming

All tools are on Lukka-Pricing with prefix `pricing___`. Use the matching operation advertised by the host.

## Algorithm

### Phase 1: Parse Input
- Receive `pairCode` and list of `sourceId`s (or exchange names to resolve)
- If names given, call `pricing___list_pricing_sources` to map to sourceIds
- Do NOT hardcode sourceIds - exchange status changes over time. Call `list_pricing_sources` and prefer `status: "ACTIVE"` venues; if a requested id is INACTIVE, note it and substitute an active liquid venue (e.g. 4001 Kraken, 4005 Binance, 4007 Gate.io, 4009 Huobi, 4010 KuCoin, 4018 Crypto.com).

### Phase 2: Parallel Data Collection (one set of calls per sourceId)

For each sourceId:
1. `pricing___get_market_depth({ sourceIds: "{id}", baseAssetCodes: "{base}", counterAssetCodes: "{counter}" })`
   - **CRITICAL**: always set `baseAssetCodes` + `counterAssetCodes`. Omitting filters returns a 6.8 MB full exchange dump. `sourceIds` accepts comma-separated values (e.g. `"4001,4002"` = one record per source), so multiple exchanges can be fetched in a single call when convenient.
   - Depth fields: `bids_1` / `asks_1` = depth within 1% of mid price (best for liquidity comparison)
2. `pricing___get_vwap({ pairCode, sourceIds: "{id}", from: 24h_ago, to: now })`
   - Max 7-day range per call
3. `pricing___get_candles({ pairCode, sourceId: "{id}", interval: 86400000 })`
   - 24h volume via the most recent daily candle

Run across sourceIds in parallel where the runtime permits. Intervals are MILLISECONDS (`86400000` = 1 day, `3600000` = 1 hr).

### Phase 3: Aggregate

- Rank exchanges by total depth (bids_1 + asks_1), tightest spread, highest 24h volume
- Spread in bps: `(ask - bid) / mid * 10000`
- Note exchanges with no data or errors per-source rather than failing globally

### Phase 4: Return Summary

Return a compact structured summary with per-exchange rows and an overall ranking.

## Quality Standards

- Use milliseconds for intervals
- Pair format: `XBT-USD`, `ETH-USD`, `SOLN-USD` (never `BTC-USD` / `SOL-USD`)
- `get_market_depth` accepts comma-separated `sourceIds` (one record per source); base/counter filters remain mandatory
- VWAP max range is 7 days - shorten the window if needed
- Report per-exchange errors rather than aborting the whole run

View saved version →

---
name: new-listings
description: "Monitor new exchange listings since a given date"
---

## OpenAI connection notes

Tool identifiers below are raw operation names. The host may add a namespace;
use the matching advertised Global MCP tool. Resolve `<resolved-package-root>`
to this plugin's installed directory before using paths. Workflow names identify
packaged skills; they are not literal Claude slash commands.

Original procedure tool scope: `pricing___get_latest_prices`, `refdata___get_asset_by_id`, `refdata___get_asset_mappings`.

# new-listings workflow

> See [CONNECTORS.md](../../CONNECTORS.md) for tool details.

## Usage

new-listings workflow <user input>

Parse <user input> for exchange code (use canonical Lukka codes: `CPRO`, `KRAK`, `BINA`, `GMNI`, etc. - never `COINBASE`) and optional `since` date (default: 7 days ago).

## Flow

1. **Recent mappings**: `refdata___get_asset_mappings({ entityCode: "{code}", mapProcessedStartTime: "{since}T00:00:00Z", mappingStatus: "Active", limit: 100 })` 
2. **Per new listing**: take `lukkaAssetId` from the mapping row, then `refdata___get_asset_by_id({ assetLid: "{lukkaAssetId}" })`  for metadata (`list_assets` filters by `lukkaAssetIds` / `assetGroupId`; code resolution goes through `get_asset_mappings`)
3. **Prices**: `pricing___get_latest_prices({ sourceId: 2000, pairCodes: "{code}-USD" })`  for each (sourceId 2000 = Lukka Prime Intraday)
   - If price returns empty/404 for a fresh listing, display "not yet indexed" instead of blank

## Output

### New Listings on {exchange} since {date}

Found **{count}** new listings.

| # | Asset Code | Asset Name | Blockchain | First Active | Price (USD) |
|---|-----------|------------|------------|--------------|-------------|

- First Active = `mapEffectiveStartTime` (when trading actually began); falls back to `mapProcessedStartTime` (when Lukka recorded) if effective is null
- Source shown in parentheses: "(effective)" or "(processed)"

**Summary**: {count} new assets listed. {highlights}.

View saved version →

---
name: news
description: "Digital asset news search, sentiment filtering, and daily digests"
---

## OpenAI connection notes

Tool identifiers below are raw operation names. The host may add a namespace;
use the matching advertised Global MCP tool. Resolve `<resolved-package-root>`
to this plugin's installed directory before using paths. Workflow names identify
packaged skills; they are not literal Claude slash commands.

Original procedure tool scope: `news___getDailySummaries`, `news___getNews`.

# news workflow

> See [CONNECTORS.md](../../CONNECTORS.md) for tool details.

## Usage

news workflow <user input>

Parse <user input>:
- Bare text = keyword search (e.g. `news workflow bitcoin ETF`)
- `--category` or `--cat` = primaryCategory filter
- `--sentiment` or `--sent` = sentiment filter (positive/negative/neutral/mixed)
- `--days N` = look back N days (default 7)
- `--daily` = show daily summaries instead of articles
- `--limit N` = max results (default 20, max 500)
- No arguments = last 7 days of daily summaries

## Flow

### Mode A: Daily summaries (no args, or `--daily`)

1. `news___getDailySummaries({ limit: 7 })` 
   - Adjust `limit` if `--days N` specified
   - Monday summaries cover Saturday + Sunday (weekend digest)
   - Summaries available from 2026-04-08

### Mode B: News search (keyword or filters provided)

1. Compute date range from `--days N` (default 7):
   - `publishDateFrom`: `{N_days_ago}T00:00:00Z`
   - `publishDateTo`: `{today}T23:59:59Z`
   - **CRITICAL: Always pass full ISO 8601 with time+zone (e.g. `2026-05-01T00:00:00Z`).**

2. `news___getNews({ keyword, primaryCategory, sentiment, publishDateFrom, publishDateTo, qualityFrom: 50, sortBy: "date", sortOrder: "desc", limit })` 

### Mode C: Trending (user asks "what's trending" or "top stories")

1. `news___getNews({ relevanceFrom: 75, sortBy: "relevanceScore", sortOrder: "desc", publishDateFrom: "{7d_ago}T00:00:00Z", publishDateTo: "{now}T23:59:59Z", limit: 15 })` 

## Output

### Mode A: Daily Summaries

**Digital Asset News Digest - Last {N} Days**

| Date | Sentiment | Articles | Key Themes |
|------|-----------|----------|------------|
| 2026-05-16 | Positive | 142 | {keyThemes[0..2]} |

Per-day detail (if few days):
- **{date}**: {summaryText excerpt}
  - Notable: {notableEvents[0..2] titles}
  - Top assets: {topAssets[0..2]}

### Mode B/C: News Articles

**Digital Asset News - "{keyword}" ({N} results)**

| # | Date | Title | Source | Sentiment | Category | Quality |
|---|------|-------|--------|-----------|----------|---------|
| 1 | 2026-05-16 | {title} | {entityName} | positive | defi-protocols | 85 |

For small result sets (<=5), expand each article:
- **{title}**
  - {publishDateTime} | {entityName} | {sentiment}
  - {snippet}
  - Quality: {qualityScoreTotal}/100 | Relevance: {relevanceScoreTotal}/100

## Valid Categories

Valid `primaryCategory` / `newsCategory` values (AI-tagged, guided taxonomy - not a fixed enum), grouped by theme:

- Markets & Trading: `price-analysis`, `market-news`, `exchange-news`, `derivatives`, `market-manipulation`
- Technology & Development: `protocol-development`, `smart-contracts`, `consensus-mechanisms`, `scaling-solutions`, `interoperability`, `developer-tools`, `open-source`
- Regulation & Legal: `regulatory-news`, `compliance`, `legal-cases`, `government-policy`, `tax-policy`, `enforcement-actions`
- DeFi & Protocols: `defi-protocols`, `lending-borrowing`, `dexes`, `yield-farming`, `staking`, `liquidity`
- NFTs & Digital Collectibles: `nft-markets`, `nft-collections`, `digital-art`, `gaming-nfts`, `nft-utility`, `metaverse`
- Institutional & Enterprise: `institutional-adoption`, `etf-news`, `corporate-treasury`, `custody-solutions`, `traditional-finance`
- Security & Privacy: `security-breaches`, `wallet-security`, `privacy-tech`, `cryptography`, `audit-reports`
- Economics & Tokenomics: `monetary-policy`, `tokenomics`, `mining-news`, `stablecoin-news`, `cbdc`
- Ecosystem & Community: `community-govern

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: pair-mapping
description: "Resolve exchange pair codes to Lukka canonical pairs, or find how a Lukka pair is named across exchanges"
---

## OpenAI connection notes

Tool identifiers below are raw operation names. The host may add a namespace;
use the matching advertised Global MCP tool. Resolve `<resolved-package-root>`
to this plugin's installed directory before using paths. Workflow names identify
packaged skills; they are not literal Claude slash commands.

Original procedure tool scope: `refdata___get_pair_mappings`, `refdata___list_entities`.

# pair-mapping workflow

> See [CONNECTORS.md](../../CONNECTORS.md) for tool details.

## Usage

pair-mapping workflow <user input>

Parse <user input> - can be:
- A Lukka pair code: `XBT-USD`
- An exchange-specific pair code: `BTC/USDT`, `XBTUSD`
- An exchange name/code + pair: `KRAK XBT/USD`
- An exchange code only: `KRAK` (returns all pairs for that exchange)

Use canonical Lukka codes (`CPRO`, `KRAK`, `BINA`, ...) - never `COINBASE`.

## Personas

- **FX & Stablecoin Settlement**: Normalize obscure pairs (e.g. USDT/UAHG) for PnL and fiat on/off-ramp reconciliation
- **Regulatory & Tax Reporting**: Translate every exchange pair into standard base/quote for capital gains and jurisdictional reporting

## Flow

### Case A: Resolve exchange pair -> Lukka canonical

1. If a free-form exchange name is given, resolve to entityCode via `refdata___list_entities({ })` 
2. `refdata___get_pair_mappings({ entityPairCode: "{code}", entityCode: "{code}", mappingStatus: "Active", })` 
3. Returns: `lukkaPairCode`, `lukkaAssetOneCode` (base), `lukkaAssetTwoCode` (counter), direction

### Case B: All exchange names for a Lukka pair

1. `refdata___get_pair_mappings({ lukkaPairCode: "XBT-USD", mappingStatus: "Active", limit: 1000 })` 
2. Returns all entity-specific codes for that pair
   - **`lukkaPairCode` is the Lukka identifier; `entityPairCode` is the exchange-side code** (e.g. Lukka `XBT-USD` == Binance `BTCUSD`). To confirm a specific exchange, pin `entityCode` too - do NOT conclude "not mapped" from a partial `lukkaPairCode`-only page (80+ venues on a flagship pair; page until `next` is null).

### Case C: All pairs for an exchange

1. `refdata___get_pair_mappings({ entityCode: "{KRAK}", mappingStatus: "Active", limit: 1000 })` 

### Supplemental search

When the exact code is unknown, page through `get_pair_mappings({ entityCode: "{code}", mappingStatus: "Active", limit: 1000 })`  and filter client-side on the `entityPairCode` substring.

## Output

### Pair Mapping: {input}

**Canonical Lukka Pair**: {lukkaPairCode}
- Base asset: {lukkaAssetOneCode} ({assetName})
- Counter asset: {lukkaAssetTwoCode} ({assetName})

**Exchange Names** ({count} active mappings)
| Exchange | Pair Code | Direction | Status |
|----------|-----------|-----------|--------|
| Kraken | XBT/USD | Standard | Active |
| Binance | BTCUSDT | Reversed | Active |

- Direction vocabulary: "Standard" = exchange base/counter matches Lukka pair order. "Reversed" = exchange pair is inverted relative to Lukka canonical. "Ambiguous" = cannot determine (rare, flag for review).

**Notes**: {any reversed pairs, deprecated codes, or ambiguous mappings}
- "Ambiguous" heuristic: when `lukkaAssetOneCode` and `lukkaAssetTwoCode` are both digital assets (no fiat counter), direction is determined by `pairDirection` field. If absent, mark as "Ambiguous".

View saved version →

---
name: resolve-assets
description: "Bulk resolve white paper codes to Lukka asset codes and prices"
---

## OpenAI connection notes

Tool identifiers below are raw operation names. The host may add a namespace;
use the matching advertised Global MCP tool. Resolve `<resolved-package-root>`
to this plugin's installed directory before using paths. Workflow names identify
packaged skills; they are not literal Claude slash commands.

Original procedure tool scope: `pricing___get_latest_prices`, `refdata___get_asset_by_id`, `refdata___get_asset_mappings`.

# resolve-assets workflow

> See [CONNECTORS.md](../../CONNECTORS.md) for tool details.

## Usage

resolve-assets workflow <user input>

Parse <user input> as comma-separated white paper codes.

## Flow

Uses the **asset-resolver** skill workflow. Resolution path: alias map -> `get_asset_mappings(entityAssetCode)` -> `get_asset_by_id`. The input is a **street ticker**, not a `lukkaAssetCode` - resolving a raw ticker through `lukkaAssetCode` returns the oldest (often inactive) holder of a collided code (the older migrated asset, never the current one). Aliases (BTC -> XBT, SOL -> SOLN, GALA -> GALAT3) are unique canonical codes and resolve directly.

1. **Per ticker**:
   - In alias map -> use the unique canonical code: `get_asset_mappings({ lukkaAssetCode: "{alias}", mappingStatus: "Active", limit: 200 })`.
   - Not in alias map -> raw ticker: `refdata___get_asset_mappings({ entityAssetCode: "{ticker}", mappingStatus: "Active", limit: 200 })` . Collect distinct `lukkaAssetId` values.
2. **Validate + collapse**: `refdata___get_asset_by_id({ assetLid })`  per distinct LID -> drop `Inactive`/`Contract Migrated`, collapse chain-variants to the group `isPrimaryAsset: true` LID, dedupe to active groups.
3. **Resolve or flag**: one active group -> winner. More than one -> emit `AMBIGUOUS` (see below); do **not** block the batch or auto-pick.
4. **Price**: `pricing___get_latest_prices({ sourceId: 1000, pairCodes: "{lukkaAssetCode}-USD" })`  (sourceId 1000 = Lukka Prime EOD)

## Output

### Asset Resolution Results

| White Paper Code | Lukka Code | Lukka ID | Active Mappings | Price (USD) | Confidence |
|-----------------|------------|----------|-----------------|-------------|------------|
| BTC | XBT | LA6EV2NKQ95 | 52 | $XX,XXX | HIGH |
| (collided ticker) | (multiple) | - | - | - | AMBIGUOUS |

Note: Lukka IDs always follow the format `LA` + 9 alphanumeric characters (e.g. `LA6EV2NKQ95`). Never display abbreviated or placeholder formats like `lid-xxx`.

**Confidence levels**: HIGH (10+ active mappings), MEDIUM (3-9), LOW (1-2), UNRESOLVED (0), AMBIGUOUS (>1 active asset group shares the ticker)
- If result count equals limit (200), display as "200+ (truncated)" and confidence as "HIGH (truncated)"
- For `AMBIGUOUS` rows, follow the table with a short list of competing candidates (name, blockchain, group primary LID) so the user can re-run `asset-report workflow` on the right one. Never silently pick one.

View saved version →

---
name: wallet-scan
description: "Wallet analysis with AML risk, balance, assets, and transaction preview"
---

## OpenAI connection notes

Tool identifiers below are raw operation names. The host may add a namespace;
use the matching advertised Global MCP tool. Resolve `<resolved-package-root>`
to this plugin's installed directory before using paths. Workflow names identify
packaged skills; they are not literal Claude slash commands.

Original procedure tool scope: `AML___generateAmlEnhancedReport`, `AML___generateAmlScoringReport`, `AML___generateAmlSimplifiedReport`, `AML___generateAmlStandardReport`, `UDA___get_address_assets`, `UDA___get_address_balance`, `UDA___get_address_transactions`.

# wallet-scan workflow

> See [CONNECTORS.md](../../CONNECTORS.md) for tool details.

## Usage

wallet-scan workflow <user input>

Parse <user input> for address and blockchain symbol. Remember: Lukka-UDA uses lowercase (`eth`, `btc`), Lukka-AML uses uppercase (`ETH`, `BTC`).

> **UDA vs AML chain coverage differ.** UDA address/tx endpoints (steps 1-3) serve: btc, bch, ltc, doge, dash, eth, avax, xrp, xlm, near, dot (+ vet balance-only). `sol`, `trx`, `matic`, `ada` return "Unsupported crypto symbol" on UDA even though AML (step 4) DOES score them. On a chain where AML scores but UDA address/tx endpoints do not serve (e.g. sol, trx), skip steps 1-3, note "on-chain data for {chain} is provided via the AML report", and run the AML scoring/standard/enhanced report only. See `skills/lukka-data-routing/references/uda.md` for the full per-endpoint matrix.

## Flow (context-safe sequence)

1. **Balance**: `UDA___get_address_balance({ blockchain: "{lc}", address: "{address}" })` 
2. **Assets**: `UDA___get_address_assets({ blockchain: "{lc}", address: "{address}" })` 
3. **Transaction preview** (always cap at 100 to stay within context):
   `UDA___get_address_transactions({ blockchain: "{lc}", address: "{address}", verbose: "1", limit: 100, get_newest: "1" })` 
4. **Light AML (default)**: `AML___generateAmlScoringReport({ address: "{address}", address_type: "{UC}" })` 
   - **Parameter is `address_type`** (e.g. `"ETH"`, `"BTC"`), NOT `blockchain`. Same for `generateAmlStandardReport` / `Enhanced`.
   - Returns C-Score (0-100) + risk_level (LOW/MEDIUM/HIGH) + top factors. Fits in context.
   - To reuse an existing report: `--reuse-report {report_id}` skips re-scoring

## On request: deeper analysis

### Full transaction scan (>100 txs)

Before calling with large limit, deploy the processor so the raw response never enters context. See `large-data-processing` skill.

```
cp "<resolved-package-root>/skills/large-data-processing/references/process_transactions.py" /tmp/
# Call MCP with limit:1000, save raw JSON to /tmp/txs.json
python3 /tmp/process_transactions.py /tmp/txs.json --stats --top-senders 10 --dust-threshold 0.0001
# Then selectively decode flagged hashes via Get_transaction_for_txhash
```

### Full AML report (325 KB+ - mandatory processor pipe)

```
cp "<resolved-package-root>/skills/large-data-processing/references/process_aml_report.py" /tmp/
# Call AML___generateAmlStandardReport, save raw to /tmp/aml_report.json
python3 /tmp/process_aml_report.py /tmp/aml_report.json
```

For maximum depth: `AML___generateAmlEnhancedReport` (500 KB+) - same processor workflow.

### Counterparty exposure (on demand)

> **Note**: for counterparty exposure data, use `generateAmlStandardReport` (with processor pipe).

> **Report tier availability**: Use SCORING for a light check on any chain. For a full or deep report use STANDARD/ENHANCED on these 30 chains: `ADA, AVAX, BCH, BSV, BTC, CC, DASH, DOGE, DOT, DOT_AH, ETC, ETH, FIL, ICP, IOTA_MAINNET, IOTAEVM, LTC, MATIC, NEAR, NEO, RSK, SOL, TRX, VET, XDAI, XLM, XRP, XTZ, ZEC, ZKS`. SIMPLIFIED covers the additional 80 chains: `ALGO, APT, ARBITRUM, ATOM, AZERO, BASE, BNB, BSC, CANTO, CELO, CHZ, CKB, COTI, CRO, CRONOS, DCR, DGB, DOGECHAIN, ECS, EGLD, EOS, ETHW, EVMOS, FET, FLOW, FTM, FUSE, GLMR, GRAM, HASH

Preview of the first 4,000 characters. Read full instructions →