Skip to main content
Glama
@true402.dev/mcp-server
by true402

whale_swaps

Recent large ($-value) DEX Swap events (Uniswap V3 + Aerodrome) on the Base pools the new-pairs watcher tracks — a whale-following / copy-trading signal. POST `{ min?, dex?, since?, limit?, direction?

Instructions

Recent large ($-value) DEX Swap events (Uniswap V3 + Aerodrome) on the Base pools the new-pairs watcher tracks — a whale-following / copy-trading signal. POST { min?, dex?, since?, limit?, direction? }; each swap gives the pool, token, quote (WETH/USDC), USD size, direction (buy/sell of the token), block + approx age, txHash. usdValue is the quote side (WETH×ETH-USD or USDC). Unpaid: free while the caller's IP has free-trial calls left that day (a small daily allowance shared across the trial stalls, no wallet); otherwise returns 402. (PAID x402 service — USDC on Base; the MCP server needs a funded wallet to settle.) Price: $0.005 USD (fixed).

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

Input Schema

NameRequiredDescriptionDefault
dexNoFilter: 'uniswap-v3' | 'aerodrome'
minNoOnly swaps of at least this USD size (default 10000)
limitNoMax swaps (1–200, default 50)
sinceNoOnly swaps at or after this block
directionNoFilter: 'buy' | 'sell' (of the non-quote token)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.0.0
    • addedInput schema / properties / dex / enum
      Added value: +[
      +  "uniswap-v3",
      +  "aerodrome"
      +]
    • addedInput schema / properties / direction / enum
      Added value: +[
      +  "buy",
      +  "sell"
      +]
  2. First observedv0.7.1

TDQS

A4.2/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so: it discloses the returned fields (pool, token, quote, USD size, direction, block + approx age, txHash), how usdValue is derived (quote side via WETH×ETH-USD or USDC), and the complete payment model including the 402 response, free-trial allowance shared across IP, and the fixed $0.005 price.

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?

Data scope and return shape are front-loaded, then the parameter signature, then payment terms — a logical order. It is dense and the payment/trial detail is verbose, but nearly every sentence contributes operational information an agent needs before calling.

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?

There is no output schema, and the description compensates by enumerating the return fields and their meaning. Combined with the disclosed cost/402 behavior for an unannotated paid tool, an agent has what it needs to call it and interpret the result.

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 defaults (min 10000, limit 1–200 default 50) and enum meanings are already documented. The description restates the parameter set and adds a mild clarification that direction is 'buy/sell of the token' and that usdValue is the quote side, but nothing beyond what the schema conveys.

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 resource (recent large DEX swap events on Uniswap V3 + Aerodrome, Base pools), the qualifying threshold ($-value), and frames the intended signal (whale-following / copy-trading). It also scopes itself to 'the pools the new-pairs watcher tracks', which distinguishes it from siblings like new_pairs and liquidity_pulls.

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

Usage Guidelines3/5

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

The phrase 'a whale-following / copy-trading signal' implies when the tool is useful, and the pool-scope note implies its boundary. However, it never states when NOT to use it or names an explicit alternative among the many sibling tools (new_pairs, liquidity_pulls, token_dossier), so selection still requires inference.

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