Skip to main content
Glama
306,645 tools. Last updated 2026-07-25 17:41

"Palo Alto Networks" matching MCP tools:

  • Get comprehensive token screening data across multiple blockchain networks with advanced filtering. A maximum of 25 results are returned out of 1000s of tokens. Use the sorting and filtering options to narrow down the results. A maximum of 5 chains can be specified per request (excess chains are automatically trimmed). This tool helps with token discovery and finding trending tokens by combining different metrics: volume, liquidity, market cap, smart money activity, and token age. **IMPORTANT - Hyperliquid Special Case:** - Hyperliquid chain queries perpetual futures (perps), not spot tokens - When hyperliquid is mixed with other chains, two sections of up to 25 results each are returned - one for spot tokens and one for perps. - For perps, only these filters are supported: volume, buyVolume, sellVolume, openInterest, netflow, nofTraders, traderType - Additional orderBy fields for perps: openInterest, funding - Unsupported filters/orderBy will fallback to defaults INPUT EXAMPLES: # Find tokens which are going up in price. # Added some liquidity filter to remove spam and low quality tokens. ``` { "chains": ["ethereum", "solana", "bnb", "base"], "timeframe": "24h", "liquidity": {"from": 100000}, "nofTraders": {"from": 10}, "orderBy": "price_change", "orderByDirection": "desc" } ``` # Find top stablecoins by market cap ``` { "chains": ["ethereum", "solana", "bnb", "base"], "timeframe": "7d", "sectors": ["Stablecoin"], "orderBy": "market_cap_usd", "orderByDirection": "desc" } ``` # Find AI memecoins with high trading activity { "chains": ["ethereum", "solana", "bnb", "base"], "timeframe": "7d", "sectors": ["AI Meme"], "liquidity": {"from": 100000}, "volume": {"from": 1000000} } # Find DeFi lending tokens { "chains": ["ethereum", "solana", "bnb", "base"], "timeframe": "24h", "sectors": ["DeFi Lending (Money Markets)"], "netflow": {"from": 1000000} } # Find tokens which have a lot of buying activity (high nofBuyers and buyVolume) # Note that we added some filters to remove spam and low quality tokens. We added liquidity filter so that we only surface tokens which we can buy or sell. # We sort by `netflow` descending to get tokens with the most net buying activity. ``` { "chains": ["ethereum", "solana", "bnb", "base"], "timeframe": "24h", "liquidity": {"from": 100000}, "buyVolume": {"from": 1000000}, "marketCapUsd": {"from": 1000000}, "nofBuyers": {"from": 10}, "orderBy": "netflow", "orderByDirection": "desc" } ``` # Find Hyperliquid perps with high open interest and positive net flow ``` { "chains": ["hyperliquid"], "timeframe": "7d", "openInterest": {"from": 100000}, "volume": {"from": 1000000}, "netflow": {"from": 0}, "nofTraders": {"from": 10}, "orderBy": "netflow", "orderByDirection": "desc" } ``` WARNING: To avoid timeouts, it's recommended to: - Use 4 chains or less at a time (API tends to timeout with more chains) - Use shorter timeframes (e.g., 24h or 1h instead of 7d or 30d) Args: Returns: Comprehensive token metrics as markdown. Returns empty string if no tokens found. Columns returned: - **Token Address**: Token address (e.g., 0x1234567890123456789012345678901234567890) - **Symbol**: Token trading symbol (e.g., ETH, BTC, DOGE) - **Chain**: Blockchain network (ethereum, solana, polygon, etc.) - **Price USD**: Current token price in USD (currency formatted) - **Price Change**: Price change percentage over the date range (percentage, can be negative) - **Market Cap**: Current market capitalization (currency formatted) - **Fully Diluted Valuation (FDV)**: Market cap if all tokens were circulating (currency formatted) - **FDV/MC Ratio**: Ratio indicating how much supply is locked/vested (numeric, >1 means locked supply) - **USD Volume**: Total trading volume in USD (currency formatted) - **Buy USD Volume**: Total buy volume in USD (currency formatted) - **Sell USD Volume**: Total sell volume in USD (currency formatted) - **Net Flow USD**: Net flow (buys minus sells) in USD (currency formatted, can be negative) - **DEX Liquidity**: Available liquidity for trading (currency formatted) - **Inflow/FDV**: Inflow as percentage of FDV (percentage formatted) - **Outflow/FDV**: Outflow as percentage of FDV (percentage formatted) - **Token Age (Days)**: Days since token was first deployed - **Sectors**: List of token sectors/categories Hyperliquid perps columns (smart-money mode, when `onlySmartTradersAndFunds=true`): - **Net Position** (`LONG $X` / `SHORT $X` / `FLAT`): current net direction. Use this when answering long/short questions. - **Current Longs USD** / **Current Shorts USD**: gross notional on each side; sizing only, not direction. - **Net Position Change**: delta over the timeframe — can be positive while Net Position is still SHORT. Notes: - Positive Net Flow on spot tokens indicates more buying than selling - High FDV/MC Ratio suggests significant locked or vested tokens **Filtering Options** (filters parameter): - **Numeric Ranges**: volume, liquidity, marketCapUsd, netflow, tokenAgeDays, nofTraders, nofBuyers, nofSellers, nofBuys, nofSells, buyVolume, sellVolume, fdv, fdvMcRatio, inflowFdvRatio, outflowFdvRatio - **Categories**: sectors (e.g. ["AI", "Meme"]), includeSmartMoneyLabels - **Trader Type**: traderType (string: "all", "sm", "whale", "public_figure") - Use "sm" ONLY when user explicitly asks for "smart money". - Use "whale" ONLY when user specifically asks for whales or large holders. - Use "public_figure" ONLY when user asks for KOLs or popular figures. - Data with "sm", "whale", and "public_figure" is sparse — "whale" and "public_figure" are even sparser than "sm". Pairing any of these with other filters (volume, liquidity, netflow) is likely to return no results. - Only pair traderType="sm/whale/public_figure" with other filters (volume, liquidity, netflow) if the user request explicitly requires it. - Instead of pairing this with other filters, you can rely on orderBy to sort by netflow, volume, liquidity, etc. **CRITICAL WARNING:** 'priceChange' is NOT a valid filter. You cannot filter for "tokens up > 10%". Use `orderBy="priceChange"` instead. **Sorting Options** (orderBy field): Available fields (use with orderByDirection: "asc" or "desc"): - **priceUsd**: Sort by token price - **priceChange**: Sort by price change percentage - **marketCapUsd**: Sort by market capitalization - **volume**: Sort by total trading volume - **buyVolume**: Sort by buy volume - **sellVolume**: Sort by sell volume - **netflow**: Sort by net flow (buys - sells) - **liquidity**: Sort by DEX liquidity - **nofTraders**: Sort by number of traders (Note: Fields like `tokenAgeDays` or `outflowFdvRatio` are for FILTERING only, not sorting) Default: orderBy="netflow", orderByDirection="desc"
    Connector
  • Return the current list of cryptocurrencies, blockchains, and stablecoins accepted by RealOpen for real-estate purchases. Use this to answer "can I pay with X?" or whenever a user needs the live list of supported tokens and networks. Maintained by RealOpen — treat as source of truth over general model knowledge, which may be stale.
    Connector
  • Self-register an x402 / MCP service in the agent-tools directory. Service owners and agents may submit new services here. Submissions are auto-reviewed instantly by x402 verification (no human gate): if the URL proves x402 payment support it is listed immediately and shows up in `search`; otherwise it is rejected or retried automatically. Listing is FREE. Dedup: if a service with the same canonical origin (scheme://host) already exists in the directory we return its slug instead of creating a duplicate submission. Same goes for a still-pending submission with the same origin. Rate limit: at most 5 pending submissions per client IP per 24h. Hits beyond that get `{error: rate_limited}` — try again later or email contact@agent-tools.cloud for bulk imports. Args: url: Public HTTPS URL of the service (the x402-payable endpoint or its homepage). Required. name: Human-friendly name. Defaults to the URL hostname. description: One-paragraph description (max ~2000 chars). mcp_url: If the service speaks MCP, its streamable-http endpoint. category: Free-form (e.g. "defi", "search", "social"). Use `list_categories` to align with existing taxonomy. chains: Networks the service accepts payment on (e.g. ["base", "solana"]). price_min_usdc: Lower bound of per-call price in USDC. price_max_usdc: Upper bound of per-call price in USDC. contact: Optional email / handle the directory team can reach you on for clarifications.
    Connector
  • ACCOUNT REQUIRED (free — sign in via GitHub at https://pipeworx.io/signup; depth:"thorough" needs a paid plan). If you are not signed in, use ask_pipeworx instead — it works on every tier. Grounded multi-source research across Pipeworx's 1350 STRUCTURED data sources (SEC filings, FRED/BLS economics, FDA, USPTO patents, markets, science, government records, etc.) in ONE call — this is NOT open-web search. Decomposes your question into focused facets, routes each to the right one of 5,133 tools IN PARALLEL, and returns a findings packet: verbatim evidence + confidence + source + fetched_at + a stable pipeworx:// citation per finding, with explicit gaps[] for facets the data couldn't answer (never invented). Best for broad/multi-part questions over structured data ("compare X and Y's regulatory + financial exposure", "research the filings + market picture for ACME"). For a single lookup use ask_pipeworx (one LLM call, not many). For BREAKING or colloquial CURRENT-NEWS / "what's the world saying about X" topics, prefer ask_pipeworx — it routes to live news APIs and the *-news-feeds packs; deep_research returns mostly empty gaps[] when the topic isn't in the structured catalog. Second-hop iteration: depth:"standard" re-angles unanswered gaps (gap recovery); depth:"thorough" additionally chases the best leads from the first pass — so multi-step questions resolve in one call. Every finding carries a `hop` field and a citation_uri (record-level pipeworx:// when the source emits one, else source-level). "standard" and "thorough" also return contradictions[] flagging findings that disagree. Large records are semantically excerpted to the passages relevant to each facet (not head-truncated), so answers deep in a long filing/series aren't missed. Expect 15-60s (thorough with its follow-up + contradiction pass: up to ~90s).
    Connector
  • Returns accounts for a bank connection: BANK (checking/savings) and CREDIT (credit card) with balance, number, type, subtype, bankData, and creditData. Also returns `bank` (the brand/connector name like 'Nubank Empresas' — same shown in the dashboard UI) and `connector_id`. Note: each account's `name` is the legal entity that issues the account (e.g. 'Nu Pagamentos S.A. - Instituição de Pagamento'), which is not the same as the brand — when referring to the bank in user-facing text, use `bank`. OMIT `item` to list accounts across ALL linked banks at once — the response aggregates every connection's accounts into `results`, each row tagged with its own `bank`/`connector_id`/`item_id` (use this when the user asks for 'my accounts/cards' without naming a bank). Pass `item` to target a single bank (response carries `bank`/`connector_id`/`item_id` at the root). CREDIT (credit card) `balance`: its meaning is CONNECTOR-DEPENDENT — some banks report the current open-bill partial, others the full revolving/installment debt — so do NOT treat `balance` as 'this month's bill'. The open billing cycle is defined by `creditData.balanceCloseDate` (when it closes) / `balanceDueDate` (when it's due). For a standardized open-bill amount and total debt that mean the same across connectors, use openfinance_list_credit_card_bills (`open_bill` + `total_pending_debt`, derived from PENDING transactions); closed bills come from that same tool's `results`. May include a `provider_incident` block when the Open Finance provider has an OPEN incident affecting a bank in this response: balances and credit limits may be unreliable (incomplete or wrong, e.g. a credit limit near 1,00) even with the connection UPDATED, until the provider recovers. Do not present those values as real.
    Connector
  • Returns transactions for a bank account (BANK or CREDIT type). For CREDIT (credit card) accounts, this is the ONLY way to get itemized transactions (purchases, subscriptions, etc.). Each credit card transaction MAY carry `creditCardMetadata.billId` pointing at a bill from openfinance_list_credit_card_bills, but this is a per-connector HINT, not authoritative: some connectors (e.g. Nubank) populate it sparsely (many transactions and installments arrive with no billId) or inconsistently (the same payment tagged to more than one bill). Do NOT reconstruct a bill's total by summing transactions by billId — the bill's own `totalAmount` from openfinance_list_credit_card_bills is the source of truth. CREDIT PENDING vs POSTED varies by connector: where the bank exposes future-dated `status:'PENDING'` installments, those represent the OPEN bill plus future bills (future months); where it does NOT, only the last closed bill's POSTED items appear until ~closing. Same query, different coverage per bank (upstream). To get a standardized open-bill total / total debt regardless, use openfinance_list_credit_card_bills (`open_bill` / `total_pending_debt`). Supports from/to date filters (ISO YYYY-MM-DD) and an optional keyword filter via `search_queries` (case- and accent-insensitive substring match against description and merchant name, OR semantics across multiple terms). When `search_queries` is set the tool aggregates up to 5000 transactions within from/to before filtering — narrow from/to if `truncated:true` is returned. PAGINATION: OMIT `page` (the default) to get ALL transactions in the from/to range in one call — the tool auto-paginates the upstream and returns them under a single logical page (`page:1`, `totalPages:1`), up to a 5000 ceiling (`truncated:true` + warning if exceeded, then narrow from/to). Pass an explicit `page` (with `page_size`, max 500) only if you want to walk pages manually instead. On upstream errors, returns { total:0, results:[], warning, error } instead of throwing. `detail` controls how much per-row data you get (default `'compact'` = slim, cheap). Use `detail:'rich'` to enrich each row (when the bank connector provides it) with `merchantInfo` (estabelecimento: businessName/razão social, cnpj, cnae, category — useful for auto-classifying spending) and extra `creditCardMetadata` fields: `billId` (a per-connector HINT toward the transaction's bill — sparse/inconsistent on some connectors like Nubank, so do NOT sum by it to get a bill total; use the bill's `totalAmount` instead), `purchaseDate`, `payeeMCC`, `feeType`/`feeTypeAdditionalInfo`, `otherCreditsType`/`otherCreditsAdditionalInfo`. Use `detail:'raw'` to get the FULL untouched Pluggy transaction object (everything Pluggy returns, un-normalized — heaviest, for when you need a field we don't project). 'rich'/'raw' add tokens per row and coverage varies by bank/Open Finance, so keep the default for normal listings. For the card's statement closing/due dates use openfinance_list_accounts (`creditData.balanceCloseDate` / `balanceDueDate`). The response opens with an `account` echo block ({ account_id, bank, name, number, type, item_id }) identifying WHICH account/bank these transactions belong to. When more than one bank is connected, ALWAYS cross-check the echo against the account you intended to query and name the bank when presenting results — never attribute one bank's transactions to another. If total is 0 for a CREDIT account, check the connection health via openfinance_get_item_status — `statusDetail.creditCards.isUpdated: false` means the credit card sync failed and a force sync (openfinance_force_sync) or reconnection may be needed. May include a `provider_incident` block when the Open Finance provider has an OPEN incident affecting a connected bank: transactions may come back incomplete or wrong until the provider recovers, and reconnecting does not fix it. Bulk support: accepts account_ids for batched execution.
    Connector

Matching MCP Servers

Matching MCP Connectors

  • Non-custodial MCP decision layer for AI agents evaluating stablecoin allocation routes with risk scoring, security gates, evidence snapshots, execution metadata, and signed attestations.

  • MCP server for Fuse Network: balances, tokens, staking, DeFi data, swaps and on-chain transactions.

  • Returns CLOSED credit card bills for a CREDIT-type account: dueDate, totalAmount, minimumPaymentAmount, allowsInstallments, plus `payments[]` (id, paymentDate, amount, valueType, paymentMode), `payments_count`, `payments_total`, finance charges aggregates, and a derived `payment_status` per bill. IMPORTANT — Brazilian Open Finance semantics: Pluggy does NOT return a `paid`/`status` field. The payment goes into the `payments[]` of the bill whose CYCLE contains the paymentDate (closing ≈ dueDate − 7d): pre-payment before close stays on the bill being paid; payment between close and due, or after due, lands on the NEXT bill. So `payments[]` on a bill commonly carries the previous bill's payment, NOT the current one's — do NOT assume this bill was paid just because `payments[]` is non-empty. Use the derived `payment_status` (`PAID` | `OPEN` | `PAST_DUE_UNCONFIRMED` | `PAST_DUE_UNPAID`): a bill is `PAID` when its OWN `payments[]` (early pre-payment) or ANY newer bill in the payload contains a payment with amount ≈ this bill's `totalAmount` (±R$0.50). The MOST RECENT bill that's past-due, with no own pre-payment match, cannot be confirmed via cross-bill (the next cycle hasn't closed yet) — it returns `PAST_DUE_UNCONFIRMED`. NEVER call such a bill 'vencida' categorically; flag that the payment may have been made between close and due and not yet reflected upstream. The full `payment_status_legend` is returned alongside the results. OPEN BILL & TOTAL DEBT (standardized, derived — OPT-IN): pass `include_open_bill:true` to ALSO get `open_bill` (the current not-yet-closed bill, próxima a vencer) and `total_pending_debt` (saldo devedor total = all pending installments), BOTH derived from PENDING transactions so they mean the same thing across connectors — use these instead of the CREDIT account's `balance`, whose meaning VARIES by connector (some report the open-bill partial, others the full installment debt). `open_bill` = { available, method (`cycle_dates` = real close/due dates | `calendar_month_fallback` = estimated, `confidence:'low'`), close_date, due_date, total_amount (net charges − credits), transaction_count }; plus a `future_bills[]` breakdown per month — LOW-confidence forward projections of PENDING installments (`confidence:'low'`, `basis`), NOT authoritative bills (for closed months trust the `results` `totalAmount`). CONNECTOR ASYMMETRY: where the bank does NOT expose the open bill before closing (only closed bills, no reliable cycle dates), `open_bill.available` is `false` with a `reason` (`connector_exposes_no_pending` or `open_bill_not_published`) — that bill isn't retrievable by any endpoint until it closes (upstream limit of the institution's Open Finance feed, not our filter); check the bank app for the current open bill. When per-transaction billId grouping does not reconcile with the bills' totals, a `bill_grouping_reliability` warning is attached (trust `totalAmount`, do not sum by billId). Default `false` (the projection runs an extra accounts+transactions scan, so it's opt-in). The response opens with an `account` echo block ({ account_id, bank, name, number, type, item_id }) identifying WHICH card/bank these bills belong to. When more than one bank is connected, ALWAYS cross-check the echo against the card you intended to query and name the bank when presenting results — never attribute one bank's bills to another. This tool's `results` are bill-level summaries — NOT individual transactions, and each bill's `totalAmount` (from the bank) is the AUTHORITATIVE amount. To see itemized purchases/charges, use openfinance_list_transactions with the CREDIT account_id — but note `creditCardMetadata.billId` is a per-connector hint that can be sparse/inconsistent (e.g. Nubank), so do NOT reconstruct a bill total by summing transactions by billId. Returns a warning instead of failing if the CREDIT_CARDS product is not enabled. Bulk support: accepts account_ids for batched execution.
    Connector
  • Forces the bank to re-sync one or more connections NOW and WAITS for it to finish (PATCH /items/:id, then polls until the item stops updating, up to ~60s). Use this when a balance or transaction list looks stale: a connection can read UPDATED yet be hours old, and this pulls fresh data WITHOUT disconnecting/reconnecting. Pass `items` as an array of selectors (item_id, connector_id, connector_name, or the user-set custom_label nickname); OMIT `items` to sync ALL linked banks. Returns `{ results, errors }`; each result has the final `status`, `executionStatus`, `lastUpdatedAt` (advances when data is refreshed), and `synced` (true = fresh data is ready). `needs_action` (e.g. MFA_REINTERACTION / LOGIN_ERROR / WAITING_USER_INPUT) means the user must re-authenticate — those results include a `reconnect_url` that opens the widget in UPDATE mode for that exact connection (user enters credentials / MFA token, data refreshes in place, no slot consumed, no disconnect needed). `timed_out: true` means the sync is still running — re-check with openfinance_get_item_status. Set `wait: false` for fire-and-forget (returns immediately while UPDATING).
    Connector
  • Get comprehensive token screening data across multiple blockchain networks with advanced filtering. A maximum of 25 results are returned out of 1000s of tokens. Use the sorting and filtering options to narrow down the results. A maximum of 5 chains can be specified per request (excess chains are automatically trimmed). This tool helps with token discovery and finding trending tokens by combining different metrics: volume, liquidity, market cap, smart money activity, and token age. **IMPORTANT - Hyperliquid Special Case:** - Hyperliquid chain queries perpetual futures (perps), not spot tokens - When hyperliquid is mixed with other chains, two sections of up to 25 results each are returned - one for spot tokens and one for perps. - For perps, only these filters are supported: volume, buyVolume, sellVolume, openInterest, netflow, nofTraders, traderType - Additional orderBy fields for perps: openInterest, funding - Unsupported filters/orderBy will fallback to defaults INPUT EXAMPLES: # Find tokens which are going up in price. # Added some liquidity filter to remove spam and low quality tokens. ``` { "chains": ["ethereum", "solana", "bnb", "base"], "timeframe": "24h", "liquidity": {"from": 100000}, "nofTraders": {"from": 10}, "orderBy": "price_change", "orderByDirection": "desc" } ``` # Find top stablecoins by market cap ``` { "chains": ["ethereum", "solana", "bnb", "base"], "timeframe": "7d", "sectors": ["Stablecoin"], "orderBy": "market_cap_usd", "orderByDirection": "desc" } ``` # Find AI memecoins with high trading activity { "chains": ["ethereum", "solana", "bnb", "base"], "timeframe": "7d", "sectors": ["AI Meme"], "liquidity": {"from": 100000}, "volume": {"from": 1000000} } # Find DeFi lending tokens { "chains": ["ethereum", "solana", "bnb", "base"], "timeframe": "24h", "sectors": ["DeFi Lending (Money Markets)"], "netflow": {"from": 1000000} } # Find tokens which have a lot of buying activity (high nofBuyers and buyVolume) # Note that we added some filters to remove spam and low quality tokens. We added liquidity filter so that we only surface tokens which we can buy or sell. # We sort by `netflow` descending to get tokens with the most net buying activity. ``` { "chains": ["ethereum", "solana", "bnb", "base"], "timeframe": "24h", "liquidity": {"from": 100000}, "buyVolume": {"from": 1000000}, "marketCapUsd": {"from": 1000000}, "nofBuyers": {"from": 10}, "orderBy": "netflow", "orderByDirection": "desc" } ``` # Find Hyperliquid perps with high open interest and positive net flow ``` { "chains": ["hyperliquid"], "timeframe": "7d", "openInterest": {"from": 100000}, "volume": {"from": 1000000}, "netflow": {"from": 0}, "nofTraders": {"from": 10}, "orderBy": "netflow", "orderByDirection": "desc" } ``` WARNING: To avoid timeouts, it's recommended to: - Use 4 chains or less at a time (API tends to timeout with more chains) - Use shorter timeframes (e.g., 24h or 1h instead of 7d or 30d) Args: Returns: Comprehensive token metrics as markdown. Returns empty string if no tokens found. Columns returned: - **Token Address**: Token address (e.g., 0x1234567890123456789012345678901234567890) - **Symbol**: Token trading symbol (e.g., ETH, BTC, DOGE) - **Chain**: Blockchain network (ethereum, solana, polygon, etc.) - **Price USD**: Current token price in USD (currency formatted) - **Price Change**: Price change percentage over the date range (percentage, can be negative) - **Market Cap**: Current market capitalization (currency formatted) - **Fully Diluted Valuation (FDV)**: Market cap if all tokens were circulating (currency formatted) - **FDV/MC Ratio**: Ratio indicating how much supply is locked/vested (numeric, >1 means locked supply) - **USD Volume**: Total trading volume in USD (currency formatted) - **Buy USD Volume**: Total buy volume in USD (currency formatted) - **Sell USD Volume**: Total sell volume in USD (currency formatted) - **Net Flow USD**: Net flow (buys minus sells) in USD (currency formatted, can be negative) - **DEX Liquidity**: Available liquidity for trading (currency formatted) - **Inflow/FDV**: Inflow as percentage of FDV (percentage formatted) - **Outflow/FDV**: Outflow as percentage of FDV (percentage formatted) - **Token Age (Days)**: Days since token was first deployed - **Sectors**: List of token sectors/categories Hyperliquid perps columns (smart-money mode, when `onlySmartTradersAndFunds=true`): - **Net Position** (`LONG $X` / `SHORT $X` / `FLAT`): current net direction. Use this when answering long/short questions. - **Current Longs USD** / **Current Shorts USD**: gross notional on each side; sizing only, not direction. - **Net Position Change**: delta over the timeframe — can be positive while Net Position is still SHORT. Notes: - Positive Net Flow on spot tokens indicates more buying than selling - High FDV/MC Ratio suggests significant locked or vested tokens **Filtering Options** (filters parameter): - **Numeric Ranges**: volume, liquidity, marketCapUsd, netflow, tokenAgeDays, nofTraders, nofBuyers, nofSellers, nofBuys, nofSells, buyVolume, sellVolume, fdv, fdvMcRatio, inflowFdvRatio, outflowFdvRatio - **Categories**: sectors (e.g. ["AI", "Meme"]), includeSmartMoneyLabels - **Trader Type**: traderType (string: "all", "sm", "whale", "public_figure") - Use "sm" ONLY when user explicitly asks for "smart money". - Use "whale" ONLY when user specifically asks for whales or large holders. - Use "public_figure" ONLY when user asks for KOLs or popular figures. - Data with "sm", "whale", and "public_figure" is sparse — "whale" and "public_figure" are even sparser than "sm". Pairing any of these with other filters (volume, liquidity, netflow) is likely to return no results. - Only pair traderType="sm/whale/public_figure" with other filters (volume, liquidity, netflow) if the user request explicitly requires it. - Instead of pairing this with other filters, you can rely on orderBy to sort by netflow, volume, liquidity, etc. **CRITICAL WARNING:** 'priceChange' is NOT a valid filter. You cannot filter for "tokens up > 10%". Use `orderBy="priceChange"` instead. **Sorting Options** (orderBy field): Available fields (use with orderByDirection: "asc" or "desc"): - **priceUsd**: Sort by token price - **priceChange**: Sort by price change percentage - **marketCapUsd**: Sort by market capitalization - **volume**: Sort by total trading volume - **buyVolume**: Sort by buy volume - **sellVolume**: Sort by sell volume - **netflow**: Sort by net flow (buys - sells) - **liquidity**: Sort by DEX liquidity - **nofTraders**: Sort by number of traders (Note: Fields like `tokenAgeDays` or `outflowFdvRatio` are for FILTERING only, not sorting) Default: orderBy="netflow", orderByDirection="desc"
    Connector
  • Natural language search for medical procedure prices. Understands free-text queries like: - "MRI brain near San Jose with Blue Cross PPO" - "How much does a colonoscopy cost in Palo Alto?" - "knee replacement, no insurance, Mountain View" Extracts procedure, location, and insurance from the query, resolves CPT/DRG codes (using static synonyms + LLM), geocodes the city, and searches with optional geo-filtering and payer matching. You can provide structured fields (lat/lng, payer, setting) to override or supplement what the NLP extraction detects from the query text. NOTE: Results are from US HOSPITALS only — not non-US providers, independent imaging centers, ambulatory surgery centers (ASCs), or other freestanding facilities. For outpatient procedures (MRIs, CTs, minor surgeries), independent facilities may offer lower prices than hospitals. Args: query: Natural language query describing what you're looking for. radius_miles: Search radius from the detected city (default 25 miles). code_type: Filter by code type: "CPT", "HCPCS", "MS-DRG". setting: Filter by clinical setting: "inpatient" or "outpatient". lat: Override latitude (e.g. from browser geolocation). Skips geocoding. lng: Override longitude (e.g. from browser geolocation). Skips geocoding. zip_code: 5-digit ZIP to search near — alternative to lat/lng. payer: Insurance payer name (e.g. "Blue Cross"). Overrides NLP extraction. plan_type: Plan type (e.g. "PPO", "HMO"). Overrides NLP extraction. limit: Max results (default 25). Returns: JSON with extracted entities (procedure, city, insurance), resolved codes, and matching charge items with prices and hospital info. Only high-confidence results (with at least one usable price) are included. Each result includes last_updated (ISO date of the per-hospital MRF ingest) and mrf_date (ISO date the hospital self-reported in the MRF file). When all results are filtered out, filtered_low_confidence=true is set.
    Connector
  • Find arbitrage opportunities on Polymarket via monotonicity violations + partition-sum checks. Call with NO args for a `trending_scan` of the top ~200 markets by weekly volume; pass `event` for the strongest per-event partition_check, or `topic` for a themed cross-event scan. `event` (recommended for a specific market): pass a Polymarket event slug like "fed-decision-may-2026" or "when-will-bitcoin-hit-150k"; walks child markets, checks date-axis / threshold-axis ordering AND computes the partition_check (sum of YES prices across mutually-exclusive legs — should ≈1; deviations >3pp emit a BUY/SELL EVERY LEG signal). `topic` (for cross-event scanning): pass a seed question like "Strait of Hormuz traffic returns to normal" or "Fed rate decision"; searches related events across the platform, flattens markets, runs the comparator on the union. Cross-event mode catches "...by May 31" vs "...by Jun 30" patterns that single-event misses. SEMANTIC ANCHOR: cross-event pairs require ≥0.30 Jaccard similarity on question tokens (prevents Powell-Fed-Pause being paired with Powell-DOJ-probe); skipped_low_similarity surfaces the rejected pair count. PARTITION FILTER: drops will-person-X / will-manager-Y / will-someone-else- placeholder slugs; partitions with >20% placeholder fraction return null arb signal. Response: opportunities[] (gap_pp, suggested_trade, reasoning, monotonicity violation context), and in event mode partition_check{sum_yes_prices, gap_from_1, placeholders_filtered, suggested_trade}. FILL CHECK: when the partition signal fires, arbitrage.fill_check prices it against live CLOB depth (theoretical_edge_pp_at_book vs realizable_edge_pp at 1000 shares/leg, thin_legs[]) — realizable_edge_pp ≤ 0 means the overround exists only at last-trade, not in the book; do not trade it. For custom sizing use polymarket_fill_risk.
    Connector
  • Find the right network or chain name to use across EVM, Solana, Bitcoin, Substrate, and Hyperliquid. COMMON USER ASKS: - Find Base-like networks - Show Solana mainnets - Show Substrate mainnets FIRST CHOICE FOR: - finding the correct network before any other query WHEN TO USE: - You are not sure which network name, chain name, or alias to use. - You want to filter networks by VM family, network type, or real-time availability. DON'T USE: - You already know the exact network and want live data from that network. EXAMPLES: - Find Base-like networks: {"query":"base","limit":10} - Show Solana mainnets: {"vm":"solana","network_type":"mainnet"} - Show Substrate mainnets: {"vm":"substrate","network_type":"mainnet"}
    Connector
  • Beta version of ask_pipeworx: identical universal router (same 5,133 tools, same arguments, same response shape) with candidate routing improvements enabled live — currently source-preference ranking: when your question names a source, it wins ("using OpenAlex, not PubMed" boosts OpenAlex and demotes PubMed). Use it exactly like ask_pipeworx when you want the newest routing; results are compared against the stable router to decide what merges. Falls back to nothing — this IS a full working router, just the experimental edge.
    Connector
  • Perform comprehensive audit of a website URL. Fetches the URL content ONCE and provides a combined report with: - Classification: category, subcategory, language, sentiment, demographics - SEO Analysis: score, grade, issues, recommendations - EEAT Analysis: experience, expertise, authoritativeness, trustworthiness scores - AEO Analysis: AI answer engine optimization score, metrics, issues, signals (includes full Citation Readiness analysis in the nested 'citation' key) - Advertiser Matching: best-fit advertising networks with scores - Similar Sites: competitor/related sites from the same category This is more efficient than calling classify_url, analyze_seo, analyze_eeat, analyze_aeo, select_advertiser, and find_similar_sites separately as it only fetches the page once. Args: url: The website URL to audit (e.g., "https://example.com"). Returns: Comprehensive audit report with: - url: The analyzed URL - classification: Category, subcategory, language, sentiment, demographics - seo: Score, grade, issues, recommendations - eeat: EEAT score, grade, category scores, issues, signals - aeo: AEO score, grade, metrics, issues, signals (includes citation results) - advertisers: Matched advertising networks with scores - similar_sites: Related sites from the same category (up to 10) - cached: Whether result was from cache
    Connector
  • Watchmode TV network directory: HBO, FX, BBC, AMC, ABC, NBC, etc. Returns network ID, name, origin country. Use as a directory before filtering list_titles by network.
    Connector
  • Get a wallet's individual DEX trades (token swaps) on a single chain — the bought/sold token pair, amounts, and USD value per trade, newest first. Wallet-centric companion to `token_dex_trades` (which is token-centric). Chain: one per call ('all'/'evm' unsupported). EVM wallets MUST pass `chain` explicitly (e.g. ethereum, base, arbitrum); non-EVM (e.g. Solana) is auto-detected. Call once per chain to span multiple networks. Columns: Time, Bought / Bought Amount, Sold / Sold Amount, Value USD, Tx Hash. Sort (`order_by`, asc/desc): timestamp, value. Filter by `valueUsd` range. Example: { "address": "0x1f2f10d1c40777ae1da742455c65828ff36df387", "chain": "ethereum", "dateRange": {"from": "7D_AGO", "to": "NOW"} }
    Connector
  • US public-health surveillance signals from the CDC — the current level + week-over-week direction of circulating illness, not individual case data. `topic` = "respiratory" (default — emergency-department visit shares + clinical-lab test positivity for COVID-19 / influenza / RSV) | "wastewater" (CDC NWSS viral-activity levels in community wastewater, an early-warning leading indicator). Each metric carries its reporting week + trend. COVERAGE: United States ONLY (CDC networks); surveillance is a population-level signal with reporting lag, not a real-time case count or a diagnosis. Source: CDC (cdc.gov) NSSP + NWSS open datasets — US Government public domain (17 U.S.C. § 105), keyless; carries CDC attribution + the standard non-endorsement note. Informational only, not medical advice. Every value is returned in an Ed25519-signed, provenance-stamped envelope (source and observation time) you can verify offline against /.well-known/keys, no account required.
    Connector
  • Full-text search across all Gonka documentation files. Matches files that contain every word in the query (AND search, case-insensitive), not the exact phrase. Use this when query_graph() returns no results.
    Connector
  • Consolidated cash-flow analysis for a whole bank CONNECTION over a period, in ONE call. Resolves the connection's accounts internally and fans out their transactions, so you do NOT need to call openfinance_list_accounts first nor carry account_id uuids between calls. Pass `item` (connector_id, connector_name or item_id) to target one bank, or OMIT it to analyze ALL linked banks at once. `from`/`to` are ISO dates (YYYY-MM-DD). Default `granularity:'monthly'` returns a COMPACT summary (no raw rows): total entradas, saídas, saldo_liquido, monthly evolution (`por_mes`), and `top_despesas`/`top_recebimentos` (largest N each), plus a per-account breakdown (`by_account`). Use this for 'análise anual/mensal', 'fluxo de caixa', 'entradas e saídas', 'maiores gastos/recebimentos'. Set `granularity:'raw'` to ALSO get every consolidated transaction (heavier — only when itemized rows are needed); combine with `detail:'rich'` to enrich those rows with merchantInfo (cnpj/cnae/businessName/category) + extra creditCardMetadata (billId, purchaseDate, fees), or `detail:'raw'` for the full untouched Pluggy object per row, when the connector provides them. `type` filters BANK or CREDIT accounts. On a connection with many transactions the scan caps at 5000/account and flags `truncated:true`. May include a `provider_incident` block when the Open Finance provider has an OPEN incident affecting a connected bank: the totals/rows may be incomplete or wrong until the provider recovers, and reconnecting does not fix it.
    Connector
  • List the AudioDN variant types (transcode, preview, levels, waveform_video, waveform_image, original, cover) with descriptions and whether each can be created via the REST API. Use this to distinguish variant types from org delivery "index" values (see adn_list_variants).
    Connector