Skip to main content
Glama

portal_get_time_series

Aggregate blockchain metrics into time buckets for simple activity charts, with compare-previous and contract grouping features.

Instructions

Build simple activity charts and other time-series views across supported VMs, including compare-previous windows and grouped EVM contract trends.

COMMON USER ASKS:

  • Base transactions per 15m bucket

  • Compare two periods

FIRST CHOICE FOR:

  • activity over time, compare-current-vs-previous, grouped trends, and simple activity charts

WHEN TO USE:

  • You want chart-ready metric buckets over time.

  • You want a simple activity chart for a network, defaulting to a 6h interactive window unless a longer window is explicitly requested.

  • You want to compare the current period to the previous period.

DON'T USE:

  • You need raw record lists instead of aggregated buckets.

  • You need DEX pool candles or OHLC output.

EXAMPLES:

  • Base transactions per 15m bucket: {"network":"base-mainnet","metric":"transaction_count","duration":"6h","interval":"15m"}

  • Compare two periods: {"network":"solana-mainnet","metric":"transaction_count","duration":"1h","interval":"5m","compare_previous":true}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNoExecution depth. Defaults to complete requested-window analysis; the optional fast value is only for explicitly bounded previews.deep
metricYesMetric to aggregate over time
addressNoOptional: Filter to specific contract address for contract-specific trends
networkYesNetwork name (supports short names: 'ethereum', 'polygon', 'base', etc.)
durationNoTotal time period to analyze. Defaults to "6h" for interactive use. Explicit longer windows like "24h" or "7d" are supported but can take longer. Accepts compact durations like "30m" or natural phrases like "past 30 minutes".6h
group_byNoOptional grouping mode. contract is currently supported only for EVM transaction_countnone
intervalYesTime bucket interval (5m, 15m, 1h, 6h, 1d)
group_limitNoMaximum number of contract groups when group_by=contract
to_timestampNoEnding timestamp. Accepts Unix seconds, Unix milliseconds, ISO datetime, or relative input like "now".
from_timestampNoStarting timestamp. Accepts Unix seconds, Unix milliseconds, ISO datetime, or relative input like "24h ago".
compare_previousNoCompare the selected window against the immediately previous window
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 default duration, execution modes (fast/deep), and comparison behavior, but does not explicitly state read-only nature or authorization needs. Adequate but could be more explicit.

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

Conciseness5/5

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

Well-structured with clear sections (COMMON USER ASKS, FIRST CHOICE FOR, WHEN TO USE, DON'T USE, EXAMPLES). Each sentence serves a purpose. Front-loaded with main purpose. No fluff.

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

Completeness4/5

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

Rich context for a complex 11-parameter tool: provides use cases, exclusions, parameter behaviors, and examples. However, absence of output schema means description could better explain the return format (e.g., structure of the bucket data). Still, overall comprehensive.

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

Parameters5/5

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

Schema coverage is 100% but description adds significant value beyond schema: explains default behaviors ('Defaults to 6h for interactive use'), acceptable formats ('compact durations like 30m or natural phrases'), and includes concrete examples that demonstrate parameter combinations.

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 the verb 'Build' and resource 'simple activity charts and other time-series views across supported VMs'. It distinguishes from siblings by mentioning specific use cases like 'compare-previous windows and grouped EVM contract trends' and contrasts with OHLC output in DON'T USE.

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

Usage Guidelines5/5

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

Explicit sections 'FIRST CHOICE FOR', 'WHEN TO USE', and 'DON'T USE' provide clear guidance on when to select this tool over alternatives. Examples further illustrate appropriate use cases.

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