@true402.dev/mcp-server

liquidity_pulls

Liquidity-pull / rug alerts on Base — Burn (liquidity-removal) events on recently-launched DEX pools (the new-pairs watcher's set). POST `{ since?, limit?, dex?, minQuote?

Instructions

Liquidity-pull / rug alerts on Base — Burn (liquidity-removal) events on recently-launched DEX pools (the new-pairs watcher's set). POST { since?, limit?, dex?, minQuote? }; each event gives the pool, token, and WETH/USDC amount removed (the rug magnitude). Cross-check the token with /v1/token-safety. 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.003 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": "liquidity_pulls"
  }
}

Input Schema

Name	Required	Description
`dex`	No	Filter: 'uniswap-v3' \| 'aerodrome'
`limit`	No	Max pulls (1–200, default 50)
`since`	No	Only pulls first seen at or after this block
`minQuote`	No	Only removals of at least this much WETH/USDC

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.0.0Jun 28, 2026
- addedInput schema / properties / dex / enum
```
Added value: +[
+  "uniswap-v3",
+  "aerodrome"
+]
```
First observedv0.7.1Jun 20, 2026

TDQS

A3.9/5.0

Behavior4/5

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

With no annotations, the description carries the burden well: it discloses the POST interface, what each event contains (pool, token, WETH/USDC amount removed), the free-trial daily allowance shared across callers, the 402 fallback, and the x402/USDC settlement requirement with a fixed $0.003 price. Remaining gaps are minor — no ordering/pagination behavior or error semantics beyond 402.

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-loads the purpose and the parameter shape before the payment caveats, so the essential selection information comes first. The payment paragraph is comparatively long but is genuinely decision-relevant for this paid tool, so it earns its place.

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?

With no output schema and no annotations, the description supplies the return shape (pool, token, removed amount) and the full access/payment model, which is the information an agent most needs here. It stops short of explaining result ordering or how to detect an empty result set.

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 coverage is 100%, so each parameter is already documented in the schema. The description adds interpretive framing, notably that minQuote corresponds to rug magnitude and that since is block-based, but does not supply syntax or defaults beyond what the schema states. Baseline 3 is appropriate.

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?

States a specific verb and resource: liquidity-pull/rug alerts, defined concretely as burn (liquidity-removal) events on recently launched DEX pools, and scopes it to the new-pairs watcher's set, which implicitly separates it from the broader liquidity_history sibling. It does not explicitly name the sibling it replaces, so differentiation is inferred rather than stated.

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?

Gives explicit usage context (cross-check the token with /v1/token-safety) and states the payment/access precondition for calling it. There is no explicit 'use this instead of liquidity_history' routing, but the recent-pairs scoping and the cross-check recommendation give an agent enough to decide.

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