Skip to main content
Glama

Bitquery: Crypto & Blockchain Data

Eth First Funder

eth_first_funder
Read-only

FIRST FUNDER / COMMON SPONSOR of up to 50 Ethereum (eth, ETH, mainnet, L1) addresses: for each address the EARLIEST incoming transfer INSIDE THE WINDOW (by default the last 180 days - not necessarily the first ever, see WINDOW) - who sent it (Funder), who signed that transaction (Tx_From), when (First_Time), how much of which token, and the Tx. Answers "who funded these wallets" and "do these wallets share a sponsor" (sybil, sniper and airdrop-farming clusters). NOT who deployed a contract → use eth_contract_creator. Pass the addresses separated by "|". A longer list is not an error: the first 50 distinct addresses are used and the rest are ignored - every row reports Addresses_Requested / Addresses_Used, so compare them and split a longer list into several calls. One row per used address, and rows whose funder is shared come FIRST: Funder_Shared = how many of the requested addresses have that same first funder, Tx_From_Shared = the same count for the transaction's signer - it catches wallets funded through a public batch-sending contract, where Funder is the contract and the signer is the real sponsor. Funder_In_Set = 1 when the funder is itself one of the requested addresses (a funding chain). Via_Internal_Call = 1 marks funding sent by contract code deeper inside a transaction; the transfer a transaction makes itself is top-level, so it reads 0. Incoming_In_Window = how many qualifying incoming transfers the address had in the window. WHAT COUNTS AS FUNDING: by default native ETH only (asset_type="native"), including ETH sent by contract code (include_internal=1); set asset_type="token" or "all", or pin one token with contract, to look at token funding instead. Zero-amount transfers, mints and self-transfers never count; raise min_amount to skip dust. WINDOW: the first funding INSIDE the last days days (default 180, at most 730) ending at before_time or now, or starting at after_time within the same limit. Status = FIRST_IN_WINDOW: the earliest qualifying funding between Window_From and Window_To. It is the address's first-ever funding ONLY if the address had no activity before Window_From, and this tool does not check that. To check one address, compare First_Time with the First_Received of eth_address_profile for it (an earlier First_Received means it already received something before the window). To look further back, call again with before_time set to the row's Window_From. Status = NO_INCOMING_IN_WINDOW means nothing qualifying arrived in the window: call again for those addresses with before_time set to their Window_From to look further back. COST grows with the number of addresses times the length of the window: for dozens of addresses keep days at 180 and page back with before_time rather than widening days. A row-limit error ("Limit for rows ... exceeded") means an address in the list is too busy (an exchange, bridge or popular contract) or the window is too long - drop that address or shorten days. Amounts are TOKEN UNITS, never USD. To identify funders, pass them to labels_for_addresses; to see everything that moved between the funders and the wallets, use eth_flows_between.

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": {
      "addresses": "<addresses>"
    },
    "name": "eth_first_funder"
  }
}

Input Schema

NameRequiredDescriptionDefault
daysNoWindow length in days ending at before_time (or now), 1-730. Ignored when after_time is set. For older history set before_time to a row's Window_From instead of widening days.
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
contractNoOnly count funding in ONE exact token, by its contract address (0x-hex (case-insensitive)). Use it with asset_type=token or all. Empty = no token filter.
addressesYesAddresses to look up, 0x-hex (case-insensitive), separated by "|" - up to 50; addresses after the 50th distinct one are ignored (compare Addresses_Requested with Addresses_Used).
after_timeNoOnly funding at/after this UTC time (e.g. "2026-01-01"). Overrides days. Empty = the last `days` days.
asset_typeNonative (default) = only ETH counts as funding; token = only tokens; all = anything.native
min_amountNoMinimum amount of the funding transfer, in that token's own units. 0 (default) = any non-zero amount.
before_timeNoOnly funding strictly before this UTC time - set it to a row's Window_From to search the next older window. 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.
include_internalNo1 (default) = also count ETH sent by contract code inside a transaction (batch senders, exchange withdrawal contracts), so wallets funded that way are not missed; 0 = only top-level ETH transfers. A transaction's own transfer is top-level, not internal, and is counted either way. Only 0 or 1.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / format
      Added value: +{
      +  "default": "rows",
      +  "description": "Shape 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.",
      +  "type": "string"
      +}
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the readOnly/non-destructive annotations, it discloses the truncation behavior (first 50 distinct addresses, rest silently ignored, compare Addresses_Requested vs Addresses_Used), the cost model (addresses × window length), the row-limit failure mode and its cause (busy exchange/bridge address), and the important semantic caveat that FIRST_IN_WINDOW is not necessarily first-ever.

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?

Well-organized with labeled sections (WHAT COUNTS AS FUNDING, WINDOW, Status, COST) and output-field explanations, and the scope statement is front-loaded. The opening sentence is a long dash-and-parenthesis pile-up that could be split, and a few points (window/Status paging) are repeated in slightly different words.

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?

For a 9-parameter, no-output-schema tool this is thorough: it names and explains every output column (Funder, Tx_From, First_Time, Funder_Shared, Tx_From_Shared, Funder_In_Set, Via_Internal_Call, Incoming_In_Window, Addresses_Requested/Used), covers both Status values with recovery actions, and flags the busy-address failure mode. An agent can call and interpret this correctly without further guessing.

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 100%, so the baseline is 3, but the description adds real meaning: what counts as funding (native ETH default, zero-amount/mint/self-transfers excluded, min_amount to skip dust), the asset_type modes, internal-vs-top-level distinction for include_internal, and the days-vs-before_time trade-off. It largely restates schema-documented parameters, so it earns a 4 rather than a 5.

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 specific verb-plus-resource ('FIRST FUNDER / COMMON SPONSOR of up to 50 Ethereum addresses') and immediately scopes the answer ('EARLIEST incoming transfer INSIDE THE WINDOW'). It explicitly excludes the confusable sibling ('NOT who deployed a contract → use eth_contract_creator') and names the analytic question it answers (who funded these wallets / shared sponsor clusters).

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 explicit when-to-use framing (sybil, sniper, airdrop-farming clusters), explicit routing to alternatives (eth_contract_creator for deployment, eth_address_profile for first-ever checks, labels_for_addresses for attribution, eth_flows_between for full movement), and explicit paging strategy (before_time on Window_From rather than widening days).

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.