Skip to main content
Glama

portal_evm_get_ohlc

Build chart-ready OHLC candles and recent trade tape from Uniswap v2/v3/v4 and Aerodrome Slipstream swap events for EVM DEX pools.

Instructions

Build chart-ready EVM OHLC candles plus a recent trade tape from supported DEX event sources, including Uniswap v2-style swaps, Uniswap v3/v4, and Aerodrome Slipstream.

COMMON USER ASKS:

  • Base Uniswap v2-style swap candles

  • Base Uniswap candles

  • Base Uniswap v4 candles

WHEN TO USE:

  • You need OHLC candles for supported EVM event-derived price sources.

  • You want a candle chart and recent trades instead of scalar time-series buckets.

  • You want a Dexscreener-style pool chart with hover-ready candle metadata and a trade tape.

DON'T USE:

  • You only need counts or scalar metrics over time.

  • You want a simple activity chart for a network rather than pool candles.

EXAMPLES:

  • Base Uniswap v2-style swap candles: {"network":"base-mainnet","source":"uniswap_v2_swap","pool_address":"0x","duration":"1h","interval":"5m","price_in":"auto","include_recent_trades":true}

  • Base Uniswap candles: {"network":"base-mainnet","source":"uniswap_v3_swap","pool_address":"0x","duration":"1h","interval":"5m","price_in":"auto"}

  • Base Uniswap v4 candles: {"network":"base-mainnet","source":"uniswap_v4_swap","pool_id":"0x","duration":"1h","interval":"5m","price_in":"auto","include_recent_trades":true}

  • Base Aerodrome Slipstream candles: {"network":"base-mainnet","source":"aerodrome_slipstream_swap","pool_address":"0x","duration":"1h","interval":"5m","price_in":"token1"}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
feeNoOptional Uniswap v4 LP fee in hundredths of a bip, e.g. 3000 for 0.30%.
modeNoExecution depth. Defaults to complete requested-window analysis; the optional fast value is only for explicitly bounded previews.deep
cursorNoContinuation cursor from a previous candle page
sourceNoWhich event source to build candles from. Prefer swap-derived sources for factual trade prices and volumes. Uniswap v4 uses PoolManager Swap events filtered by pool_id, not a per-pool contract address.uniswap_v3_swap
networkNoEVM network name (default: base-mainnet)base-mainnet
pool_idNoUniswap v4 pool id (bytes32). Optional when you provide the full v4 pool key instead.
durationNoHow much recent history to cover. Accepts compact durations like "1h" or natural phrases like "past 30 minutes".1h
intervalNoCandle interval. auto uses chart-friendly defaults like 1h→5m and 24h→1h.auto
price_inNoChoose which token the displayed price should be expressed in. auto picks the more human-readable quote side.auto
base_tokenNoLegacy orientation input. Prefer price_in instead.
pool_addressNoPool/pair contract address for address-keyed sources like Uniswap v3, Slipstream, or Sync-derived CPMM pools.
tick_spacingNoOptional Uniswap v4 tick spacing. Required with the rest of the pool key when deriving pool_id.
hooks_addressNoOptional Uniswap v4 hooks contract address. Defaults to the zero address when omitted.
token0_symbolNoOptional token0 symbol label for summaries
token1_symbolNoOptional token1 symbol label for summaries
token0_addressNoOptional token0 address to infer known decimals
token1_addressNoOptional token1 address to infer known decimals
token0_decimalsNoOptional token0 decimals for human-readable prices
token1_decimalsNoOptional token1 decimals for human-readable prices
currency0_addressNoOptional Uniswap v4 currency0 address. Use with currency1_address, fee, and tick_spacing to derive pool_id factually.
currency1_addressNoOptional Uniswap v4 currency1 address. Use with currency0_address, fee, and tick_spacing to derive pool_id factually.
recent_trades_limitNoMaximum number of recent trades to return in the trade tape.
pool_manager_addressNoUniswap v4 PoolManager address. Optional on networks with a built-in official Uniswap deployment mapping.
include_recent_tradesNoInclude a recent trade tape for swap-derived sources when factual per-trade amounts are available.
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It describes the tool's output and supported data sources but does not disclose potential behavioral traits like rate limits, data freshness guarantees, or error handling. However, it clarifies that it produces candles from event-derived sources, which is sufficient for an agent to understand the core behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is well-structured with clear sections (common asks, when/don't use, examples). It is front-loaded with a concise summary. While somewhat lengthy, every section serves a purpose; minor verbosity in examples is acceptable for clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite no output schema, the description sufficiently indicates the return type: 'chart-ready OHLC candles plus a recent trade tape'. It covers all key aspects—supported sources, parameters, usage scenarios, and examples—making it complete for an agent to select and invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description adds value by providing real-world examples with JSON payloads for different sources, but the individual parameter descriptions in the schema already explain each field. The description does not significantly enhance parameter understanding beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states 'Build chart-ready EVM OHLC candles plus a recent trade tape from supported DEX event sources', using specific verb and resource. It lists supported sources (Uniswap v2, v3, v4, Aerodrome Slipstream) and distinguishes from siblings that focus on analytics, logs, or transactions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Includes explicit 'WHEN TO USE' and 'DON'T USE' sections, guiding when OHLC candles are appropriate vs scalar metrics. While alternative tool names are not mentioned, context from siblings (e.g., portal_evm_get_analytics, portal_get_time_series) provides implicit alternatives. The guidance is clear and actionable.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/subsquid-labs/portal-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server