Skip to main content
Glama

Bitquery: Crypto & Blockchain Data

Robinhood Contract Creator

robinhood_contract_creator
Read-only

WHO CREATED a Robinhood (robinhood, rh, Robinhood Chain) contract, and what a creator deployed. Answers "who created / deployed this token", "who is behind this contract", "what else did this deployer launch", and "were these tokens made by the same person" (serial deployers, rug and clone farms). NOT who funded a wallet → use robinhood_first_funder. On this chain a token IS a contract, so pass the TOKEN'S CONTRACT ADDRESS in contracts. TWO WAYS TO CALL IT, pick one - setting both is refused, because the two answer different questions and their shared-creator counters would be mixed: contracts="0x..|0x.." - up to 50 contracts, one row each: Creator (the address whose code ran CREATE), Signer, Created_At, Block_Number, Tx, Deploy_Value, Gas_Used and Deploy_Success. Rows whose creator or signer is SHARED come first: Creator_Shared / Signer_Shared count how many of the requested contracts have that same creator / signer, which is what exposes one person behind many tokens. A longer list is not an error: the first 50 distinct addresses are used and the rest ignored - compare Contracts_Requested with Contracts_Used and split a longer list into several calls. creator="0x.." - the contracts THAT address deployed, newest first, inside the window (days, after_time, before_time), at most limit rows. Use it on the Creator or Signer a first call returned, to see the rest of that deployer's output. Creator_Shared is empty in this form - every row has the same creator by construction, so the counter would only repeat the row count. Creator_Is_Contract = 1 means the contract was deployed BY OTHER CONTRACT CODE - a token factory, a launchpad or a DEX pair factory - and then Creator is that factory, which is the SAME address for every token it ever made, while Signer is the person who asked for it. On a factory-made token read Signer, not Creator. Deploy_Depth is how deep inside the transaction the deployment happened (0 = the transaction itself) and Call_Index is the deployment's position in that transaction - one transaction can deploy several contracts, and Call_Index is what tells those rows apart when everything else about them looks the same. Status = NOT_FOUND means no deployment is recorded for that address: it is a plain wallet, not a contract, or the deployment is older than the recorded history of this chain. Creations is normally 1; a higher number means the address was created more than once (destroyed and redeployed), and the row describes the EARLIEST creation. THE CREATOR'S STORY IS NOT IN THIS TOOL - build it from the returned addresses: labels_for_addresses (is the creator a known entity, exchange or scammer), robinhood_first_funder (who funded the creator, and whether several creators share one sponsor), robinhood_address_profile and robinhood_transfers_in / robinhood_transfers_out (what that wallet does), robinhood_flows_between (what moved between the creator and the token). The token's own name, symbol, price and market cap come from find_token_by_address; its first buyers from early_buyers. Amounts are the native coin, never USD. COST: a contract lookup has to walk every call that address ever received, so a handful of ordinary tokens answer in a second or two while one exchange-scale contract can take ~20 s on its own. If you already know roughly when the contract appeared, bound it with after_time / before_time - that alone took one busy token from 21 s to 2 s. A row-limit error ("Limit for rows ... exceeded") means the batch is too busy: bound it that way, or split the list.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "robinhood_contract_creator"
  }
}

Input Schema

NameRequiredDescriptionDefault
daysNoCreator lookup only: window length in days ending at before_time (or now), 1-3660. Ignored when after_time is set, and ignored entirely when contracts is set (a contract lookup searches the whole recorded history).
limitNoMax contracts to return for a creator lookup, newest first. At most 1000. Ignored when contracts is set.
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
creatorNoLook up the contracts THIS address deployed instead, 0x-hex (case-insensitive). Pass a Creator or Signer returned by a contracts call. Empty (default) = look up contracts instead. Setting neither returns no rows.
contractsNoContract addresses to look up the creator of, 0x-hex (case-insensitive), separated by "|" - up to 50; addresses after the 50th distinct one are ignored (compare Contracts_Requested with Contracts_Used). For a token, this is the token's contract address. Empty = use creator instead.
after_timeNoOnly deployments at/after this UTC time (e.g. "2026-01-01"). Works in BOTH modes: on a creator lookup it overrides days, and on a contract lookup it is the cheapest way to make a busy address fast. Empty = no lower bound on a contract lookup, the last `days` days on a creator lookup.
before_timeNoOnly deployments strictly before this UTC time. Works in both modes. On a creator lookup 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.

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.9/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=true / destructiveHint=false; the description goes far beyond by disclosing cost profiles (~1–2 s typical, ~20 s for exchange-scale contracts), a concrete optimization (after_time took a token from 21 s to 2 s), the row-limit failure mode and its fix, and the silent 50-address truncation with the Contracts_Requested vs Contracts_Used check. It also explains tricky result semantics: Creator_Is_Contract, Signer vs Creator on factory-made tokens, Deploy_Depth, Call_Index, Status=NOT_FOUND, and Creations>1 describing the earliest creation.

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?

The lead is front-loaded with purpose and the sibling exclusion, and sections are visually separated by the two-mode block, the contract-metadata glossary, and the follow-up pointer. It is long (~500 words) and repeats the mode-exclusivity point in both the prose and each schema field, but given the tool's dual-mode complexity and failure modes, nearly every sentence carries information.

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?

No output schema exists, yet the description names the returned columns per mode (Creator, Signer, Created_At, Block_Number, Tx, Deploy_Value, Gas_Used, Deploy_Success, Creator_Shared/Signer_Shared), explains Creator_Shared's emptiness in creator mode, and covers errors and follow-up tools. An agent has everything needed to invoke it and interpret the rows.

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%, so baseline is 3, but the description adds genuinely new meaning: the mutual exclusivity of contracts/creator, which parameters are ignored in each mode, the 50-distinct-address cap and how to detect truncation, and after_time/before_time as both a cost lever and a window-walking mechanism (set before_time to a row's Window_From). It also clarifies units (native coin, never USD).

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+resource ("WHO CREATED a Robinhood contract, and what a creator deployed") and immediately enumerates the exact questions it answers. It explicitly separates itself from robinhood_first_funder ("NOT who funded a wallet") and from find_token_by_address / early_buyers, so an agent can route correctly without opening a schema.

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?

It gives two named call modes (contracts= vs creator=), states that setting both is refused and why, and prescribes the intended workflow: call contracts first, then feed the returned Creator or Signer into creator= to see the rest of that deployer's output. Exclusions are explicit ("NOT who funded a wallet → use robinhood_first_funder") and follow-up tools are listed by name.

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.