Query and analyze blockchain data directly in ChatGPT with Allium. Discover schemas and documentation, run SQL across blockchain datasets, and turn results into shareable queries, visualizations, and dashboards. Ask questions like “Compare DEX volume across chains,” “Analyze this wallet’s holdings and P&L,” or “Chart a token’s price history.” Allium combines historical datasets with real-time market and wallet data, taking you from question to analysis in one conversation.
_index.md to choose a document. Internal paths are unavailable on MCP. Use search_docs when you do not know the path.initial_run_id; the rows are NOT ready when this call returns. Poll get_query_run_results(run_id=initial_run_id, poll_timeout_seconds=180) and wait for rows before building a visual or dashboard on the query; leaving poll_timeout_seconds off checks once and returns immediately. A visual created on a run that has not finished renders blank. Use run_sql_query instead only for throwaway one-off exploration nothing downstream consumes. Leave run_on_creation=False for templates, drafts, or saves that should not execute yet.url deep-links to the visual this call wrote. A query can hold several visuals, each with its own visual_id. Call get_explorer_query first to see what is already there. Two ways to call this: - Omit visual_id — adds a new visual alongside any existing ones. - Pass visual_id — replaces that one visual in place. This is how you edit a visual; omitting visual_id would add a duplicate instead. Choose spec.type based on the shape of the data: - "chart" — line, bar, or area over an x axis (typically time). - "value" — a single big number, with an optional comparison to a prior period. - "table" — tabular rows with optional per-column formatting and heatmap shading. - "pie" — share-of-total across categories (pie, donut, or donut-with-center-value). - "sankey" — directional flow between two or more entity columns. - "treemap" — nested rectangles sized by a numeric value. - "scatter" — two numeric axes with optional point size and color encodings. - "map" — country or region choropleth keyed on a location field. - "chord" — pairwise flows between two columns (alternative to sankey). Call get_skill(name='explorer-visuals') first for general advice, then get_skill(name='explorer-visuals', reference_title=<type>) for the exact JSON schema for spec of the chosen type. Editor permission on the query is required. Two things make a visual render blank, both checkable before calling: - The query has no finished run. Queueing one (create_explorer_query with run_on_creation=True, or run_explorer_query) does not wait for it — poll get_query_run_results with a non-zero poll_timeout_seconds and only build the visual once it returns rows. - Field names in spec (axes, columns, filters, aggregates) that the query's result set doesn't have. Once the visual is created, offer to share it — call share_explorer_query(query_id=..., visual_id=...) to get a public link the user can send around.spec=null and that node's ID path.visual_id from get_explorer_query's visuals. Editor permission on the query is required, and this cannot be undone — to change a visual instead of removing it, pass its visual_id to create_explorer_visual with a new spec.params accepts: - type: "timeseries" (default) or "latest" - granularity: "day", "week", "month" — timeseries only - from, to: ISO dates bounding the range — timeseries only - sort: "asc" or "desc"; delta_window: integer — latest only - entity: one entity id, or a list, to restrict the rows - series: a dimension id, or a list, to split the metric by - limit: how much to keep. On type=latest it is the number of ranked rows, taken from the top, or from the bottom with sort=asc. On a timeseries it is the number of most recent periods, each returned whole - any other key is a filter on a dimension, in PostgREST syntax: - {"chain": "ethereum"} or "eq.ethereum": equal to one value - "neq.base": anything but base, rows with no chain included - "in.(ethereum,solana)": any of several; quote a value holding a comma or parenthesis, in.("a,b",c) - "not.in.(base,tron)": none of several, rows with no chain included - "gte.1m-10m", plus gt, lt, lte: only on a dimension with ordered values, such as tier; the bound is one of those values - a list of expressions on one key must all hold: {"tier": ["gte.10k-100k", "lte.1m-10m"]} - a value that itself starts with an operator and a dot, such as in., is written eq.<value> - the metric's own id takes gt, gte, lt or lte and a plain number, and keeps the returned rows whose value passes: {"payment_volume_usd": "gte.1000000"}. On a timeseries each period is tested, so a series can have gaps, and limit counts only the periods kept - activity_date takes gt, gte, lt or lte and an ISO date, the same as from/to, on a timeseries only. Bounds cut days, so a week or month partly outside them covers only the days inside An unknown entity id or filter value is not an error — it matches no rows and returns an empty result, so check the spelling against list_catalog_metrics before concluding a metric has no data. Results are capped at 200 rows: a timeseries keeps its most recent rows, a type=latest ranking keeps its highest-valued rows, or its lowest with sort=asc. Ask for what you need with limit, or narrow with from/to, a coarser granularity, or an entity filter, rather than relying on the cap.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.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.row_count, and cost_explorer_units when complete; row_limit may return fewer rows than row_count. By default this checks once. Set poll_timeout_seconds to wait, then call again if still queued or running. While queued, queue_status shows org-wide queue counts for its compute profile. Check failures and zero-row results before answering; zero rows may itself answer the question. For useful saved-query data, create_explorer_visual can render a visual unless the user wants only raw data, SQL, or a single value.reference_title set to the exact listed title to retrieve one.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.refreshed_at — when its data was last published. A metric whose refreshed_at is null has no published data and get_catalog_metric will fail on it. These are curated, pre-computed metrics: prefer them over writing SQL when one answers the question.queued and running query counts. Each profile has its own warehouse and its own queue, shared across the org but isolated from the other profiles, so a query sent to a less contended profile starts sooner. Pass a profile's identifier as compute_profile to run_sql_query or run_explorer_query, and prefer the profile with the lowest queued. The profile with is_default=true is used when no profile is specified.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. Reads Explorer dashboards (URL /analyze/dashboards/{dashboard_id}), which are user-created. The id is the path segment after /analyze/dashboards/. Never use this tool for a /terminal/... URL; use get_terminal_results instead.count includes matches beyond limit. Covers Explorer dashboards only. Use search_terminal for Allium's published Terminal dashboards, and read_dashboard to open one 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. Write query as a few keywords, e.g. ethereum dex trades or solana token transfers. Pass database to restrict hits to one chain. Long sentences dilute the ranking. 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. Keep the default limit for discovery and use limit=1-3 when include_content=True. Without database, hits are one per schema.table: the best-ranked database's copy is returned and other_databases lists the other databases (chains) that have the same table. Fetch a specific copy with id="<database>.<schema>.<table>". Each hit reports deprecated, and replacement_table when the retired table names one./terminal/ dashboards. Returns ranked discovery details and optionally rendered dashboard content, without SQL or result rows. Use include_content=True with a small limit when full context is needed, and provide the dashboard link for its charts and explanations. For a user's Explorer dashboards at /analyze/dashboards/, use search_dashboards.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. When editing an existing Explorer dashboard (/analyze/dashboards/{id}), use Terminal only for that SQL baseline, never to find the dashboard itself. 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…visual_id, the shared page shows the results table and saved visuals, but the embed shows only the table. Set visual_id to a visual listed by get_explorer_query to share and embed that visual alone. SQL is visible by default; set exclude_sql=True to hide it. An existing share is reused, and its SQL visibility is updated if requested. To revoke public access, open the query in the Allium app and turn off sharing there.sql does not run the query - it only saves the new SQL. Any visuals or dashboard elements bound to this query keep referencing its columns by name; they pick up the new SQL's columns the next time the query runs, and a binding whose column was renamed or removed will fail to render until it's rebound.Click any prompt to copy it.
App Stats
51
Tools
3
Prompts
ChatGPT
Platforms
Category
Investment ResearchWorks with
Data refreshed daily
