Skip to main content
Glama

Bitquery: Crypto & Blockchain Data

Matic Token Senders

matic_token_senders
Read-only

TOKEN SENDERS COHORT on Polygon (matic, POL, MATIC, PoS): the addresses that SENT a given token at least min_transfers times inside a time window, most recently active first - "wallets that actively use this token", "build a cohort or airdrop list of recent senders of this token". NOT one wallet's own outgoing transfers → use matic_transfers_out. This counts SENDERS of the token, one row per sender; it does not value or label them - pass the returned addresses to labels_for_addresses, and to matic_native_balances to keep only funded wallets. By default only normal user wallets (EOAs) that sent the token in their OWN transaction count (eoa_only=1); set eoa_only=0 to include contract senders. Pass the token's CONTRACT address in token (0x-hex (case-insensitive)); a symbol also matches clone tokens, so pin the exact contract. WINDOW: the last days days (default 1, at most 30) ending at before_time or now; after_time sets the start instead. A sender must reach min_transfers sends WITHIN this window, so a short recent window keeps only clearly-active wallets - the recency the cohort wants. There is no full-history mode: to go further back, page with before_time. PAGING: newest-active first, at most limit rows. If the result has limit rows there may be more - set before_time to the oldest Last_Transfer_Time returned and call again, then combine and de-duplicate the pages. COST grows with the token's volume times the window: widen days step by step. A row-limit error ("Limit for rows ... exceeded") means the token is too busy for that window - shorten days. Each row: Address, Transfers, First_Transfer_Time, Last_Transfer_Time.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "token": "<token>"
    },
    "name": "matic_token_senders"
  }
}

Input Schema

NameRequiredDescriptionDefault
daysNoWindow length in days ending at before_time (or now), 1-30. Ignored when after_time is set.
limitNoMax senders to return, most recently active first. At most 5000.
tokenYesThe token's CONTRACT address (0x-hex (case-insensitive)) whose senders to list. Pin the exact token - a symbol matches clone tokens.
formatNoShape of the returned data. "rows" (the default) returns one item per row. "columnar" returns a single item, {"columns":[...],"rows":[[value,...],...]}, naming the columns once and listing each row's values in that order; it is more compact for large results and carries the same values.rows
eoa_onlyNo1 (default) = only normal user wallets (EOAs), i.e. the sender signed the transaction itself; 0 = any sender, contracts included. Only 0 or 1.
after_timeNoOnly sends at/after this UTC time (e.g. "2026-06-01"). Overrides days. Empty = the last `days` days.
before_timeNoOnly sends strictly before this UTC time - set it to the oldest Last_Transfer_Time of a full page to get the next one. Empty = up to now. Format: YYYY-MM-DD, YYYY-MM-DD HH:MM[:SS], ISO-8601 like 2026-09-20T00:00:00Z (fraction or +02:00 offset allowed) or 10-digit unix seconds.
min_transfersNoMinimum number of sends of this token by an address inside the window to include it (default 11). 1-1000.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only cover the safety profile (readOnly/not destructive), and the description adds substantial behaviour beyond that: cost scales with token volume times window, a specific 'Limit for rows ... exceeded' error means the window is too wide, results are capped at `limit` with a paging recipe, and EOA-vs-contract sender semantics. It also warns that a symbol matches clone tokens, which prevents a real class of wrong calls.

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?

Front-loaded with the core definition and the sibling exclusion, then structured with WINDOW/PAGING/COST/row-shape segments that are easy to scan. It is longer than necessary in places, restating schema facts (contract address format, eoa_only values) that the parameter descriptions already carry.

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?

With eight parameters, no output schema, and a non-obvious cost/paging model, the description covers everything an agent needs: window semantics, paging protocol, error interpretation, cost control, and the exact row fields returned. Nothing material is left to inference.

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

Parameters4/5

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

Schema coverage is already 100%, so the schema documents every parameter; the description nevertheless adds meaning the schema does not, such as why a short window is desirable ('keeps only clearly-active wallets - the recency the cohort wants'), how min_transfers interacts with the window, and how to use before_time for paging. It mostly repeats schema text for token/eoa_only rather than adding to it, which keeps it out of the top score.

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?

Opens with a precise verb+resource+scope: 'TOKEN SENDERS COHORT on Polygon... addresses that SENT a given token at least min_transfers times inside a time window'. It explicitly distinguishes itself from the nearest sibling ('NOT one wallet's own outgoing transfers → use matic_transfers_out') and from holders-style tools, so an agent can route correctly without opening schemas.

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?

Gives concrete use cases ('build a cohort or airdrop list of recent senders'), an explicit negative case with the alternative tool, and a two-step workflow chaining the output into labels_for_addresses and matic_native_balances. It also states there is no full-history mode and prescribes paging with before_time instead.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.