Skip to main content
Glama

launch_ledger

Robinhood Chain (chain id 4663) token launches that cleared a first-hour activity floor, with the early-buyer cohort: the first ~25 distinct wallets that bought (transaction sender, never the router), each with block delta from launch and quote spent. Every launch is graded at 24h and 7d (price multiple vs first buy, liquidity, holders). Launchpad is identified from the Uniswap v4 hook. Recorded forward from 2026-09-03 straight from chain logs: happened_at is the launch block time, observed_at is when the cohort was banked. Not backfilled.

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": "launch_ledger"
  }
}

Input Schema

NameRequiredDescriptionDefault
paidNotrue = request the pay-per-call (x402) quote or the live tier. Without a payment attached the call returns the x402 PaymentRequired object as an isError result; attach the signed payment at _meta["x402/payment"] (or the PAYMENT-SIGNATURE header) and retry. Omit for the free, delayed tier.
quoteNoQuote asset: ETH, WETH, USDG, or a stock token symbol
sinceNoOnly launches on/after this YYYY-MM-DD
tickerNoToken symbol as the deployer named it (untrusted text)
walletNoLaunches this address was early in, or deployed
min_usdNoMinimum first-hour buy volume, USD estimate
tickersNoComma-separated token symbols
launchpadNoSubstring match, e.g. doppler, launchhook, none
min_buyersNoMinimum distinct early buyers captured

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / paid
      Added value: +{
      +  "description": "true = request the pay-per-call (x402) quote or the live tier. Without a payment attached the call returns the x402 PaymentRequired object as an isError result; attach the signed payment at _meta[\"x402/payment\"] (or the PAYMENT-SIGNATURE header) and retry. Omit for the free, delayed tier.",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / tickers
      Added value: +{
      +  "description": "Comma-separated token symbols",
      +  "type": "string"
      +}
  2. Added

TDQS

A3.5/5.0
Behavior4/5

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

With no annotations, the description carries real weight: it discloses data provenance (straight from chain logs), the exact cohort definition (first ~25 distinct wallets, transaction sender never the router), and the 'not backfilled / recorded forward from 2026-09-03' limitation. Gaps remain — it never states this is a read-only query, says nothing about result limits/pagination, and the pay-per-call x402 gating lives only in the schema, not the description.

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

Conciseness3/5

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

The clause-level density is high with little filler, and the resource is front-loaded. But it is a single run-on sentence stitched with colons and semicolons, so provenance, grading cadence, cohort definition and backward-fill caveats all blur together without structural cues.

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?

For a filterable dataset with 9 optional params and no output schema, the description covers the return content (cohort with block delta and quote spent; 24h/7d grading on multiple, liquidity, holders) and the temporal scope. What it omits — ordering, pagination, and the free-vs-paid tiering that governs whether the call even returns data — keeps it from being fully complete.

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 3 is the baseline, but the prose adds meaning the schema alone does not: it clarifies that 'early buyers' means the first ~25 distinct transaction senders (never the router), which sharpens min_buyers, and ties launchpad to the Uniswap v4 hook, sharpening the launchpad filter. That is genuine added semantics beyond the field descriptions.

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

Purpose4/5

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

The description pins down a highly specific resource: Robinhood Chain (chain id 4663) token launches that cleared a first-hour activity floor, with the early-buyer cohort and 24h/7d grading. An agent can tell it is a launch-ledger dataset, not a wallet list like launch_wallets. It lacks an explicit verb ('returns'/'lists') and never names or contrasts a sibling, so it stops short of a 5.

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

Usage Guidelines2/5

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

There is no when-to-use / when-not-to-use guidance and no routing to alternatives such as launch_wallets. The only constraint offered is 'not backfilled' and the forward-recording start date (2026-09-03), which bounds results but does not tell the agent when this tool is the right pick.

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.

Resources