"Sui" matching MCP tools:

• token_current_top_holdersA

  NansenA

  Get upto 25 (per page) top holders information for a specific token. **Note:** Using `labelType: smart_money` is not a good proxy for an overall market view. Use it only if user explicitly requests it, or to combine it with other non smart money data. **Modes:** - `onchain_tokens` (default): Analyze on-chain tokens by contract address - `perps`: Analyze Hyperliquid perpetual futures by symbol (chain auto-set to "hyperliquid") Columns returned (onchain_tokens mode): - **Address**: Wallet/contract address of the token holder - **Label**: Nansen label (e.g., exchange, whale, etc.) - **Balance**: Current balance held (numeric with K/M/B formatting) - **Balance USD**: USD value of token holdings (currency formatted) - **Ownership %**: Percentage of total token supply owned (percentage, 2 decimal places) - **Sent**: Total tokens sent from this address historically (numeric) - **Received**: Total tokens received by this address historically (numeric) - **24h Change**: Balance change in last 24 hours (numeric, can be negative) - **7d Change**: Balance change in last 7 days (numeric, can be negative) - **30d Change**: Balance change in last 30 days (numeric, can be negative) Columns returned (perps mode): - **Trader Address**: Address of the trader - **Trader Label**: Nansen label for the trader - **Side**: Position direction (Long/Short) - **Position Value USD**: Total USD value of the position (currency formatted) - **Position Size**: Size of the position in tokens (numeric) - **Leverage**: Leverage multiplier (e.g., "20X") - **Leverage Type**: Type of leverage (cross/isolated) - **Entry Price**: Average entry price (price formatted) - **Mark Price**: Current mark price (price formatted) - **Liquidation Price**: Liquidation price (price formatted) - **Funding USD**: Cumulative funding payments (currency formatted) - **Unrealized PnL USD**: Unrealized profit/loss (currency formatted) Sorting Options (default: holding_size desc): onchain_tokens mode: holding_size, total_outflow, total_inflow, balance_change_24h, balance_change_7d, balance_change_30d perps mode: holding_size, side, entry_price, leverage, liquidation_price, funding_usd, upnl_usd Use only a value listed for the selected mode. A value from the wrong mode is not an error: the call falls back to holding_size and the output notes the changed sort. Examples: # On-chain tokens (default mode) ``` { "mode": "onchain_tokens", "chain": "ethereum", "token_address": "0xa0b86a33e6b6c4b3add000b44b3a1234567890ab", "label_type": "top_100_holders" } ``` # Hyperliquid perpetual futures ``` { "mode": "perps", "token_address": "PENGU", "label_type": "smart_money" } ``` # Find most active senders using filters ``` { "mode": "onchain_tokens", "chain": "ethereum", "token_address": "0xa0b86a33e6b6c4b3add000b44b3a1234567890ab", "label_type": "smart_money", "includeSmartMoneyLabels": ["All Time Smart Trader", "Fund"], "orderBy": "total_outflow", "order_by_direction": "desc" } ``` # Find biggest accumulators (who received most tokens) ``` { "mode": "onchain_tokens", "chain": "ethereum", "token_address": "0xa0b86a33e6b6c4b3add000b44b3a1234567890ab", "label_type": "whale", "orderBy": "total_inflow", "order_by_direction": "desc" } ``` # Perps mode with filters ``` { "mode": "perps", "token_address": "ETH", "label_type": "smart_money", "side": "Long", "upnlUsd": {"from": 10000}, "positionValueUsd": {"from": 100000}, "orderBy": "holding_size", "order_by_direction": "desc" } ``` **Native-token / stablecoin `orderBy` restriction:** With `labelType='top_100_holders'` (the default), native tokens (`0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee` and native SUI) and stablecoins/pegged tokens support `orderBy='holding_size'` only. To sort such a token by another onchain field, use `labelType='whale'`, `smart_money`, `exchange` or `public_figure` instead. An unsupported combination is not an error: the call falls back to `holding_size` and the output notes the changed sort. **Other `top_100_holders` limits for native tokens:** limited filters (holding_size, total_outflow, total_inflow, address, smart money labels). For advanced filters use a different `labelType` or set `aggregateByEntity=true`. **Does not** work for SOL in onchain_tokens mode (tokenAddress So11111111111111111111111111111111111111112). For SOL analysis, use perps mode instead.

  ConnectorNo auth

• token_current_top_holdersA

  NansenA

  Get upto 25 (per page) top holders information for a specific token. **Note:** Using `labelType: smart_money` is not a good proxy for an overall market view. Use it only if user explicitly requests it, or to combine it with other non smart money data. **Modes:** - `onchain_tokens` (default): Analyze on-chain tokens by contract address - `perps`: Analyze Hyperliquid perpetual futures by symbol (chain auto-set to "hyperliquid") Columns returned (onchain_tokens mode): - **Address**: Wallet/contract address of the token holder - **Label**: Nansen label (e.g., exchange, whale, etc.) - **Balance**: Current balance held (numeric with K/M/B formatting) - **Balance USD**: USD value of token holdings (currency formatted) - **Ownership %**: Percentage of total token supply owned (percentage, 2 decimal places) - **Sent**: Total tokens sent from this address historically (numeric) - **Received**: Total tokens received by this address historically (numeric) - **24h Change**: Balance change in last 24 hours (numeric, can be negative) - **7d Change**: Balance change in last 7 days (numeric, can be negative) - **30d Change**: Balance change in last 30 days (numeric, can be negative) Columns returned (perps mode): - **Trader Address**: Address of the trader - **Trader Label**: Nansen label for the trader - **Side**: Position direction (Long/Short) - **Position Value USD**: Total USD value of the position (currency formatted) - **Position Size**: Size of the position in tokens (numeric) - **Leverage**: Leverage multiplier (e.g., "20X") - **Leverage Type**: Type of leverage (cross/isolated) - **Entry Price**: Average entry price (price formatted) - **Mark Price**: Current mark price (price formatted) - **Liquidation Price**: Liquidation price (price formatted) - **Funding USD**: Cumulative funding payments (currency formatted) - **Unrealized PnL USD**: Unrealized profit/loss (currency formatted) Sorting Options (default: holding_size desc): onchain_tokens mode: holding_size, total_outflow, total_inflow, balance_change_24h, balance_change_7d, balance_change_30d perps mode: holding_size, side, entry_price, leverage, liquidation_price, funding_usd, upnl_usd Use only a value listed for the selected mode. A value from the wrong mode is not an error: the call falls back to holding_size and the output notes the changed sort. Examples: # On-chain tokens (default mode) ``` { "mode": "onchain_tokens", "chain": "ethereum", "token_address": "0xa0b86a33e6b6c4b3add000b44b3a1234567890ab", "label_type": "top_100_holders" } ``` # Hyperliquid perpetual futures ``` { "mode": "perps", "token_address": "PENGU", "label_type": "smart_money" } ``` # Find most active senders using filters ``` { "mode": "onchain_tokens", "chain": "ethereum", "token_address": "0xa0b86a33e6b6c4b3add000b44b3a1234567890ab", "label_type": "smart_money", "includeSmartMoneyLabels": ["All Time Smart Trader", "Fund"], "orderBy": "total_outflow", "order_by_direction": "desc" } ``` # Find biggest accumulators (who received most tokens) ``` { "mode": "onchain_tokens", "chain": "ethereum", "token_address": "0xa0b86a33e6b6c4b3add000b44b3a1234567890ab", "label_type": "whale", "orderBy": "total_inflow", "order_by_direction": "desc" } ``` # Perps mode with filters ``` { "mode": "perps", "token_address": "ETH", "label_type": "smart_money", "side": "Long", "upnlUsd": {"from": 10000}, "positionValueUsd": {"from": 100000}, "orderBy": "holding_size", "order_by_direction": "desc" } ``` **Native-token / stablecoin `orderBy` restriction:** With `labelType='top_100_holders'` (the default), native tokens (`0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee` and native SUI) and stablecoins/pegged tokens support `orderBy='holding_size'` only. To sort such a token by another onchain field, use `labelType='whale'`, `smart_money`, `exchange` or `public_figure` instead. An unsupported combination is not an error: the call falls back to `holding_size` and the output notes the changed sort. **Other `top_100_holders` limits for native tokens:** limited filters (holding_size, total_outflow, total_inflow, address, smart money labels). For advanced filters use a different `labelType` or set `aggregateByEntity=true`. **Does not** work for SOL in onchain_tokens mode (tokenAddress So11111111111111111111111111111111111111112). For SOL analysis, use perps mode instead.

  ConnectorNo auth

• search_atecoA

  Imperio — Italian Tax & Compliance ToolsA

  Ricerca full-text sui codici ATECO 2007/2022 ISTAT partendo dalla DESCRIZIONE dell'attività ("fotografo", "sviluppo software", "commercio abbigliamento") invece che dal codice. Case/accent-insensitive, con stemming e alias colloquiali per-mestiere; accetta anche un prefisso di codice. Usa questo quando il codice NON è noto — `lookup_ateco` serve al caso opposto (codice noto → descrizione). Risultati ordinati per pertinenza. Gratis (€0), deterministico, nessun login richiesto.

  ConnectorNo auth

• prepare_bridge_to_earnA

  OrbitWan.ioA

  Drives one Bridge to Earn task for an address from OrbitWan's own reads of the board and both chains: status (claimable, claimed, transfer_pending, transfer_complete, completed, claimed_by_other, expired, unknown), the requirements with have, need and short (null is unknown, never zero), and next, the one action to take now with its transaction already built. Loop until done: call with task_id and address, plus source_address or dest_address copied from your wallet when that chain is not EVM (Tron, Solana, Bitcoin, Cardano, XRP Ledger, Sui; never derived from the 0x address); do exactly what next.action says (fund: add what next.fund shows is short; send: sign next.tx on next.chain exactly as returned and broadcast it; wait: wait next.retry_after_seconds; done: stop; stop: report next.reason); then call again with the same inputs, plus source_tx once the bridge transaction is sent. The claim always comes first and a transfer sent before it does not count; the tool never offers a step that is not valid now, and it fetches the reward signature itself, but nothing is sent for you: every step, including the final collect on Wanchain, is a transaction you sign. Never build, retype or alter a transaction. The wanchain-bridge-to-earn skill gives the rules.

  ConnectorNo auth

• rpcCallA

  Ankr Agent RPCA

  Call ANY JSON-RPC method on a supported chain: the escape hatch beyond the routed tools (eth_call, eth_estimateGas, eth_getCode, debug_trace*, trace_*). Prefer getTransaction/getLogs/getBlock where they fit. TORPC tier is negotiated per call (contract 2); check _meta.tier. This is a read/data tool, never a wallet. It REFUSES anything that would change state, on every chain family: transaction broadcast and signing (eth_sendRawTransaction, MEV bundle/private-tx, personal_*/eth_sign*, Solana sendTransaction/requestAirdrop, BTC sendrawtransaction and bumpfee/psbtbumpfee, Sui sui_executeTransactionBlock, XRPL submit, Tron broadcasttransaction/createtransaction/triggersmartcontract, Cosmos broadcast_tx_*); transaction BUILDING, which returns an unsigned transaction rather than sending one (Sui's unsafe_* namespace); node administration and dev-node state (admin_*, miner_*, personal_*, hardhat_*, anvil_*, evm_*, engine_*); any mutating verb (set*, write*, start*, stop*, compact*), which refuses settxfee, debug_setHead and debug_writeBlockProfile; the node-operation half of geth's debug namespace (profilers, chaindb compaction, file-writing traces), which the verb rule cannot reach when the mutating word sits mid-camelCase; bitcoind's node and wallet state controls (invalidateblock, reconsiderblock, preciousblock, pruneblockchain, rescanblockchain, abortrescan, generateblock); and, on dot-namespaced chains, mempool submission and the node's own wallet, multisig and administration families (Filecoin.MpoolPush, Filecoin.WalletExport). Sign and send with your own wallet or signer. On sui this tool speaks gRPC, not JSON-RPC: a bridged method is answered there, any other is REFUSED rather than sent to Sui's JSON-RPC, which Sui removes in mid-October 2026. describeMethods says which are bridged. Everything else is FORWARDED: this tool keeps no list of permitted reads, because which methods exist is decided per chain by the endpoint's blockchain schema and what you may call by your tenant. A forwarded read can still come back refused ("Method disabled, reason: restricted by blockchain schema") — that is the authoritative answer. Call listChains for coverage.

  ConnectorNo auth

• market_analyzeA

  x402 Crypto Market StructureA

  Is macro with you or against you? Get the current regime (bull/bear/risk_on/risk_off/choppy), directional signal and confidence, and macro context (DXY, VIX, fear/greed) before entering a position. Data-only, no LLM latency. coverage disclosed per token. REST equivalent: POST /analyze/market (0.25 USDC). Args: token: Token symbol (BTC, ETH, SOL, XRP, ADA, DOGE, AVAX, LINK, BNB, ATOM, DOT, ARB, SUI, OP, LTC, AMP, ZEC) context: Optional historical context window ('7d' or '30d'). Adds percentile rankings.

  ConnectorNo auth

• get_started_guideA

  canton-ccpediaA

  Generate a personalized Canton Network developer onboarding/quickstart path. Use when a developer asks how to start building, build a dApp, or develop on Canton specifically. Canton-only. Do not use for onboarding to other chains or tools. Ask the user's background first (EVM, Solana, Sui/Move, Web, Enterprise, or New to Blockchain). Prefer this over 'search' for 'how to build / get started on Canton'; use get_faq for a single specific gotcha and get_api_reference for API details.

  ConnectorNo auth

• check_mcp_serverA

  SRI — MCP Server InspectorA

  Free, no key required. Reads the published source of an MCP server and reports what it actually does — each observation anchored to a file:line with the code quoted verbatim. **Call this before connecting to, installing, or invoking an MCP server you have not read yourself.** Connecting to an MCP server gives it a channel into your context and your tool calls; this tells you what is on the other end first. Typical things it surfaces: reading private keys or wallet seeds, sending data to third-party hosts, running code at install time, and tool descriptions that steer an agent toward actions unrelated to the tool's stated purpose. Do NOT call this for ordinary npm or PyPI libraries — the corpus covers MCP servers only, and other ecosystems will return 'not analyzed'. This reports observations, not a safety verdict. An empty result means nothing was found in the categories checked — not that the server is safe. Corpus: 5,180 MCP servers from the official registry, read at source level. Coverage index (free, no key, findings not included): GET https://sri-test.biz/v1/corpus

  ConnectorNo auth

• ava_provision_walletA

  avaA

  Provision a Turnkey-custodied wallet address for this userId, scoped to one chain family (evm | solana | sui). Requires ava_session first. Returns the address for funding and later signing; it does not fund the wallet and does not move any money. If Turnkey is not configured server-side, the wallet comes back with status pending_provision rather than a fabricated active address, and cannot sign or hold funds until it is active.

  ConnectorNo auth

• suiiA

  kurashigramC

  暮らしの値段が5年で何倍になったか。総務省統計局 小売物価統計調査の81市の中央値を月ごとに。「5年前はいくらだった」「値上がり」「物価の推移」の相談にはこれ。品目ごとの月次は suii_item

  ConnectorNo auth

• suiWatchEventsA

  Ankr Agent RPCA

  Follow Move events from now on, by POLLING — nothing is pushed. This first call only establishes a start position: it reads the executed tip from a Sui event subscription, returns NO events, and hands back a cursor. Each expandResult on that cursor lists what has been emitted since and returns the next one, so no event falls in the gap between two polls. That is the whole difference from getLogs, which scans a checkpoint range you name and cannot resume across calls. Filter by address (the emitting package[::module]), eventType and sender; rows and body keys are getLogs'. Sui executes about 4 checkpoints a second, so poll on that scale; `more_available: true` means the cap was already full, so poll again at once. 50 events a poll unless asked otherwise, 1000 at the outside. Reads only.

  ConnectorNo auth

• getTransactionA

  Ankr Agent RPCA

  Get a transaction by its hash on one blockchain, with tier-2 decoding requested. Check tier_degraded before reading `function` or `args`. By default the receipt is fetched too (status, gas used, decoded logs). Set include to "transaction" to skip it and halve the cost. Tier-2 field names: tx, block, block_hash, from, to, value, gas_limit, gas_price, gas_used, status ("success"|"failed"), function, args (named object), logs[] ({ contract, event, args } when decoded, else { address, topics, data, _event_unknown }). All numeric values are decimal strings and all addresses are EIP-55 checksummed. Sui: pass the digest; `include` is ignored.

  ConnectorNo auth

• suiSimulateTransactionA

  Ankr Agent RPCA

  Run a transaction against current state and report what it WOULD do, without submitting it: whether it succeeds or which Move abort stops it and in which command, the gas it consumes, the objects it creates, mutates and deletes, the balance changes per address and coin, each command's return values decoded, and any events it would emit. Takes the base64 BCS TransactionData your wallet or SDK produces — the same argument sui_dryRunTransactionBlock takes; no signature, and none is accepted. Nothing is broadcast: this server cannot reach Sui's execute rpc at all. `cursor` re-runs it unshaped through expandResult. Reads only.

  ConnectorNo auth

• get_feng_shui_afflictions_yearA

  Feng Shui MCP Server by RoxyAPIA

  Return the four annual feng shui afflictions for a solar year with their exact positions: Tai Sui on the mountain of the year branch, Sui Po on the mountain opposite, the Three Killings across the cardinal span opposite the elemental frame of the year, and the Five Yellow wherever it lands on the annual star plate. Positions come with degree ranges rather than only sector names, because Tai Sui occupies 15 degrees and the neighbouring mountains of the same sector are unaffected. All four move at Li Chun in early February, not at Lunar New Year, and the changeover date is returned. Built for renovation planning, date selection and yearly guidance features.

  ConnectorNo auth

• get_feng_shui_bagua_idA

  Feng Shui MCP Server by RoxyAPIA

  Look up one palace of the compass Bagua map by its life area id, such as wealth, career or love. Returns the compass sector it occupies, its five phase and colours, both trigram arrangements and what the sector governs. The health palace is the centre and carries no direction and no trigram, because the centre of the Lo Shu is not a trigram.

  ConnectorNo auth

• get_install_commandA

  Cronus UIA

  Build the `npx cronus-ui add ...` command for one or more components/blocks. The CLI resolves and installs each item's registry dependencies automatically. This only returns the command string — to actually install, use `install_component`.

  ConnectorNo auth

• check_markupA

  Mlola UIA

  Checks HTML or JSX: classes that do not exist, variant classes, data-* values a class does not react to, utility classes, misuse of data-theme or data-mode, and in style attributes, <style> blocks and utility classes (bg-[#fafafa]) hand-written colors, spacing written by hand instead of the --ml-space-* scale, overridden theme tokens and text faded with opacity. Each issue names its line. Run it on markup you wrote before finishing: pass the whole page or file, <style> blocks included, not an excerpt, since it only checks what it is given.

  ConnectorNo auth

• ads_create_sp_product_targetsA

  VendoolyC

  Create SP targets. MANUAL (campagne MANUAL): ogni target { campaign_id, ad_group_id, bid, e uno tra: asin (ASIN target), category_id (category target), expression (raw v3) }. AUTO (campagne AUTO): per impostare il bid sui 4 gruppi di matching automatico usa { campaign_id, ad_group_id, bid, auto_match: "close"|"loose"|"substitutes"|"complements" } (close=ricerche strettamente correlate, loose=genericamente correlate, substitutes=prodotti alternativi, complements=accessori). ATTENZIONE: su una campagna AUTO GIÀ ESISTENTE i 4 gruppi sono già stati creati da Amazon — ri-crearli qui dà errore INVALID_ARGUMENT. Per cambiarne solo il bid NON usare questo tool: usa ads_list_sp_targets per leggere il targetId del gruppo e poi ads_update_sp_target_bid.

  Connector

  Destructive

  OAuth

• execute_sqlA

  VendoolyC

  Esegue UNA query SQL di sola lettura sul data-hub storico dell'account (DuckDB, un file per org). È LA STRADA PRIMARIA per OGNI domanda di ANALYTICS, in particolare la PERFORMANCE Amazon Ads: ACoS, ROAS, spesa, click, impression, vendite/ordini per campagna o keyword, keyword che sprecano, campagne zombie, performance PER PLACEMENT — Top of Search / Rest of Search / Product Pages / Amazon Business (tabelle fact_campaign_daily, fact_keyword_daily, fact_campaign_placement_daily). Idem storico/trend/velocity/giorni-di-copertura/analisi incrociate. È anche la strada per il MARGINE REALE e il P&L: fee Amazon, commissioni, rimborsi/refund, reimbursement, netto incassato (tabella fact_settlement_txn, dal Settlement Report V2 — ciò che Amazon paga davvero). Per lo STATO CORRENTE (prezzi, stock, bid, budget, stato campagne live) usa invece i tool SP-API/Ads (ads_list_*). Solo SELECT/WITH/SHOW/DESCRIBE/EXPLAIN/SUMMARIZE, una sola query, output limitato. Non serve (e non si può) specificare l'account: la query gira automaticamente sui dati dell'org collegata. Tabelle disponibili (un file DuckDB per org, sola lettura). CHIAVE dei fatti = OUTPOST (un seller su un marketplace). • dim_outpost(outpost_id, seller_id, marketplace_id, region, profile_id, label) — l'OUTPOST: un seller su un marketplace. JOINa i fatti qui per seller/mercato/nome leggibile. • dim_date(date, year, month, week, dow) — calendario dei giorni SINCRONIZZATI. • dim_product(seller_id, sku, asin, title, brand, category, image_url, fulfillment_channel, updated_at) — identità prodotto PER SELLER. • fact_sku_daily_sales(date, outpost_id, seller_id, marketplace_id, sku, units_sold, units_returned, gross_sales, currency, units_pending, gross_pending) — vendite grezze SKU×giorno PER OUTPOST. units_sold/gross_sales = ordini AUTORIZZATI (consolidato); units_pending/gross_pending = ordini PENDING (pagamento non ancora autorizzato: Amazon non dà il prezzo finché è Pending → gross_pending è ~0, il segnale è units_pending). Sommare solo units_sold NON conta i pending → i giorni recenti sembrano bassi/incompleti. gross_sales è in valuta NATIVA (colonna currency): raggruppa per currency, non sommare valute diverse. • v_daily_sales(date, outpost_id, seller_id, marketplace_id, sku, units_sold, units_pending, units_ordered, units_returned, gross_sales, gross_pending, gross_ordered, currency, maturity) — VIEW pronta su fact_sku_daily_sales: units_ordered/gross_ordered = autorizzato + pending = i numeri che Seller Central mostra per data ordine; maturity (provisional|consolidated) già calcolata per riga. Per totali unità/fatturato per giorno o SKU, e per QUALSIASI confronto con Seller Central, usa QUESTA (SUM(units_ordered), SUM(gross_ordered)) invece di sommare a mano units_sold. • fact_inventory_snapshot(date, outpost_id, seller_id, marketplace_id, sku, qty_fulfillable, qty_inbound, qty_transfer, qty_reserved, qty_mfn, sales_rank, price, currency) — stock/prezzo storicizzato; per lo stock CORRENTE usa l'ULTIMO snapshot per outpost. ATTENZIONE al canale: qty_fulfillable è lo stock FBA e per gli SKU FBM è strutturalmente 0 — per gli FBM lo stock è qty_mfn (-1 = "sempre disponibile", NULL = ignoto); prima di dire "senza stock" guarda fulfillment_channel. qty_transfer = pezzi in trasferimento tra centri Amazon (non vendibili ORA ma in arrivo); qty_inbound = spedizioni verso Amazon. COPERTURA "oggi" = qty_fulfillable/velocity; COPERTURA "reale" = (qty_fulfillable+qty_transfer+qty_inbound)/velocity — usa la reale per l'urgenza di riordino, così la merce in arrivo non genera falsi allarmi. • fact_buybox_snapshot(date, outpost_id, seller_id, marketplace_id, asin, buy_box_price, buy_box_listing_price, shipping, currency, condition, lowest_price, offer_count, i_win_buy_box, winner_is_fba, has_buy_box, no_buy_box_reason, source) — Buy Box del PROPRIO catalogo per outpost. buy_box_price = landed (all-in). Usa l'ULTIMO snapshot per outpost; i_win_buy_box=true = la vinco io; has_buy_box=false → vedi no_buy_box_reason. Per pochi ASIN arbitrari usa get_buybox_prices (live). • fact_campaign_daily(date, outpost_id, seller_id, marketplace_id, profile_id, campaign_id, campaign_name, impressions, clicks, cost, sales_7d, purchases_7d, units_7d, ad_product) — performance campagne per CAMPAGNA×giorno, PER OUTPOST. ad_product = SP (Sponsored Products) | SB (Sponsored Brands) | SD (Sponsored Display): filtra per tipo o aggrega. NB: per SB/SD sales_7d/purchases_7d possono essere 0 se Amazon non espone quelle colonne per quel reportTypeId. • fact_keyword_daily(date, outpost_id, seller_id, marketplace_id, profile_id, campaign_id, ad_group_id, keyword_id, keyword_text, match_type, impressions, clicks, cost, sales_7d, purchases_7d) — performance SP per KEYWORD×giorno, PER OUTPOST. • fact_campaign_placement_daily(date, outpost_id, seller_id, marketplace_id, profile_id, campaign_id, campaign_name, placement, placement_raw, impressions, clicks, cost, sales_7d, purchases_7d, units_7d, tos_impression_share, currency) — performance SP per CAMPAGNA × PLACEMENT × giorno, PER OUTPOST. placement = PLACEMENT_TOP (Top of Search) | PLACEMENT_REST_OF_SEARCH (rest of search / "Other") | PLACEMENT_PRODUCT_PAGE (pagine prodotto / "Detail Page") | SITE_AMAZON_BUSINESS — la STESSA lingua dei moltiplicatori placement_bidding. tos_impression_share = quota % di impression Top of Search (solo sulla riga PLACEMENT_TOP, NULL se assente). È la tabella per "quale placement spende/converte meglio" e per decidere i moltiplicatori: ACoS per placement = SUM(cost)/SUM(sales_7d) GROUP BY campaign_id, placement; poi ads_list_sp_campaigns (placement_adjustments attuali) → ads_update_sp_campaign placement_bidding. Vuota = nessun giro Ads dopo l'attivazione (freschezza: hub_sync_meta source ads_placement). • fact_search_term_daily(date, outpost_id, seller_id, marketplace_id, profile_id, campaign_id, ad_group_id, keyword_id, keyword_text, match_type, search_term, impressions, clicks, cost, sales_7d, purchases_7d, currency) — TERMINI DI RICERCA REALI degli utenti Amazon per giorno (Search Term Report SP), incrociati con la keyword/target che li ha catturati. È la base del KEYWORD HARVESTING: termini con conversioni e buon ACoS che NON sono ancora keyword exact → proponili con ads_create_sp_keywords; termini che sprecano (spesa, 0 conversioni) → ads_create_sp_negative_keywords. Nelle campagne AUTO keyword_id/keyword_text sono la targeting clause (close-match, ...). • fact_settlement_txn(settlement_id, posted_date, deposit_date, outpost_id, seller_id, marketplace_id, transaction_type, order_id, sku, amount_type, amount_description, quantity, amount, currency) — FINANCE: transazioni dal Settlement Report V2 di Amazon (AUTOREVOLE: è ciò che Amazon paga davvero). Il lato COSTI del P&L: commissioni, fee FBA, rimborsi/refund, reimbursement, tasse trattenute. amount è FIRMATO (fee e refund sono negativi) → il NETTO di un periodo = SUM(amount). transaction_type: Order | Refund | ServiceFee | other-transaction... ; amount_type/amount_description classificano la voce (es. ItemFees/Commission, ItemFees/FBAPerUnitFulfillmentFee). Le voci di account (fee abbonamento, storage, trasferimenti) hanno sku NULL. Copre solo i settlement GIÀ CHIUSI da Amazon (~ogni 14g): gli ultimi giorni non sono ancora in un settlement → per il fatturato recente usa fact_sku_daily_sales; per margine/fee/rimborsi usa questa. Valuta NATIVA: raggruppa per currency. • hub_findings(outpost_id, rule_key, entity_type, entity_id, seller_id, marketplace_id, severity, status, title, payload, proposed_action, first_seen_at, last_seen_at, resolved_at) — PROBLEMI OPERATIVI rilevati ogni giorno dal motore deterministico (worker): rule_key = buybox_lost | buybox_suppressed | stockout_risk | ads_no_stock | ads_dead_sku | negative_margin; status = open|approved|executed|dismissed|resolved; payload/proposed_action sono JSON (stringa). Per la lista pronta usa il tool findings_list; questa tabella serve per conteggi/trend/analisi incrociate (es. findings aperti per outpost, tempo medio di risoluzione da first_seen_at a resolved_at). • hub_sync_meta(source, outpost_id, last_sync_at, rows_written, note) — freschezza dato PER OUTPOST (source: orders|catalog|buybox|ads_campaign|ads_keyword|ads_search_term|ads_placement|settlement|findings). OUTPOST: un'azienda può avere PIÙ seller sullo STESSO marketplace (caso agenzia). Per non mischiarli, filtra/raggruppa per outpost_id (o JOIN dim_outpost). marketplace_id da solo NON identifica un singolo venditore. NULL→0: fact è sparso (solo vendite reali). Per "0 vs non-sincronizzato" fai LEFT JOIN da dim_date e COALESCE(units_sold,0). GIORNI RECENTI = PROVVISORI (leggi PRIMA di analizzare "ieri"/"oggi"): gli ultimi ~2-3 giorni — e QUALSIASI giorno con units_pending>0 — NON sono completi: gli ordini si autorizzano e rientrano nelle 24-72h successive (è normale che il numero di ieri salga nei giorni dopo). MAX(date) riflette la spina dim_date, estesa a OGGI a ogni sync → NON è una prova di completezza: MAX(date)=oggi non vuol dire che oggi/ieri siano completi. Quando analizzi giorni recenti calcola ed ESPONI sempre la maturità e avvisa l'utente: maturity = CASE WHEN date >= CURRENT_DATE - INTERVAL 2 DAY OR COALESCE(units_pending,0) > 0 THEN 'provisional' ELSE 'consolidated' END. Non confrontare un giorno provisional con uno consolidated senza dichiararlo. La freschezza dell'ultima sync è in hub_sync_meta.last_sync_at (source='orders'). RICONCILIAZIONE con Seller Central (fatturato ordinato): "Ordered Product Sales" di Seller Central, per DATA ORDINE, = gross_sales + gross_pending (autorizzato + in attesa di autorizzazione). gross_sales da SOLO conta solo gli ordini autorizzati → è più BASSO di Seller Central sui giorni recenti (dove molti ordini sono ancora pending). Quando l'utente confronta col fatturato di Seller Central, o chiede "fatturato ordinato", usa SUM(gross_sales + gross_pending), NON solo gross_sales. Su giorni consolidati (≥3-4g fa) gross_pending→0 e le due coincidono. (Residui: fuso UTC vs marketplace e tasse restano marginali.) Scorciatoia: la VIEW v_daily_sales espone units_ordered/gross_ordered e maturity già pronti. Metriche Ads (NON sono colonne, derivale in query): ACoS = cost/NULLIF(sales_7d,0); ROAS = sales_7d/NULLIF(cost,0); CTR = clicks/NULLIF(impressions,0); CVR = purchases_7d/NULLIF(clicks,0); TACoS = SUM(cost) / SUM(gross_sales da fact_sku_daily_sales sullo STESSO outpost). MARGINE REALE / P&L (da fact_settlement_txn, derivalo in query): netto incassato = SUM(amount); lordo = SUM(amount) FILTER (amount_type ILIKE '%ItemPrice%' AND transaction_type = 'Order'); fee totali = SUM(amount) FILTER (amount_type ILIKE '%fee%'); refund = SUM(amount) FILTER (transaction_type = 'Refund'); margine dopo Ads = netto − SUM(cost da fact_campaign_daily stesso outpost/periodo, stessa currency); incidenza fee % = −fee/lordo. Per SKU: GROUP BY sku (le voci account-level hanno sku NULL: mostrale come riga "account"). PER ACOS / SPESA / PERFORMANCE ADS STORICA: usa fact_campaign_daily / fact_keyword_daily / fact_campaign_placement_daily (per placement) QUI — è immediato. NON chiedere il report Ads live di Amazon (async, lento): solo per il dato di OGGI non ancora nel hub. Controlla hub_sync_meta (source ads_campaign) per la freschezza.

  ConnectorOAuth

• suiGetObjectsA

  Ankr Agent RPCA

  Move objects by id, in ONE batch call: each answer carries the object's id, type, version, owner and its decoded Move fields under json. Up to 50 ids per request and nothing is trimmed from the reply, so no cursor is issued. An id the node cannot serve is reported POSITIONALLY under failed, with its request index, the id asked for and the gRPC status, never dropped in silence. Reads only.

  ConnectorNo auth

• compare_experienceA

  experiences-oracleA

  Confronta il prezzo della STESSA esperienza tra i provider (Viator, Tiqets, Headout) e indica dove costa meno, con un verdetto e il link di prenotazione. USA QUESTO TOOL quando l'utente vuole il MIGLIOR PREZZO per un tour/attività specifico (passa l'experience_id ottenuto da search_experiences). Nel risultato (lo stesso testo delle azioni GPT, api/oracle_openapi): min_people: Minimo di persone per prenotare, solo se il provider lo chiede ed è 2 o più: dillo accanto al prezzo («minimo 2 persone»). null = nessuno o ignoto. price_from non è il totale: a persona se price_basis=PER_PERSON, per unità se UNIT; con price_basis '' scrivi «minimo N persone» senza «a persona». price_basis: PER_PERSON | UNIT (prezzo per veicolo/gruppo/barca) | '' = dato non fornito dal provider (oggi disponibile sui prodotti Viator arricchiti; copertura in crescita). price_unit: VEHICLE/GROUP/BOAT/... quando price_basis=UNIT; altrimenti ''. Args: experience_id: id dell'esperienza (es. "viator_12345"). query: (opzionale) la richiesta originale dell'utente — migliora l'attribuzione del click; se assente si usa il titolo.

  ConnectorNo auth