Skip to main content
MCP tool calls draw on the same credit pools as the rest of Allium. Most tools are free — only the ones that actually compute or serve data cost anything.

​
What costs credits

Free tools: search_schemas, search_docs, browse_docs, search_terminal, get_terminal_results, list_skills, get_skill, list_compute_profiles, get_query_run_results, get_explorer_query, list_explorer_queries, realtime_get_supported_chains, all dashboard, visual, and sharing tools.
get_query_run_results is free — the Explorer Units were charged when the run was queued. Polling for results costs nothing, so poll as long as you need.
Two different meters. Realtime and Hyperliquid tools call Allium’s Realtime APIs, which charge Developer Units per endpoint. Separately, every metered MCP tool call is checked against your Explorer Unit allowance before it runs. In practice that means a realtime tool can be refused when your Explorer Unit allowance is exhausted, even though the call itself is priced in Developer Units. If you hit an unexpected limit error on a realtime tool, check both balances.

​
Explorer Units

Query cost scales with the compute profile and query duration. The exact Explorer Unit cost of a run is returned in the get_query_run_results response, so your agent can report what a query actually cost.
Running SQL with run_sql_query and then saving the same SQL with create_explorer_query bills the compute twice. If the result might be reused, use create_explorer_query(run_on_creation=true) from the start.

​
Developer Units

Realtime tools call Allium’s Realtime APIs under the hood, so they consume Developer Units at the published per-endpoint rate — 20–60 DU depending on the endpoint. Batched calls multiply the cost by the number of inputs, so a realtime_token_latest_price call with 10 payloads costs 10× the single-call rate. See API Credits for the full per-endpoint table, and Realtime data for the tool-to-endpoint mapping.

​
When you run out

If your organization is over its credit cap or overage limit, billed tools fail with an error explaining the limit. Free tools keep working. Contact [email protected] to raise a limit.

​
Row limits

Two separate caps apply to SQL results, and mixing them up is the most common source of “where did the rest of my rows go?”. Raise the last one with row_limit, or pass null or 0 for no tool-side truncation. The default is deliberately small so a wide result doesn’t consume your agent’s whole context window.
Ad-hoc SQL is capped ten times lower than a saved query. If you need more than 1,000 rows, save the query with create_explorer_query rather than reaching for run_sql_query.
If you need more than 1,000 rows, aggregate in SQL rather than paginating through raw rows. Blockchain tables are large; a GROUP BY is almost always cheaper than moving rows into your agent.
Other limits:

​
Tool visibility

A few capabilities are enabled per organization. Where that applies, the tool is removed from tools/list entirely — your agent never sees it, rather than seeing it and failing on call. Individual skills work the same way: list_skills returns only the ones your organization can access. So the tool list your client shows can legitimately be shorter than the full tool list.
Visibility fails closed. If authentication fails, gated tools are hidden — so if you expect a tool and don’t see it, check that your API key is valid before assuming an access problem. Contact [email protected] if it’s still missing.

API Credits

Developer Unit cost per Realtime endpoint

Usage & billing

Check your org’s consumption in the App

Compute profiles

How warehouse size affects Explorer Units

SQL & queries

The async run and results flow