Skip to main content
Glama

Agent Utility Suite (x402)

by io.github.vanakenj45
OverviewDiscussionsAdmin

New token launches on Base, with risk verdicts

new_token_launches
Read-only

Answers "What tokens launched on Base in the last hour, and which look safe?" for trading and research agents. Finds every pool created against WETH, ETH or USDC on Uniswap v2, v3 and v4 and Aerodrome in the window (default the last 60 minutes, up to 6 hours), groups them by token, newest first, and runs each of the newest (up to 20) through token_risk_check: name and symbol, whether the contract itself is brand new, owner and renounced ownership, powers in its code (mint, blacklist, fees, pause, trading switch, limits), upgradeability, measured liquidity in USD, OFAC screening, and a verdict (high_risk, caution, no_flags) with reasons. Filter by minimum liquidity or hide high-risk tokens. Built for polling: each answer gives latest_block; pass it as since_block next time to get only newer launches. Read live from the chain. Not financial advice. You are only charged when a result is returned: invalid input (400) and upstream failures (4xx/5xx) are not settled. Costs $0.01 USDC per call via x402. Paid per call with x402 inside MCP (see the server instructions).

Input Schema

NameRequiredDescriptionDefault
viaNoOptional: the tool whose next_calls suggested this call (filled in for you).
limitNoHow many tokens to check, newest first (1-20, default 10). All new pools are counted either way.
minutesNoHow far back to look, in minutes (1-360, default 60). Ignored when since_block is given.
since_blockNoOnly pools created after this Base block: pass the previous answer's latest_block when polling (at most 6 hours back).
hide_high_riskNoLeave out tokens judged high_risk. Default false.
min_liquidity_usdNoLeave out tokens with less measured liquidity than this (USD). Default 0.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / via
      Added value: +{
+  "description": "Optional: the tool whose next_calls suggested this call (filled in for you).",
+  "maxLength": 64,
+  "type": "string"
+}
  2. Added

TDQS

A4.4/5.0
Behavior5/5

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

Goes well past the annotations (readOnly, openWorld, non-idempotent, non-destructive) by disclosing that it reads live from chain, runs risk checks, is built for polling via latest_block, costs $0.01 USDC per call via x402, and — critically — that invalid input (400) and upstream failures (4xx/5xx) are not settled. This charging/settlement detail is not derivable from any structured field.

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?

Purpose, scope, and polling pattern are front-loaded, and the dense enumeration of returned fields is informative rather than filler. It is long and slightly repetitive (the 6-hour limit appears twice), but nearly every sentence carries actionable content.

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 no output schema, the description carries the full burden of describing returns, and it does so in detail: name/symbol, new-contract flag, owner/renouncement, code powers, upgradeability, liquidity in USD, OFAC screening, and a verdict enum with reasons, plus latest_block for polling. An agent has everything needed to call and interpret it.

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 the schema already documents every parameter. The description restates the window limits (60 min default, up to 6 hours), the newest-first cap (up to 20), and the liquidity/high-risk filters, but adds no format or syntax detail beyond what the schema provides. 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 specific verbs and resources: it 'finds every pool created against WETH, ETH or USDC on Uniswap v2/v3/v4 and Aerodrome,' groups them, and runs the newest through token_risk_check. An agent can distinguish this (a launch-discovery + verdict tool) from siblings like token_launches_peek or token_risk_check 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 Guidelines4/5

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

Clearly frames the use case (trading/research agents asking what launched and which look safe) and gives the polling workflow with since_block. It also notes the default 60-minute window up to 6 hours. However, it never explicitly contrasts with the sibling token_launches_peek, leaving the agent to infer the distinction between a full verdict run and a cheap peek.

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

All Agent Utility Suite (x402) toolsInspect
Try in Browser
Give agents eyes on the webHosted screenshot MCP. Send a URL, get a pixel-perfect image. $0.002 per grab. Works with Claude, Cursor, and Codex.grabbit.liveAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources