Skip to main content
Glama

Base launches

get_base_launches
Read-onlyIdempotent

Use when an agent needs the newest token launches on Base. Returns pools created on Base in the last 24 hours on Uniswap V4, V3, V2 and Aerodrome, newest first, with launchpad, liquidity and volume. Each carries its pair, creation time, launchpad named from the V4 hook (Zora, Clanker, Doppler, Flaunch), quote-side liquidity, 24h volume and swaps, and our honeypot simulation for the busiest. Read from Base logs every minute; a snapshot older than 5 minutes answers 503. Costs 0.02 USDC per call (x402, USDC on Solana, Base, Polygon, Arbitrum or Arc).

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

Input Schema

NameRequiredDescriptionDefault
limitNolaunches returned, newest first, 1-100, default 20
min_liq_usdNominimum quote-side liquidity (ETH, WETH or USDC held) in USD, default 1000; 0 lists every launch

Output Schema

NameRequiredDescriptionDefault
dataYesthe get_base_launches payload; a real captured example is free at https://x402.ochinimus.app/api/sample/get_base_launches
toolYesthe tool that produced this payload

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / limit / maximum
      Added value: +100
    • addedInput schema / properties / limit / minimum
      Added value: +1
    • addedInput schema / properties / min_liq_usd / maximum
      Added value: +1000000000000
    • addedInput schema / properties / min_liq_usd / minimum
      Added value: +0
  2. Added

TDQS

A4.4/5.0
Behavior5/5

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

Goes well beyond the annotations by disclosing data freshness (logs refreshed every minute, stale snapshot older than 5 minutes returns 503), the exact return contents, and the x402 payment model with cost and accepted chains. These are operationally critical facts an agent cannot infer from readOnlyHint/idempotentHint alone.

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 trigger and scope, then builds outward to return contents, freshness, and pricing. It is dense and information-rich, though the long single paragraph enumerating return fields could be tightened slightly.

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?

Covers the trigger, the data sources and venues, the freshness SLA and failure mode (503), the payment requirement, and the return shape. Even though an output schema exists, nothing an agent needs to call this correctly or interpret a failure is missing.

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

Parameters3/5

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

Schema description coverage is 100%, so both parameters (limit, min_liq_usd) are already fully documented with ranges and defaults. The description reinforces quote-side liquidity semantics but adds no syntax or edge-case guidance beyond the schema, so baseline 3 is appropriate.

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?

States a specific verb and resource ('newest token launches on Base') plus scope: pools created in the last 24 hours across Uniswap V4/V3/V2 and Aerodrome, newest first. It clearly distinguishes itself from siblings like get_honeypot_check or get_token_risk by being a launch-feed, not a per-token check.

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

Usage Guidelines4/5

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

Opens with an explicit trigger ('Use when an agent needs the newest token launches on Base'), giving clear when-to-use context. It doesn't name an alternative tool or state when not to use it, so it falls short of the top score.

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.