Allium

Get the Historical PnL for a given wallet address and token address. Before calling, use browse_docs with path 'api/developer/holdings/holdings-pnl-by-token-history.md' for detailed docs on supported chains, edge cases, and response format.

realtime_holdings_pnl_by_token_history

Fetch paginated historical fungible token balances for wallet addresses over a requested time range. Before calling, use browse_docs with path 'api/developer/wallets/historical-token-balances.md' for detailed docs on supported chains, edge cases, and response format.

realtime_historical_token_balances

Get historical aggregated USD holdings for one or more addresses. Before calling, use browse_docs with path 'api/developer/holdings/holdings-history.md' for detailed docs on supported chains, edge cases, and response format.

realtime_holdings_history

Fetch the latest fungible token balances for wallet addresses across supported chains, optionally including liquidity totals. Before calling, use browse_docs with path 'api/developer/wallets/latest-token-balances.md' for detailed docs on supported chains, edge cases, and response format.

realtime_latest_token_balances

Get the latest price for the given token addresses and chains. Before calling, use browse_docs with path 'api/developer/prices/token-latest-price.md' for detailed docs on supported chains, edge cases, and response format.

realtime_token_latest_price

Get token details for the given token addresses and chains. Before calling, use browse_docs with path 'api/developer/tokens/get-tokens-by-chain-address.md' for detailed docs on supported chains, edge cases, and response format.

realtime_get_tokens_by_chain_address

Price of a token at a given timestamp. Before calling, use browse_docs with path 'api/developer/prices/token-price-at-timestamp.md' for detailed docs on supported chains, edge cases, and response format.

realtime_token_price_at_timestamp

Get the price history for the given token and the given time granularity. Before calling, use browse_docs with path 'api/developer/prices/token-price-history.md' for detailed docs on supported chains, edge cases, and response format.

realtime_token_price_history

Get tokens price stats like volume, high and low, price and volume change. Before calling, use browse_docs with path 'api/developer/prices/token-price-stats.md' for detailed docs on supported chains, edge cases, and response format.

realtime_token_price_stats

Search tokens with a query string. Before calling, use browse_docs with path 'api/developer/tokens/search-tokens.md' for detailed docs on supported chains, edge cases, and response format.

realtime_search_tokens

Get rich transaction activity data for wallets, including activities, asset transfers, and labels. Before calling, use browse_docs with path 'api/developer/wallets/transactions.md' for detailed docs on supported chains, edge cases, and response format.

realtime_transactions

Endpoint providing fills by user address Before calling, use browse_docs with path 'api/developer/hyperliquid/fills.md' for detailed docs on supported chains, edge cases, and response format.

realtime_fills

Read one visual saved on an Allium Explorer query, including its full `spec`. Use this to tweak a field of an existing visual, or to match its style in a new one — get_explorer_query lists a query's visuals, and this returns the config of whichever one you name. To change what you read back, pass the same `visual_id` to create_explorer_visual with the edited `spec`. A null `type` means a legacy config that predates the current format: build a fresh `spec` for it rather than editing what you read back, which won't validate.

get_explorer_visual

Retrieve a saved Explorer query by ID. Returns the full SQL, row limit, template parameters, tags, URL, and latest result field metadata when available. Use this to inspect a query before editing or running it. `visuals` lists every visual saved on the query, IDs only. Pass a `visual_id` to create_explorer_visual to edit that visual, omit it to add one, or call get_explorer_visual for its full config.

get_explorer_query

Get the full instructions for a specific skill. Use this for detailed guidance on how to perform a task. If the skill has reference files, they are listed at the end by title; fetch one by calling this tool again with reference_title set to the title exactly as listed.

get_skill

Check which blockchain chains each realtime /developer/ endpoint supports. **Call this ONCE per session** before making any realtime tool calls (prices, wallets, etc.) or using the realtime APIs in generated code. Cache the result — it covers all endpoints. This is unnecessary for Explorer SQL and Docs endpoints. Returns a map of endpoint path → list of supported chain names, e.g.: {"/api/v1/developer/prices": ["ethereum", "solana", ...], ...} Use the result to: - **Validate** a chain before calling a realtime tool. Wrong chain = silent empty result or error. - **Discover** which endpoints cover a chain the user asks about.

realtime_get_supported_chains

Fetch SQL or latest precomputed result rows for one Terminal dashboard chart. Use search_terminal first to find a dashboard id, then call get_terminal_results without chart_id for the chart manifest. Call again with chart_id and mode="queries" for SQL, mode="results" for capped latest rows, or mode="both" for SQL plus rows. When returning or citing result values, state `result.queried_at` when present so the user knows when the precomputed Terminal result was last generated. This never uses compute units; it only reads existing query definitions and results from Terminal.

get_terminal_results

Get assets by ID, slug, or (chain, address). Before calling, use browse_docs with path 'api/developer/assets/get-assets.md' for detailed docs on supported chains, edge cases, and response format.

realtime_get_assets

Retrieve results of a query run by its run_id. Use this for both ad-hoc SQL queries, or a saved Explorer query run. Returns the query run status, and if the run succeeded, the result data, columns, row count, and the Explorer Units (cost_explorer_units) the run consumed. By default, checks once and returns immediately. Set poll_timeout_seconds to wait for completion. If the run is still in progress or failed, returns the current status and any error message. While a run is queued, `queue_status` reports how many queries are queued (including this run) and running org-wide on its compute-profile queue - a high queued count means running a follow-up on a less-contended profile (see list_compute_profiles) will start sooner. After results return: - Verify the run before you use it: if it failed, errored, or returned zero rows, fix the SQL and re-run — don't report an empty or failed run as the result (unless zero rows is itself a valid answer to the question, e.g. "were there any exploits today?" → none, in which case report it as such). - Once you have real data worth showing, and create_explorer_visual is available, that is the default next step on the saved query — chat surfaces render the visual inline. Skip only for single-scalar answers, or when the user asked for raw data or SQL only.

get_query_run_results

Get complete orderbook snapshot for all pairs. Before calling, use browse_docs with path 'api/developer/hyperliquid/orderbook-snapshot.md' for detailed docs on supported chains, edge cases, and response format.

realtime_orderbook_snapshot

List user's saved Explorer queries with field metadata and tags. Use the tags parameter to filter queries by tag (e.g., to find all queries tagged for a specific dashboard or topic).

list_explorer_queries

List available Allium skill guides and their descriptions. Returns skills the authenticated user has access to. Each skill provides in-depth guidance on a specific topic — use get_skill to retrieve the full instructions for a skill.

list_skills

List assets. Before calling, use browse_docs with path 'api/developer/assets/list-assets.md' for detailed docs on supported chains, edge cases, and response format.

realtime_list_assets

List the organization's Explorer compute profiles, each with its current query-queue depth. Each compute profile maps to a dedicated Snowflake warehouse (sized as a speed multiplier - "1x", "2x", "4x", "8x", "16x") and its own query queue, shared by everyone in the org but isolated from other profiles. Per profile: - `queued`: queries waiting to start, org-wide (a high value means new queries here will wait). - `running`: queries currently executing, org-wide. Pass a profile's `identifier` as the `compute_profile` argument to run_sql_query / run_explorer_query to route a query to that warehouse; prefer a profile with a low `queued` count to start sooner. The profile with `is_default=true` is used when no compute_profile is specified.

list_compute_profiles

List tokens, optionally sorted by a field. Before calling, use browse_docs with path 'api/developer/tokens/list-tokens.md' for detailed docs on supported chains, edge cases, and response format.

realtime_list_tokens

Endpoint providing order history by user address Before calling, use browse_docs with path 'api/developer/hyperliquid/order-history.md' for detailed docs on supported chains, edge cases, and response format.

realtime_order_history

Endpoint providing order status by user address Before calling, use browse_docs with path 'api/developer/hyperliquid/order-status.md' for detailed docs on supported chains, edge cases, and response format.

realtime_order_status

Query Hyperliquid account, market, and exchange information by request type through Allium's rate-limit-free proxy. Before calling, use browse_docs with path 'api/developer/hyperliquid/info.md' for detailed docs on supported chains, edge cases, and response format.

realtime_info

Inspect a dashboard at any depth. Pass `dashboard_id` alone for a root summary (name, settings, list of pages). Add `page_id` / `section_id` / `element_id` to drill down — each level returns the targeted node plus its immediate children's summaries (never a full subtree). At element depth the full typed config is returned.

read_dashboard

Run an existing saved Explorer query by ID. Queues the query for execution and returns a run_id. Use get_query_run_results to wait for results or for a non-blocking status check.

run_explorer_query

Run an ephemeral, throwaway SQL query on Allium's blockchain data. **Call `get_skill(name="sql-optimization")` before writing or running any SQL.** Use ONLY when the result is not reused — inspecting sample rows, checking distinct values, answering a single ad-hoc question. The run is not saved and cannot be referenced by a chart or dashboard. If the output might feed a chart/dashboard or be re-run later, start with create_explorer_query(run_on_creation=True) instead; running here first and re-saving the same SQL duplicates the compute. Returns a run_id immediately; use get_query_run_results to poll and retrieve results. The query is sanitized and row-limited per the caller's policy. IMPORTANT: When prepare_sql is available, validate queries before running them.

run_sql_query

Search Allium's public documentation (https://docs.allium.so). Use this tool when you need: - Information about blockchain data tables and schemas - Details about Allium's data models (DEX, NFT, DeFi, etc.) - API documentation and usage examples - Best practices for querying blockchain data

search_docs

Search schemas or fetch one schema entry by id. `query` runs the chosen `search_mode` against the prebuilt schema index. `id` fetches a single entry by its dotted table id (e.g. `ethereum.public.transactions`). Provide exactly one. For query searches, keep `include_content=False` unless full schema markdown is required. Search results are for discovery and ranking; full markdown can make result payloads too large. Use `limit=3-5` for broad searches and `limit=1-3` when `include_content=True`. Each hit reports `deprecated`, and `replacement_table` when the retired table names one.

search_schemas

Share an Explorer query publicly and return shareable + embeddable links. What gets shared depends on `visual_id`: - omitted: the query. The shared page shows the results table plus a tab per saved visual, so it's usually the best choice when there is more than one. - a `visual_id` from get_explorer_query's `visuals`: that one visual, pinned. This is the only form whose embed URL renders the visual; without it the embed shows just the table. `exclude_sql=True` hides the SQL on the shared page. Defaults to False (SQL visible). Returns a share URL (https://app.allium.so/s/{share_id}) and an embed URL (https://app.allium.so/embed/{share_id}). Idempotent: if a share already exists for the query/visual, the existing share is returned. If the caller-requested `exclude_sql` differs from the existing share's setting, the share is updated in place. To stop sharing, visit the query at https://app.allium.so/analyze/queries/{query_id} and toggle off public access there — there is no unshare tool.

share_explorer_query

Share a dashboard publicly and return a shareable link. Returns a URL of the form https://app.allium.so/s/dashboard/{share_id}. Idempotent: if the dashboard already has a public share, the existing link is returned. Dashboards do not have embed URLs. To stop sharing, visit the dashboard at https://app.allium.so/analyze/dashboards/{dashboard_id} and toggle off public access there — there is no unshare tool.

share_dashboard

Search Allium's public Terminal dashboards (app.allium.so/terminal). Returns ranked dashboard discovery hits — label, path, category, status, tags, and (optionally) the full rendered dashboard markdown. Use this to recommend an existing analyst-built dashboard before building one from scratch. Returns metadata and curated context only, never query result rows or raw SQL. Keep `include_content=False` for ranking; set it `True` with a small `limit` when you need full dashboard detail. Always suggest users to access the provided link to Terminal dashboard results, as they contain rich context and visualisations.

search_terminal

Update an existing Explorer query. Requires query_id. Only provide fields you want to change - others will be preserved.

update_explorer_query

Upsert or delete any node in a dashboard tree. Call get_skill(name='dashboard-design') first — it covers the build order, element catalog, layout, and design/SQL rules. For an element, `config.type` is one of: chart, value, table, pie, sankey, treemap, scatter, map, chord, markdown, spacer, variable-select, switch, date-range, radio-group. Fetch its full schema (query_id included for data elements) with get_skill(name='dashboard-design', reference_title=<config.type>) before building. If the user is following up on Terminal results or asks to chart/build a dashboard for a topic covered by Terminal, use search_terminal/get_terminal_results first. Use the Terminal chart manifest, context, and SQL as the baseline before creating or selecting dashboard query_ids. `spec.kind` selects the node type. The ID path locates the target: - IDs are the parent path on **create** (the target's own ID is absent). - IDs are the self path on **update** (the target's own ID is present). Examples: - Create a new dashboard: spec={"kind": "dashboard", "name": "..."} - Rename an existing dashboard: dashboard_id="d1", spec={"kind": "dashboard", "name": "..."} - Add a page: dashboard_id="d1", spec={"kind": "page", "name": "..."} - Add a section: dashboard_id="d1", page_id="p1", spec={"kind": "section"} - Add a data element (chart/value/table/pie/scatter/sankey/treemap/map/chord): dashboard_id="d1", page_id="p1", section_id="s1", spec={"kind": "element", "config": {"type": "value", "query_id": "qry_123", "field": "..."}}, layout?={"x": 0, "y": 0, "w": 6, "h": 4} `query_id` is REQUIRED on data-driven configs — it binds the element to a saved Explorer query. Without it the element renders empty with "missing query ID". Use create_explorer_query to mint one, or list_explorer_queries to find an existing one. The bound query also needs a finished run — creating one with run_on_creation=True only queues it, so poll get_query_run_results with a non-zero poll_timeout_seconds before binding, or the element renders with no data. - Add a static element (markdown/spacer) — no query needed: dashboard_id="d1", page_id="p1", section_id="s1", spec={"kind": "element", "config": {"type": "markdown", "content": "## Section heading"}}, layout?={"x": 0, "y": 0, "w": 12, "h": 2} - Add an input element (variable-select/switch/date-range/radio-group) — no query_id; it writes to a named variable that bound query SQL reads via `{{variable}}`. Changing the input re-runs every query referencing that variable; defaults seed it so the dashboard renders on load: dashboard_id="d1", page_id="p1", section_id="s1", spec={"kind": "element", "config": {"type": "date-range", "start_variable": "start_date", "end_variable": "end_date", "default_preset": "7d"}}, layout?={"x": 0, "y": 0, "w": 6, "h": 1} - Update an element's config (layout sticky — unchanged): dashboard_id, page_id, section_id, element_id="e1", spec={"kind": "element", "config": {...}} The new config fully replaces the prior one. Resend `query_id` (and any other fields you want kept) — omitting them drops them. Deleting a node — pass `spec=null` with the **self path** of what to remove: - Remove one element: dashboard_id="d1", page_id="p1", section_id="s1", element_id="e1", spec=null - Remove a section (and its elements): dashboard_id="d1", page_id="p1", section_id="s1", spec=null - Remove a page (and its sections): dashboard_id="d1", page_id="p1", spec=null Sibling layouts are recomputed so the remaining nodes stay aligned. The deepest ID given names the node that goes away, so double-check the path before sending. Deleting a whole dashboard is delete_dashboard's job. Path is exact: each ID must exist under the one above it. To put a section on a different page, create it on that page. To move an element to another section, delete it from the old section (spec=null) and create it on the new one. Layout for element creates auto-stacks below existing elements when omitted (x=0, w=6, h=4); on element updates, omitted layout means keep existing. Once the dashboard looks right, offer to share it — call share_dashboard to get a public link the user can send around.

set_dashboard