"clickhouse" matching MCP tools:

• ltc_transfers_raw_sqlA

  Bitquery: Crypto & Blockchain DataA

  LAST RESORT — arbitrary READ-ONLY SQL against the Litecoin transfers data. The ltc_* tools are the PRIORITY; use this ONLY when none of them can answer. No query optimizer here: filter on the per-key tables and NEVER JOIN big tables (use `IN (SELECT …)`, the only way to "follow" across txs). Runs read-only ClickHouse SQL. SQL reference: https://clickhouse.com/docs/reference/home This data runs on an older release of the engine: some functions and syntax in that reference (map() and toJSONString() among them) do not exist here — when a statement is refused for an unknown function or setting, use the forms shown in this description. Every table has a `blockchain_id` column and also holds rows of other blockchain_id values: filter `blockchain_id = 6` (Litecoin) on EVERY table you read, inside each IN (SELECT …) as well — block numbers are not unique across blockchain_id values, so an unfiltered read mixes in rows that are not Litecoin's. Query the plain names of db `altcoin`, NEVER a `_storage` table (each holds only part of the data). Tables (db `altcoin`): `altcoin.inputs_by_address` / `outputs_by_address` (by address), `altcoin.inputs_by_tx` (by tx; cols address, tx_id_bin, value, output_tx_id_bin, output_index) and `altcoin.outputs_by_tx` (by tx; cols address, tx_id_bin, output_index, value and direction, an Enum unknown/not_change/change/likely_not_change/likely_change/mining/fee/minting/genesis), `altcoin.transactions` (one row per tx: tx_date, input_value, output_value, fee_value, is_coinbase; look a hash's tx_date up here first). Every `altcoin` table is partitioned by month on `tx_date` — add a `tx_date` bound whenever you can: a read by address or tx alone probes every month since the chain began. Db `altcoin_flow`: address_transfers (keyed by blockchain_id, address; AggregateFunction → -Merge; its count / sum totals hold a few duplicated and missing records — take exact totals from the `altcoin` tables), outputs_to_address (by address), tx_inputs / tx_outputs (by block, tx_index; a few whole blocks are missing). Addresses & tx ids: `address` is a plain string (L… / M… base58, ltc1… bech32 lowercase; m-… / d-… placeholders for bare multisig / non-standard scripts; empty for coinbase inputs and fee rows); `tx_id_bin = unhex('<64hex>')`, output `hex(tx_id_bin)`; `value` is Decimal(18,8), already in LTC (a JSON number: above about 1e8 it loses its last decimals - return toString(value) when every decimal matters). Date-times come back as 'YYYY-MM-DD hh:mm:ss' UTC; select formatDateTime(tx_time, '%FT%TZ') for ISO-8601 (2026-09-21T15:04:18Z), the shape the other tools return. Address labels: none in this data — use labels_for_addresses(chain='litecoin'). Read-only; JSONEachRow. A result of more than 25,000 rows is not cut off - the whole query fails with an error - so aggregate (GROUP BY, count) or add a LIMIT of at most 25,000. 64-bit integers come back as JSON numbers, exact only up to 2^53: return a hash such as cityHash64(...) or any other 64-bit id as toString(x).

  ConnectorOAuth

• database_tools_execute_queryA

  Point Topic — UK Broadband Market ReferenceA

  Query Point Topic's public broadband ontology (ClickHouse) — read-only. Exposes the public reference tables (the visitor view): the entity graph of ISPs, network operators, networks, links, link standards and their relationships. Discover tables with SHOW TABLES FROM ontology; inspect columns with DESCRIBE TABLE <name>. Licensed measurement data (footprints, premises, speeds, tariffs, forecasts, take-up, subscribers) is not queryable here and requires a Point Topic licence — denied queries return contact details. Only SELECT/WITH/SHOW/DESCRIBE/EXPLAIN allowed; returns CSV (large results are truncated at ~50k tokens with a leading notice — add LIMIT to keep results small).

  ConnectorNo auth

• arbitrum_transfers_raw_sqlA

  Bitquery: Crypto & Blockchain DataA

  LAST RESORT — arbitrary READ-ONLY SQL against the Arbitrum transfers database. The Bitquery MCP specialized arbitrum_* tools are the PRIORITY; use this ONLY when none of them can answer (e.g. an uncovered table). No query optimizer here — naive SQL full-scans huge tables and JOINs time out. Runs read-only ClickHouse SQL. SQL reference: https://clickhouse.com/docs/reference/home FAST-QUERY RULES: filter on the indexed key tables — `arbitrum_api.transfers_sender` (by sender / outgoing), `arbitrum_api.transfers_receiver` (by receiver / incoming), `arbitrum_api.transfers_tx` (by tx hash); NEVER JOIN big tables — use `WHERE col IN (SELECT …)` (use `GLOBAL IN` when the subquery is referenced inside another subquery, otherwise its result is not available where it is used). A subquery that itself reads a transfers table (`IN (SELECT Transfer_Sender FROM …transfers_… WHERE …)`) is re-run for every shard and rescans that table — run it as its OWN query first, then pass the result back as a literal list (`IN (unhex('a'), unhex('b'))`). To filter transfers by a specific token, read `transfers_currency` (keyed by the token contract + `Block_Time`); `transfers_sender` / `transfers_receiver` are keyed by address, so filtering those by a token contract scans the table. Addresses are RAW BYTES `FixedString(20)` in `Transfer_Sender` / `Transfer_Receiver` (there are NO plain string address columns) → `Transfer_Sender = unhex(substring(lower('0x…'),3))`, output `concat('0x',lower(hex(col)))`. Tx hash is `Transaction_Hash` `FixedString(32)` (same unhex/hex pattern). A SET of hashes or addresses must have the column's exact type: `Transaction_Hash IN (SELECT toFixedString(unhex(h), 32) FROM …)`, `toFixedString(…, 20)` for an address. A plain `unhex(…)` set, or a JOIN on a String key, silently misses every value ending in `00`; `=` and a literal list `IN (unhex('a'), unhex('b'))` are safe. Currency symbol + decimals are INLINE columns (no dictionaries): amount = `toFloat64(Transfer_Amount) / pow(10, Transfer_Currency_Decimals)`; symbol = `Transfer_Currency_Symbol`; token contract = `Transfer_Currency_SmartContract` — itself RAW BYTES in a `String` column (not text), so filter it `= unhex('<40 hex, no 0x>')` and read it back `concat('0x',lower(hex(…)))`; a `'0x…'` text literal matches nothing. Always add `AND Transfer_Success = 1`. `Transfer_Type`: 'token' = a token transfer, 'transaction' = a plain native-coin send, 'call' = native coin moved by a call. A transaction's OWN value transfer is stored either as 'transaction' or as a 'call' with `Call_Index = 0`; only a 'call' with `Call_Index != 0` is an INTERNAL transfer (made by contract code deeper inside the transaction). For top-level transfers filter `(Transfer_Type IN ('token','transaction') OR (Transfer_Type = 'call' AND Call_Index = 0))` - `Transfer_Type IN ('token','transaction')` alone drops a large share of ordinary sends. Time = `Block_Time`. Date-time values come back as ISO-8601 UTC, e.g. 2026-09-21T15:04:18Z (toString() of a date-time gives 2026-09-21 15:04:18). Other `arbitrum_api.*` tables (calls, transactions, balances) are reachable with an explicit db prefix. Counterparty labels are NOT in this database — use labels_for_addresses. Read-only; always add a LIMIT of at most 10,000 — a larger answer fails with an error, so aggregate (GROUP BY, count) instead. 64-bit integers come back as JSON numbers, exact only up to 2^53: return a hash such as cityHash64(...) or any other 64-bit id as toString(x). Exact table and column names first: chain_list_tables, chain_describe_table and chain_search_columns with database=arbitrum_api.

  ConnectorOAuth

• btc_transfers_raw_sqlA

  Bitquery: Crypto & Blockchain DataA

  LAST RESORT — arbitrary READ-ONLY SQL against the Bitcoin transfers databases (`bitcoin`, `bitcoin_flow`). Bitquery MCP btc_* tools are the PRIORITY; use this ONLY when none can answer. No query optimizer here: query the per-key tables and NEVER JOIN big tables (use `IN (SELECT …)`, the only way to "follow" across txs). Runs read-only ClickHouse SQL. SQL reference: https://clickhouse.com/docs/reference/home This data runs on an older release of the engine: some functions and syntax in that reference (map() and toJSONString() among them) do not exist here — when a statement is refused for an unknown function or setting, use the forms shown in this description. Addresses & tx ids: `address` is a plain string (base58/bech32); `tx_id_bin = unhex('<64hex>')`, output `hex(tx_id_bin)`; `value` is Decimal(18,8), already in BTC. Date-times come back as 'YYYY-MM-DD hh:mm:ss' UTC; select formatDateTime(tx_time, '%FT%TZ') for ISO-8601 (2026-09-21T15:04:18Z), the shape the other tools return. Key tables (db `bitcoin`): inputs_by_address / outputs_by_address (by address), inputs_by_tx (by tx; cols address, tx_id_bin, value, output_tx_id_bin, output_index) / outputs_by_tx (by tx; cols address, tx_id_bin, output_index, value and direction, an Enum unknown/not_change/change/likely_not_change/likely_change/mining/fee), omni_transfers_* ; (db `bitcoin_flow`): address_transfers (AggregateFunction → -Merge). Address labels: none in this data — use labels_for_addresses(chain='bitcoin'). Read-only; JSONEachRow. A result of more than 25,000 rows is not cut off - the whole query fails with an error - so aggregate (GROUP BY, count) or add a LIMIT of at most 25,000. 64-bit integers come back as JSON numbers, exact only up to 2^53: return a hash such as cityHash64(...) or any other 64-bit id as toString(x).

  ConnectorOAuth

• execute_sqlA

  Bitquery: Crypto & Blockchain DataA

  ESCAPE HATCH — read-only SQL for what NO tool answers: custom cohort backtests beyond launch_cohort, multi-step joins, quantiles. Check the tools first; they are keyed and far cheaper: - token_price, token_ohlcv, pair_ohlcv, currency_ohlcv, token_trade_bars (30 s to 1 h buy/sell bars) - new_tokens, launch_cohort, token_launch_stats, early_buyers, token_dex_venues, pool_recent_trades - trader_trades, trader_profile, trader_positions, trader_activity, top_traders_by_token - list_tables, describe_table, search_columns before writing a query - Hyperliquid (the perp exchange) is NOT in this database at all: its markets, funding, liquidations and traders are the hyperliquid_* tools, and its own hatch is hyperliquid_raw_sql After a tool answers, keep going with tools; use SQL only for the step none can do. Runs read-only ClickHouse SQL. SQL reference: https://clickhouse.com/docs/reference/home Scope: only the trading_rt database — DEX trades and 1 s to 1 h bars per token, pair, pool and currency, last ~30 days, 10 chains. Other visible databases are internal and unsupported: do not query them. Address labels and per-chain transfers are not here: use the label and <chain>_ tools. Rules: - Names are case-sensitive, not GraphQL fields or tool output names: trades_* use Pair_Token_Address / Pair_Token_Network / Pair_Token_Symbol (quote side Pair_QuoteToken_*), tokens_* and pairs_* Token_*; confirm with describe_table. - Use the *_by_<key> table that matches your filter, filter its leading sort keys, and on trades_* bound Block_Date too. - Bars: Interval_VolumeBased = 0; Price_IsQuotedInUsd = 1 for USD. - Windows on *_by_interval_start: enumerate the hour starts, Interval_Time_Start IN (SELECT arrayJoin(arrayMap(h -> toStartOfHour(now()) - toIntervalHour(h), range(24)))) AND Interval_Time_Duration = 3600; a >= range reads every duration. - One tokens_* hour can be stored twice: on multi-token scans add Token_Did = '' (never on a single-address lookup); take the current and previous hour as argMax(Volume_Usd, Indexing_Time) per token; never GROUP BY Token_Name / Token_Symbol. - Amounts are decimal-adjusted; USD: AmountsInUsd_Base / AmountsInUsd_Quote / PriceInUsd; Side = what the trader received; Supply_MarketCap = the diluted value when Supply_CirculatingSupply = 0. - EVM addresses are lowercase 0x-hex, Solana/Tron base58 case-sensitive. Use UNION ALL; always add a LIMIT. Dates and times come back as ISO-8601 UTC (a Date as T00:00:00Z).

  ConnectorOAuth

• matic_transfers_raw_sqlA

  Bitquery: Crypto & Blockchain DataA

  LAST RESORT — arbitrary READ-ONLY SQL against the Polygon transfers database. The Bitquery MCP specialized matic_* tools are the PRIORITY; use this ONLY when none of them can answer (e.g. an uncovered table). No query optimizer here — naive SQL full-scans huge tables and JOINs time out. Runs read-only ClickHouse SQL. SQL reference: https://clickhouse.com/docs/reference/home FAST-QUERY RULES: filter on the indexed key tables — `matic_api.transfers_sender` (by sender / outgoing), `matic_api.transfers_receiver` (by receiver / incoming), `matic_api.transfers_tx` (by tx hash); NEVER JOIN big tables — use `WHERE col IN (SELECT …)` (use `GLOBAL IN` when the subquery is referenced inside another subquery, otherwise its result is not available where it is used). A subquery that itself reads a transfers table (`IN (SELECT Transfer_Sender FROM …transfers_… WHERE …)`) is re-run for every shard and rescans that table — run it as its OWN query first, then pass the result back as a literal list (`IN (unhex('a'), unhex('b'))`). To filter transfers by a specific token, read `transfers_currency` (keyed by the token contract + `Block_Time`); `transfers_sender` / `transfers_receiver` are keyed by address, so filtering those by a token contract scans the table. Addresses are RAW BYTES `FixedString(20)` in `Transfer_Sender` / `Transfer_Receiver` (there are NO plain string address columns) → `Transfer_Sender = unhex(substring(lower('0x…'),3))`, output `concat('0x',lower(hex(col)))`. Tx hash is `Transaction_Hash` `FixedString(32)` (same unhex/hex pattern). A SET of hashes or addresses must have the column's exact type: `Transaction_Hash IN (SELECT toFixedString(unhex(h), 32) FROM …)`, `toFixedString(…, 20)` for an address. A plain `unhex(…)` set, or a JOIN on a String key, silently misses every value ending in `00`; `=` and a literal list `IN (unhex('a'), unhex('b'))` are safe. Currency symbol + decimals are INLINE columns (no dictionaries): amount = `toFloat64(Transfer_Amount) / pow(10, Transfer_Currency_Decimals)`; symbol = `Transfer_Currency_Symbol`; token contract = `Transfer_Currency_SmartContract` — itself RAW BYTES in a `String` column (not text), so filter it `= unhex('<40 hex, no 0x>')` and read it back `concat('0x',lower(hex(…)))`; a `'0x…'` text literal matches nothing. Always add `AND Transfer_Success = 1`. `Transfer_Type`: 'token' = a token transfer, 'transaction' = a plain native-coin send, 'call' = native coin moved by a call. A transaction's OWN value transfer is stored either as 'transaction' or as a 'call' with `Call_Index = 0`; only a 'call' with `Call_Index != 0` is an INTERNAL transfer (made by contract code deeper inside the transaction). For top-level transfers filter `(Transfer_Type IN ('token','transaction') OR (Transfer_Type = 'call' AND Call_Index = 0))` - `Transfer_Type IN ('token','transaction')` alone drops a large share of ordinary sends. Time = `Block_Time`. Date-time values come back as ISO-8601 UTC, e.g. 2026-09-21T15:04:18Z (toString() of a date-time gives 2026-09-21 15:04:18). Other `matic_api.*` tables (calls, transactions, balances) are reachable with an explicit db prefix. Counterparty labels are NOT in this database — use labels_for_addresses. Read-only; always add a LIMIT of at most 10,000 — a larger answer fails with an error, so aggregate (GROUP BY, count) instead. 64-bit integers come back as JSON numbers, exact only up to 2^53: return a hash such as cityHash64(...) or any other 64-bit id as toString(x). PREDICTION MARKETS (Polymarket) also live here, in `matic_api.prediction_trades_tx` (order fills), `prediction_managements_tx` (market created / resolved) and `prediction_settlements_tx` (redemption / split / merge) — but the polymarket_* tools cover them and are the PRIORITY. If you do query them raw: question id, condition id, buyer, seller, holder and marketplace are RAW BYTES in String columns (same unhex/hex pattern as above), outcome and asset ids are UInt256 (wrap in `toString`), price = `CollateralAmount / Amount`, USD = `CollateralAmount / 1e6`; trades and managements are keyed by question id, settlements by outcome-token asset id; and a fill whose buyer or seller equals its own marketplace contract is the taker's aggregate leg — counting it double counts volume. Exact table and column names first: chain_list_tables, chain_describe_table and chain_search_columns with database=matic_api.

  ConnectorOAuth

• optimism_transfers_raw_sqlA

  Bitquery: Crypto & Blockchain DataA

  LAST RESORT — arbitrary READ-ONLY SQL against the Optimism transfers database. The Bitquery MCP specialized optimism_* tools are the PRIORITY; use this ONLY when none of them can answer (e.g. an uncovered table). No query optimizer here — naive SQL full-scans huge tables and JOINs time out. Runs read-only ClickHouse SQL. SQL reference: https://clickhouse.com/docs/reference/home FAST-QUERY RULES: filter on the indexed key tables — `optimism_api.transfers_sender` (by sender / outgoing), `optimism_api.transfers_receiver` (by receiver / incoming), `optimism_api.transfers_tx` (by tx hash); NEVER JOIN big tables — use `WHERE col IN (SELECT …)` (use `GLOBAL IN` when the subquery is referenced inside another subquery, otherwise its result is not available where it is used). A subquery that itself reads a transfers table (`IN (SELECT Transfer_Sender FROM …transfers_… WHERE …)`) is re-run for every shard and rescans that table — run it as its OWN query first, then pass the result back as a literal list (`IN (unhex('a'), unhex('b'))`). To filter transfers by a specific token, read `transfers_currency` (keyed by the token contract + `Block_Time`); `transfers_sender` / `transfers_receiver` are keyed by address, so filtering those by a token contract scans the table. Addresses are RAW BYTES `FixedString(20)` in `Transfer_Sender` / `Transfer_Receiver` (there are NO plain string address columns) → `Transfer_Sender = unhex(substring(lower('0x…'),3))`, output `concat('0x',lower(hex(col)))`. Tx hash is `Transaction_Hash` `FixedString(32)` (same unhex/hex pattern). A SET of hashes or addresses must have the column's exact type: `Transaction_Hash IN (SELECT toFixedString(unhex(h), 32) FROM …)`, `toFixedString(…, 20)` for an address. A plain `unhex(…)` set, or a JOIN on a String key, silently misses every value ending in `00`; `=` and a literal list `IN (unhex('a'), unhex('b'))` are safe. Currency symbol + decimals are INLINE columns (no dictionaries): amount = `toFloat64(Transfer_Amount) / pow(10, Transfer_Currency_Decimals)`; symbol = `Transfer_Currency_Symbol`; token contract = `Transfer_Currency_SmartContract` — itself RAW BYTES in a `String` column (not text), so filter it `= unhex('<40 hex, no 0x>')` and read it back `concat('0x',lower(hex(…)))`; a `'0x…'` text literal matches nothing. Always add `AND Transfer_Success = 1`. `Transfer_Type`: 'token' = a token transfer, 'transaction' = a plain native-coin send, 'call' = native coin moved by a call. A transaction's OWN value transfer is stored either as 'transaction' or as a 'call' with `Call_Index = 0`; only a 'call' with `Call_Index != 0` is an INTERNAL transfer (made by contract code deeper inside the transaction). For top-level transfers filter `(Transfer_Type IN ('token','transaction') OR (Transfer_Type = 'call' AND Call_Index = 0))` - `Transfer_Type IN ('token','transaction')` alone drops a large share of ordinary sends. Time = `Block_Time`. Date-time values come back as ISO-8601 UTC, e.g. 2026-09-21T15:04:18Z (toString() of a date-time gives 2026-09-21 15:04:18). Other `optimism_api.*` tables (calls, transactions, balances) are reachable with an explicit db prefix. Counterparty labels are NOT in this database — use labels_for_addresses. Read-only; always add a LIMIT of at most 10,000 — a larger answer fails with an error, so aggregate (GROUP BY, count) instead. 64-bit integers come back as JSON numbers, exact only up to 2^53: return a hash such as cityHash64(...) or any other 64-bit id as toString(x). Exact table and column names first: chain_list_tables, chain_describe_table and chain_search_columns with database=optimism_api.

  ConnectorOAuth

• get_page_performanceA

  SEO GSC Wizard MCPA

  Use this when the user asks how one specific page performed day by day. Daily performance for a single page (clicks, impressions, CTR, position). Useful for diagnosing post-deploy regressions on a specific URL. Not for a ranking of pages: use query_top_pages. `pageUrl` must match the URL exactly. Rows run by date, oldest first; days without impressions are absent, not zero. `ctr` is a 0-100 percentage. Served from the ClickHouse warehouse when available, otherwise the live Search Console API (see `dataSource`). Date range is optional: omit startDate/endDate to analyze the last 28 settled days (data lags ~2-3 days).

  ConnectorOAuth

• get_ranking_changesA

  SEO GSC Wizard MCPA

  Use this when the user asks which queries or pages moved up or down between two periods: each is filed as new, lost, improved or declined (improved = better, lower average position). Not for pages losing clicks over time: use find_decaying_content. `limit` (1-10000, default 50) applies PER BUCKET; `counts` gives the full size of each bucket before that cut. Buckets run largest first: improved and declined by the size of `positionDelta` (prevPosition minus position; a new or lost key's missing side reads 0), new by clicks, lost by prevClicks. `ctr` is a 0-100 percentage. Each period reads its top `scanLimit` keys by clicks (warehouse: max(limit*10, 1000), capped at 50000; live API: 25000), and `counts` are measured within them. The warehouse reads every key in either period's top `scanLimit` in both periods, so new and lost are real; on the live API the reads are independent, so a key just below one cut can show as new or lost. Query movers are only the queries Google lists: on most properties a large share of clicks has no query row (analyze_sampling_impact measures it). Served from the GSC Wizard ClickHouse warehouse when available, otherwise the live Search Console API (see `dataSource`). Date range is optional: omit startDate/endDate to analyze the last 28 settled days (data lags ~2-3 days).

  ConnectorOAuth

• get_cross_site_summaryA

  SEO GSC Wizard MCPA

  Use this when the user asks how all their properties are doing, or which gained or lost most. Aggregates a last-N-days clicks/impressions summary across the account's registered Search Console properties (optionally filtered to those carrying a given tag), with a same-length prior period for comparison and per-site totals. Without a tag it also covers properties shared with the account (marked `shared: true`; tags are the caller's own, so a tag filter covers owned properties only). The MCP equivalent of the app's Global Reports page. Set `includeSearchTypes` to also split every property across web / image / video / news / discover, and `includeCountries` for a country leaderboard aggregated over the whole portfolio; their ctr and clickShare are 0-100. perSite and countries are sorted by clicks, descending. Each site routes independently to the ClickHouse warehouse or the live Search Console API, so `dataSource` is reported per site; a site whose read fails, or a share that no longer grants access, is reported in `errors` with a `reason` rather than failing the whole call, and the totals then cover only `sitesIncluded` properties, which `warning` says. Not for one property: use get_site_summary; for a tag's daily trend and top queries and pages use get_tag_group_view. Processes at most `maxSites` properties per call (default and maximum 100; `scope.truncated` says when more matched, so narrow by `tag`). The rate-limit cost scales with the number of properties and the breakdowns requested.

  ConnectorOAuth

• get_feed_audit_resultsA

  SEO GSC Wizard MCPA

  Use this when the user asks how their Merchant Center feed scored in the feed audit or which checks fail. Results of the Merchant Center feed audit for a GSC Wizard site: the latest run (or the run of a given runDate) with its status, Feed Score (0-100, split into scoreFeed and scorePage), failure counts by severity, per-check applicable / failed / passed counts with pass rates, offers audited, pages fetched and crawl coverage, plus the score history of earlier runs for the trend. checks run worst first (most failures), history newest first. coverage and the rates are 0-1 fractions (0.12 = 12%), not the 0-100 percentage ctr uses elsewhere. Not for Google's own item issues: use get_product_listing_status. checkKey narrows the checks list to one check; severity is accepted for parity with the app report, but the per-offer issue rows behind either filter live in the ClickHouse warehouse this server cannot read, so such a call answers `issuesAvailable: false`, pointing at the Feed Audit report in the GSC Wizard app. A run can cover several markets (one "<contentLanguage>~<feedLabel>" key each, e.g. "en~GB"): `run.markets` lists them, home market first, and `run.perMarket` gives each market's own offersAudited, score and severity counts; both are null on runs from before multi-market audits, and perMarket stays null until the run completes. The run-level score and checks combine every market the run covered; pass `market` with a key from run.markets to get that market's per-check counts in `checks` instead (a key the run does not cover answers a `marketNote` listing its markets, not an error). The owner picks the home market and up to 4 extra markets on the Feed Audit page in the GSC Wizard app; this server cannot change them. `run.crawlBlocked: true` means the page crawl stopped early because the site refused GSCWizard-Bot (401/403 or robots.txt), so the page-plane checks and scorePage cover few or no pages; allow the crawler and queue a new run. `run: null` means no audit has run yet, or none on runDate (queue one with run_feed_audit). `syncPaused` (with a one-line `staleNote`) means the Merchant Center sync is paused because Merchant Center no longer lets the connected Google account read the merchant: the stored results are still returned but may be stale, and `syncPaused.message` says how to fix it. `syncNotice` (reason "gmc_on_other_account") means Merchant Center is connected on another Google login than the property's Search Console one, so no new audit can run; stored results are still returned. Returns a `notConfigured` result (not an error) when Merchant Center is not connected, its credentials were revoked, no Merchant Center account is linked to the site, or (reason "gmc_on_other_account") no audit was ever stored because Merchant Center sits on another Google login.

  ConnectorOAuth

• get_webmasterA

  SpytrendA

  Fetch a single webmaster (affiliate NETWORK) by UUID: aggregate stats PLUS top_creatives — the creatives this webmaster re-uploads the MOST, ordered by the webmaster's OWN in-slice ad count (slice.ads_in_slice desc — the deliberate slice order, matching what the profile page shows), media stripped/free. Each entry's total_ads is the creative's market-wide family size, folded best-effort from family redirects and floored at ads_in_slice — total_ads == ads_in_slice therefore often means 'family cards not yet built', not 'this webmaster owns the whole market'; it is context, not the sort key. analytics_pending=true means the canonical PostgreSQL identity exists but its ClickHouse aggregate is not published yet, so zero counters are not analytical zeroes. fanpages_status explicitly reports advertiser-aligned lifecycle enrichment as available, partial, unavailable or not_applicable; an omitted fanpages array is therefore never evidence that a page is alive. The id MUST be the canonical UUID returned by search_webmasters; domain names and display names are rejected instead of silently widening to the whole database. Present top_creatives as the headline final step; for the rest of the network use search_creatives?webmaster_id / search_ads?webmaster_id, and download media with get_media (entity_type=creo). identifier_inventory_semantics explains why historical page/domain/pixel inventory counts are not comparable to total_ads. attribution_link_stats.merge_edges answers WHY these identifiers sit in one network: each entry is a {page_id, page_name, domain, ads} pair — that fanpage ran exactly that many ads on that landing domain, and such a pair is what merges two networks into one (an ad whose domain belongs to network A and whose fanpage belongs to network B fuses them permanently). Weigh the edges before claiming a single operator: a 1-3 ad edge next to 100+ ad edges is a thin bridge, typically a catalog/feed ad, and is weak evidence of shared ownership; identifiers with no edge at all are inherited from earlier merges and prove nothing today. QUOTA: 1 MCP credit (one entity card). TIKTOK: with source=tiktok this fetches the TikTok cluster card instead (business-id rollup, same UUID space as search_webmasters source=tiktok results) — ⚠️ costs 10 MCP credits and requires a Pro-or-higher plan; the Meta-only embeds (top_creatives, attribution link-stats) are omitted on the TikTok card. PRICING: on paid plans ×1 after 500 MCP credits/month; one-time consent via accept_pricing_terms; before calling, get the maximum debit from estimate_cost (free) and tell the user.

  ConnectorOAuth

• create_relational_databaseA

  mcpA

  Provisions a managed MySQL (or MariaDB) database on a dedicated VM on your private network - the relational-database resource (use this instead of create_database when the app needs MySQL/MariaDB, e.g. WordPress, NextCloud, Matomo, many PHP/LAMP apps). Requires a recent plan_managed_datastore. For app deployments, prefer deploy_app database:'managed' with db_engine mysql/mariadb so plan_deploy includes and wires the DB automatically. It is PRIVATE - reachable only from another instance on the same private network, via the DB's internal/private IP (port 3306), not a public address. Get the ids from plan_managed_datastore/list_flavors/list_private_networks/list_keypairs. Provisioning takes ~5 min; poll list_relational_databases until status='ready', then the connection details (private_ip, port 3306, db_name, db_user) are populated. MySQL is created with mysql_native_password auth so older clients/apps connect cleanly. (ClickHouse is a separate resource - use create_clickhouse / list_clickhouse_databases.)

  ConnectorNo auth

• create_clickhouseA

  mcpA

  Provisions a managed ClickHouse database (OLAP / columnar analytics engine, Apache-2.0) on a dedicated VM on your private network - its OWN resource, NOT a relational database. Requires a recent plan_managed_datastore. Use it for analytics / observability workloads that need a column store (PostHog, Langfuse, event analytics, time-series). It is PRIVATE - reachable only from another instance on the same private network, via the DB's internal/private IP on the ClickHouse HTTP port 8123 (CLICKHOUSE_HOST/PORT/USER/PASSWORD/DB env, http://host:8123). Get the ids from plan_managed_datastore/list_flavors (use m1.small+ - ClickHouse needs >=2GB RAM), list_private_networks, list_keypairs. Provisioning takes ~5 min; poll list_clickhouse_databases until status='ready'. HIGH AVAILABILITY: pass ha:true to get THREE machines on three different physical hosts behind a load balancer instead of one: all three take reads and writes, so losing a machine costs no failover and no write pause, and the replacement refills itself from the survivors before it serves again. It costs about 3x the hourly rate (three machines instead of one) and provisions more slowly. Default is a single machine; show the user the price difference and get an explicit yes before turning HA on.

  ConnectorNo auth

• upgrade_to_haA

  mcpA

  Turns an EXISTING, running single-machine managed Postgres or ClickHouse into a THREE-machine highly available cluster, in place, keeping the data and the same username, password and database name. Use this when the user has a live database and wants it to survive a machine or host failure: they do NOT have to create a new one and migrate by hand. How it works: a full backup is taken first (a safety copy while the upgrade runs, deleted when it ends: the old machine is never touched and stays the restore point), the cluster is built alongside, the data is copied in and verified by counting both sides, and only then does the database's address move to the load balancer. The original machine is left running and untouched throughout, so a failure changes nothing and the user is never without a database. SAY THREE THINGS TO THE USER AND GET A YES BEFORE CALLING: (1) COST, it becomes three machines behind a load balancer instead of one, so roughly 3x the hourly rate, and the old single machine keeps billing for 3 days, until it is removed automatically; (2) WRITE LOSS, anything written to the old machine during the copy is not carried over (see acknowledge_write_loss); (3) THEY MUST REPOINT THE APP afterwards, the connection address changes and nothing redeploys their app for them. Takes about 20 minutes and returns immediately; poll list_databases / list_clickhouse_databases until the address changes. Requires a payment method: high availability is not available on the no-card trial. ⛔ CLICKHOUSE ONLY, a FOURTH thing to say: after the upgrade every table has to use a REPLICATED engine. The existing tables are converted for them as part of the copy, but any NEW `CREATE TABLE ... ENGINE = MergeTree` is refused from then on (ClickHouse error 56) and has to be written `ENGINE = ReplicatedMergeTree`. It is refused rather than accepted because a plain MergeTree on three machines replicates its schema and not its rows, which would leave two of the three answering with an empty table and no error. If their app ships plain-MergeTree migrations (Plausible, PostHog and Langfuse all do), those migrations will fail after the upgrade and they should stay on the single machine. For the app tier rather than the database, use upgrade_to_cluster instead.

  Connector

  Destructive

  No auth

• agents_traces_statsA

  DialogBrainB

  Aggregated trace statistics for one agent over the last N days — total runs, success rate, avg duration, error breakdown, top tools used, runs-per-day histogram, and what the agent spent. `spend` totals the agent's LLM usage over the same window: `llm_calls`, `tokens_input`, `tokens_output`, `cost_usd`, and `own_key_cost_usd` (the slice paid with the workspace's own vendor key, included in cost_usd rather than added to it). It covers usage recorded since per-agent attribution shipped, so it reads 0 for older runs; null means the lookup could not run. Use this when you want a bird's-eye view of an agent's health before diving into individual traces with `agents.traces_list` / `agents.trace_get`. Scoped to the target agent (exact match, no substring bleed). `days` is capped at 30 — matches the ClickHouse request_traces TTL.

  ConnectorAPI key

• agents_traces_statsA

  dialogbrainB

  Aggregated trace statistics for one agent over the last N days — total runs, success rate, avg duration, error breakdown, top tools used, runs-per-day histogram, and what the agent spent. `spend` totals the agent's LLM usage over the same window: `llm_calls`, `tokens_input`, `tokens_output`, `cost_usd`, and `own_key_cost_usd` (the slice paid with the workspace's own vendor key, included in cost_usd rather than added to it). It covers usage recorded since per-agent attribution shipped, so it reads 0 for older runs; null means the lookup could not run. Use this when you want a bird's-eye view of an agent's health before diving into individual traces with `agents.traces_list` / `agents.trace_get`. Scoped to the target agent (exact match, no substring bleed). `days` is capped at 30 — matches the ClickHouse request_traces TTL.

  ConnectorAPI key

• agents_traces_statsA

  dialogbrainB

  Aggregated trace statistics for one agent over the last N days — total runs, success rate, avg duration, error breakdown, top tools used, runs-per-day histogram, and what the agent spent. `spend` totals the agent's LLM usage over the same window: `llm_calls`, `tokens_input`, `tokens_output`, `cost_usd`, and `own_key_cost_usd` (the slice paid with the workspace's own vendor key, included in cost_usd rather than added to it). It covers usage recorded since per-agent attribution shipped, so it reads 0 for older runs; null means the lookup could not run. Use this when you want a bird's-eye view of an agent's health before diving into individual traces with `agents.traces_list` / `agents.trace_get`. Scoped to the target agent (exact match, no substring bleed). `days` is capped at 30 — matches the ClickHouse request_traces TTL.

  ConnectorAPI key

• bch_transfers_raw_sqlA

  Bitquery: Crypto & Blockchain DataA

  LAST RESORT — arbitrary READ-ONLY SQL against the Bitcoin Cash transfers data. The bch_* tools are the PRIORITY; use this ONLY when none of them can answer. No query optimizer here: filter on the per-key tables and NEVER JOIN big tables (use `IN (SELECT …)`, the only way to "follow" across txs). Runs read-only ClickHouse SQL. SQL reference: https://clickhouse.com/docs/reference/home This data runs on an older release of the engine: some functions and syntax in that reference (map() and toJSONString() among them) do not exist here — when a statement is refused for an unknown function or setting, use the forms shown in this description. Tables (db `bitcash`): `bitcash.inputs_by_address` / `outputs_by_address` (by address), `bitcash.inputs_by_tx` (by tx; cols address, tx_id_bin, value, output_tx_id_bin, output_index) and `bitcash.outputs_by_tx` (by tx; cols address, tx_id_bin, output_index, value and direction, an Enum unknown/not_change/change/likely_not_change/likely_change/mining/fee), `bitcash.transactions` (one row per tx: tx_date, input_value, output_value, fee_value, is_coinbase; look a hash's tx_date up here first). Every `bitcash` table is partitioned by month on `tx_date` — add a `tx_date` bound whenever you can: a read by address or tx alone probes every month since the chain began. Db `bitcash_flow`: address_transfers (keyed by address; AggregateFunction → -Merge; its count / sum totals hold a few duplicated and missing records — take exact totals from the `bitcash` tables), outputs_to_address (by address), tx_inputs / tx_outputs (by block, tx_index; a few whole blocks are missing). Addresses & tx ids: `address` is a plain string (CashAddr q… / p… lowercase WITHOUT the bitcoincash: prefix; m-… / d-… placeholders for bare multisig / non-standard scripts; empty for coinbase inputs and fee rows); `tx_id_bin = unhex('<64hex>')`, output `hex(tx_id_bin)`; `value` is Decimal(18,8), already in BCH (a JSON number: above about 1e8 it loses its last decimals - return toString(value) when every decimal matters). Date-times come back as 'YYYY-MM-DD hh:mm:ss' UTC; select formatDateTime(tx_time, '%FT%TZ') for ISO-8601 (2026-09-21T15:04:18Z), the shape the other tools return. Address labels: none in this data — use labels_for_addresses(chain='bitcoin-cash'). Read-only; JSONEachRow. A result of more than 25,000 rows is not cut off - the whole query fails with an error - so aggregate (GROUP BY, count) or add a LIMIT of at most 25,000. 64-bit integers come back as JSON numbers, exact only up to 2^53: return a hash such as cityHash64(...) or any other 64-bit id as toString(x).

  ConnectorOAuth

• dash_transfers_raw_sqlA

  Bitquery: Crypto & Blockchain DataA

  LAST RESORT — arbitrary READ-ONLY SQL against the Dash transfers data. The dash_* tools are the PRIORITY; use this ONLY when none of them can answer. No query optimizer here: filter on the per-key tables and NEVER JOIN big tables (use `IN (SELECT …)`, the only way to "follow" across txs). Runs read-only ClickHouse SQL. SQL reference: https://clickhouse.com/docs/reference/home This data runs on an older release of the engine: some functions and syntax in that reference (map() and toJSONString() among them) do not exist here — when a statement is refused for an unknown function or setting, use the forms shown in this description. Every table has a `blockchain_id` column and also holds rows of other blockchain_id values: filter `blockchain_id = 7` (Dash) on EVERY table you read, inside each IN (SELECT …) as well — block numbers are not unique across blockchain_id values, so an unfiltered read mixes in rows that are not Dash's. Query the plain names of db `altcoin`, NEVER a `_storage` table (each holds only part of the data). Tables (db `altcoin`): `altcoin.inputs_by_address` / `outputs_by_address` (by address), `altcoin.inputs_by_tx` (by tx; cols address, tx_id_bin, value, output_tx_id_bin, output_index) and `altcoin.outputs_by_tx` (by tx; cols address, tx_id_bin, output_index, value and direction, an Enum unknown/not_change/change/likely_not_change/likely_change/mining/fee/minting/genesis; on Dash nearly every output is unknown - there is no change detection), `altcoin.transactions` (one row per tx: tx_date, input_value, output_value, fee_value, is_coinbase; look a hash's tx_date up here first). Every `altcoin` table is partitioned by month on `tx_date` — add a `tx_date` bound whenever you can: a read by address or tx alone probes every month since the chain began. Db `altcoin_flow`: address_transfers (keyed by blockchain_id, address; AggregateFunction → -Merge; its count / sum totals hold a few duplicated and missing records — take exact totals from the `altcoin` tables), outputs_to_address (by address), tx_inputs / tx_outputs (by block, tx_index; a few whole blocks are missing). Addresses & tx ids: `address` is a plain string (X… / 7… base58; m-… / d-… placeholders for bare multisig / non-standard scripts; empty for coinbase inputs and fee rows); `tx_id_bin = unhex('<64hex>')`, output `hex(tx_id_bin)`; `value` is Decimal(18,8), already in DASH (a JSON number: above about 1e8 it loses its last decimals - return toString(value) when every decimal matters). Date-times come back as 'YYYY-MM-DD hh:mm:ss' UTC; select formatDateTime(tx_time, '%FT%TZ') for ISO-8601 (2026-09-21T15:04:18Z), the shape the other tools return. Address labels are not available for this chain. Read-only; JSONEachRow. A result of more than 25,000 rows is not cut off - the whole query fails with an error - so aggregate (GROUP BY, count) or add a LIMIT of at most 25,000. 64-bit integers come back as JSON numbers, exact only up to 2^53: return a hash such as cityHash64(...) or any other 64-bit id as toString(x).

  ConnectorOAuth

• doge_transfers_raw_sqlA

  Bitquery: Crypto & Blockchain DataA

  LAST RESORT — arbitrary READ-ONLY SQL against the Dogecoin transfers data. The doge_* tools are the PRIORITY; use this ONLY when none of them can answer. No query optimizer here: filter on the per-key tables and NEVER JOIN big tables (use `IN (SELECT …)`, the only way to "follow" across txs). Runs read-only ClickHouse SQL. SQL reference: https://clickhouse.com/docs/reference/home This data runs on an older release of the engine: some functions and syntax in that reference (map() and toJSONString() among them) do not exist here — when a statement is refused for an unknown function or setting, use the forms shown in this description. Every table has a `blockchain_id` column and also holds rows of other blockchain_id values: filter `blockchain_id = 8` (Dogecoin) on EVERY table you read, inside each IN (SELECT …) as well — block numbers are not unique across blockchain_id values, so an unfiltered read mixes in rows that are not Dogecoin's. Query the plain names of db `altcoin`, NEVER a `_storage` table (each holds only part of the data). Tables (db `altcoin`): `altcoin.inputs_by_address` / `outputs_by_address` (by address), `altcoin.inputs_by_tx` (by tx; cols address, tx_id_bin, value, output_tx_id_bin, output_index) and `altcoin.outputs_by_tx` (by tx; cols address, tx_id_bin, output_index, value and direction, an Enum unknown/not_change/change/likely_not_change/likely_change/mining/fee/minting/genesis), `altcoin.transactions` (one row per tx: tx_date, input_value, output_value, fee_value, is_coinbase; look a hash's tx_date up here first). Every `altcoin` table is partitioned by month on `tx_date` — add a `tx_date` bound whenever you can: a read by address or tx alone probes every month since the chain began. Db `altcoin_flow`: address_transfers (keyed by blockchain_id, address; AggregateFunction → -Merge; its count / sum totals hold a few duplicated and missing records — take exact totals from the `altcoin` tables), outputs_to_address (by address), tx_inputs / tx_outputs (by block, tx_index; a few whole blocks are missing). Addresses & tx ids: `address` is a plain string (D… / A… / 9… base58; m-… / d-… placeholders for bare multisig / non-standard scripts; empty for coinbase inputs and fee rows); `tx_id_bin = unhex('<64hex>')`, output `hex(tx_id_bin)`; `value` is Decimal(18,8), already in DOGE (a JSON number: above about 1e8 it loses its last decimals - return toString(value) when every decimal matters). Date-times come back as 'YYYY-MM-DD hh:mm:ss' UTC; select formatDateTime(tx_time, '%FT%TZ') for ISO-8601 (2026-09-21T15:04:18Z), the shape the other tools return. Address labels: none in this data — use labels_for_addresses(chain='dogecoin'). Read-only; JSONEachRow. A result of more than 25,000 rows is not cut off - the whole query fails with an error - so aggregate (GROUP BY, count) or add a LIMIT of at most 25,000. 64-bit integers come back as JSON numbers, exact only up to 2^53: return a hash such as cityHash64(...) or any other 64-bit id as toString(x).

  ConnectorOAuth