@true402.dev/mcp-server provides pay-per-call access to AI inference, web analysis, and blockchain tools via x402 micropayments (USDC on Base) — no accounts or API keys needed, just a funded wallet.
AI Inference
chat — Send chat completions to many LLMs (GPT-4o, Claude, Gemini, etc.), priced per token + 3%
list_models (free) — List available models with live per-token pricing
Web Analysis
web_extract — Fetch any URL and return clean text, markdown, links, and metadata
link_preview — Fetch a URL's Open Graph card (title, description, image, favicon)
seo_audit — Full SEO + generative-engine optimization (GEO) audit with structured scores and issues
robots_check — Check a site's AI-crawler policy (GPTBot, ClaudeBot, etc.), sitemaps, and llms.txt
headers_check — Analyze HTTP security headers (HSTS, CSP, etc.) with a 0–100 score
Blockchain / Token Safety (Base)
token_safety — Rug/honeypot pre-check: ERC-20 conformance, ownership, mint capability, liquidity depth, buy/sell simulation, and risk score
token_report — Composite report combining token safety, liquidity-pull history, and whale activity into a single verdict (ok/caution/avoid)
address_safety — Structural profile of any Base address: EOA vs. contract, balances, tx count, proxy detection, and risk flags
deployer_check — Deployer wallet reputation: age, balance, contracts shipped, and throwaway-wallet detection
new_pairs — Recently created DEX pairs (Uniswap V3 / Aerodrome) for fresh token launch monitoring
liquidity_pulls — Liquidity-removal / rug alerts on Base DEX pools
whale_swaps — Large USD-value swaps on Base DEX pools for whale-flow signals
All paid tools use x402 micropayments: the server signs EIP-3009 USDC authorizations from the configured wallet; gas is sponsored. Without a wallet, paid tools return payment requirements instead of executing.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@@true402.dev/mcp-server check token safety for 0x1f984"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for the true402 machine-native marketplace — give your agent pay-per-call access to AI inference and web tools over x402 (HTTP 402 micropayments in USDC on Base).
No accounts, no API keys. The agent's wallet is its identity: each paid tool returns an HTTP 402 challenge, the server signs an EIP-3009 USDC authorization, and the call settles on-chain. Configure a funded wallet to auto-pay, or run without one and the paid tools will surface the exact payment requirements instead of failing.
Tool | Price | What it does |
| per-token + 3% | OpenAI-compatible LLM inference across many models |
| free | List available models + pricing |
| $0.005 | ERC-20 rug/honeypot pre-check on Base → 0–100 score, risk band, flags, liquidity depth + a buy/sell honeypot simulation |
| $0.04/page | SEO + GEO (generative-engine-optimization) audit of a page → structured report |
| $0.005 | Fetch a URL → clean text + markdown + links + metadata |
| $0.003 | Fetch a URL → Open Graph / unfurl card |
| $0.003 | A site's AI-crawler policy (GPTBot, ClaudeBot, Google-Extended, PerplexityBot, …) + sitemaps + llms.txt |
| $0.003 | HTTP security-headers analysis (HSTS, CSP, …) + a 0–100 score |
| $0.003 | Newly created Base DEX pairs (Uniswap V3 / Aerodrome) — fresh token launches |
| $0.003 | Liquidity-removal / rug alerts on Base pools |
| $0.005 | Large swaps on Base by USD size — whale flow |
| $0.01 | Fuller on-chain token report |
| $0.005 | What ALREADY happened to a Base token's liquidity — every removal with amount/block/tx, plus the other tokens drained in the same transaction. History a live simulation cannot re-derive |
| $0.008 | Check an unsigned Base transaction before signing: does it revert, does it grant an unlimited approval, and has the counterparty been seen draining liquidity. Takes no key and no signature, so it cannot broadcast or front-run |
Tools are auto-discovered from the live catalog, so new marketplace stalls appear automatically. Prices are illustrative; the live 402 challenge is authoritative.
Related MCP server: x402-mcp
A copy-paste reference in examples/token-safety/ — a framework-agnostic
x402 client plus a drop-in LangChain tool that rug/honeypot-checks any Base token for $0.005/call.
Requires Node.js ≥ 20. Runs over stdio — point any MCP client at it via npx.
Add to your MCP config (claude_desktop_config.json, or .mcp.json for Claude Code):
{
"mcpServers": {
"true402": {
"command": "npx",
"args": ["-y", "@true402.dev/mcp-server"],
"env": {
"WALLET_PRIVATE_KEY": "0xYOUR_FUNDED_BASE_WALLET_KEY"
}
}
}
}Same idea — command npx, args ["-y", "@true402.dev/mcp-server"], and the WALLET_PRIVATE_KEY env var.
Env var | Default | Description |
|
| true402 API base. Override to point at a self-hosted instance. |
| (none) | A funded Base wallet private key used to sign x402 payments. Needs USDC (gas is sponsored by the facilitator — no ETH required). Without it, paid tools return the 402 requirements instead of paying. |
|
| Hard per-call spend ceiling in USDC. This server auto-discovers every paid stall the marketplace advertises (it walks the live OpenAPI spec, not a fixed list), so a new or repriced stall can appear above the default at any time — a call over the ceiling is refused (not paid, not crashed), and the refusal names the price and the ceiling. Raise it if a discovered tool's description shows a price close to or over your configured value; one stall ( |
Security: the key is read only from the environment and is never logged, echoed, or returned. Use a dedicated low-balance wallet — fund it with only what you intend to spend.
The tool calls the true402 endpoint with no payment.
The server replies 402 with accepted payment options (USDC on Base).
This MCP server signs an EIP-3009 transferWithAuthorization with your wallet.
It retries with the signed X-PAYMENT header; the service verifies and responds.
Settlement happens on-chain. Your wallet pays only USDC — the facilitator sponsors gas.
Marketplace: https://true402.dev
Free Telegram rug-check bot (no wallet): https://t.me/True402bot
Live tool catalog: https://true402.dev/api/v1/services
x402 protocol: https://x402.org
MCP (Claude Code / Desktop, Cursor, Hermes) · Hermes Agent · OpenClaw · ElizaOS · LangChain · CrewAI · Vercel AI SDK · Coinbase AgentKit · Virtuals GAME · CLI — same on-chain checks, one install command each: true402.dev/integrations
The rules below are the service's, not this package's — they bite whatever client you use, and they are the ones that surprise people writing their own payer.
Pay the EXACT amount quoted in the 402. Underpaying is rejected. Overpaying is refused with 403 and never credited — settlement submits the signed value and there is no refund path, so a surplus would simply be swept. Equality is also what binds an authorization to the resource it was quoted for.
One authorization buys exactly one response. A replay is refused, not double-charged.
You are charged on success only. Settlement is submitted only when the endpoint returns 2xx; if it errors or times out, your signed authorization is never submitted, so there is nothing to refund.
Some endpoints serve a few free calls per day per client IP, with no wallet. The per-operation description in the OpenAPI spec says which.
Full rules: true402.dev/terms · what is logged and kept: true402.dev/privacy
MIT
Structural safety profile for ANY Base address — an EOA or an arbitrary contract — before an agent sends funds to it, approves it, or calls it. Returns contract-vs-EOA, ETH + USDC balance, tx-count (activity), and for contracts: whether it is a recognised ERC-20, ownership state, a mint() selector, and whether it is an EIP-1967 upgradeable proxy (its logic can be swapped after you trust it). Coarse risk band + flags. On-chain reads only — no API key. POST { address }. Unpaid returns 402. (PAID x402 service — USDC on Base; the MCP server needs a funded wallet to settle.)
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | Chain to check; only 'base' is supported (default) | |
| address | Yes | Any address (0x…) on Base — an EOA or a contract |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It reveals the tool is read-only (on-chain reads), lists all returned fields, and discloses payment requirement (402 response, server needs funded wallet). No destructive behavior mentioned; it's a safe operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is somewhat long but each sentence adds value: purpose, returned data, payment model. Front-loaded with main purpose. Could be slightly more concise, but no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description thoroughly explains what the tool returns (contract status, balances, activity, contract details, risk band). Also covers payment context and chain limitation. Complete for a safety check tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters (chain default 'base', address any 0x). Description adds context about address being EOA or contract and purpose, but does not add significant new semantic meaning beyond schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool provides a structural safety profile for any Base address (EOA or contract) before sending funds, approving, or calling. It specifically lists returned data (contract-vs-EOA, balances, tx-count, contract details, risk band) and distinguishes from siblings like token_safety by covering general addresses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: before sending funds, approving, or calling a contract. Mentions on-chain read-only nature and paid service (402 if unpaid). Does not explicitly exclude scenarios or compare to alternatives, but context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a chat completion request to an LLM via true402 (PAID x402 service, USDC on Base). Requires a funded wallet (WALLET_PRIVATE_KEY) on the MCP server.
| Name | Required | Description | Default |
|---|---|---|---|
| model | Yes | Model ID (e.g. gpt-4o, claude-3-5-sonnet) | |
| messages | Yes | Chat messages | |
| max_tokens | No | Maximum tokens to generate |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the burden. It discloses payment requirement and wallet setup, but does not mention rate limits, error handling, or consequences of insufficient funds. The description partially covers behavior but leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary action, and no wasted words. Every sentence adds necessary information about the service and prerequisite.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters (2 required), no output schema, and no annotations, the description is minimal. It covers the payment aspect but lacks details on model availability, response format, or error scenarios, making it incomplete for a transactional tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for each parameter (model, messages, max_tokens). The description adds no extra semantics beyond what the schema already provides, earning the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sends a chat completion request to an LLM via a specific paid service (true402). The verb 'send' and resource 'chat completion request' are explicit, and the service detail distinguishes it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the paid nature and wallet requirement, providing context on when to use it (if funded). However, it lacks explicit guidance on when not to use it or alternatives, leaving the AI to infer from sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolves the deployer of a Base token and profiles that wallet's reputation: age (tx-count), balance, contracts shipped, and whether it is a FRESH throwaway spun up for the launch (a common rug setup) — the discriminating caution. Reputation context a structural/honeypot check can't see; raw contract count is reported as context, NOT a rug verdict (legit protocols ship many). POST { token }. Unpaid returns 402. Requires an explorer key on the server; returns 503 if not configured (and is not charged). (PAID x402 service — USDC on Base; the MCP server needs a funded wallet to settle.)
| Name | Required | Description | Default |
|---|---|---|---|
| deep | No | Opt-in: also classify the deployer's recent prior tokens as live/dead (no liquidity = rug outcome). Slower; the real serial-rugger signal. | |
| chain | No | Chain to check; only 'base' is supported (default) | |
| token | Yes | Token contract address (0x…) on Base |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses payment model, server dependencies, error codes (402, 503), and cautions that raw contract count is not a rug verdict. Also explains the 'deep' flag behavior. This is comprehensive for a paid tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is somewhat dense but front-loaded with core purpose. Every sentence adds value, though some restructuring could improve readability. Still, it's concise enough for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers what the tool returns (reputation profile) and hints at additional results for 'deep'. It does not specify exact output format but provides enough context for expected behavior. Missing explicit return shape, but acceptable for a profiling tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for all 3 parameters. Description adds value by explaining the 'deep' flag's full effect, the supported chain, and the POST method for the token. No contradictions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool resolves and profiles the deployer of a Base token, including reputation metrics like age, balance, contracts shipped, and fresh wallet detection. It distinguishes from siblings like token_safety or address_safety by focusing solely on deployer reputation, not token-level safety.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the tool is a paid x402 service, requires a wallet on the server, and returns 402/503 for payment/config issues. It implies usage for deployer reputation checks but does not explicitly compare with siblings or state when to use vs not.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a URL and analyse its HTTP security headers (HSTS, CSP, X-Frame-Options, …) into present/missing + a 0–100 score. POST { url }; unpaid returns 402. (PAID x402 service — USDC on Base; the MCP server needs a funded wallet to settle.)
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL (http/https) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses payment requirement and behavior (402 if unpaid). No annotations, so description carries full burden. Does not mention any side effects or whether URL is fetched publicly, but overall transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. First sentence states core function; second adds critical payment context. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, parameter, and payment. Lacks example output or detailed list of headers, but for a single-parameter tool this is adequate. Could include a note about required authentication or rate limits, but not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already documents 'url' parameter well. Description adds value by indicating HTTP method (POST) and that the URL is the payload. With 100% schema coverage, baseline is 3, but extra context merits a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool fetches a URL and analyzes HTTP security headers, outputting present/missing and a score. Differentiates from siblings like seo_audit or robots_check which focus on other aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly notes paid service with 402 for unpaid, and prerequisite of funded wallet. No explicit when-not-to-use, but sibling tools are distinct enough to avoid confusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a URL and return its Open Graph card (title, description, image, site name, favicon, canonical). POST { url }; an unpaid request returns 402. Flat-priced per request. (PAID x402 service — USDC on Base; the MCP server needs a funded wallet to settle.)
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The page URL (http/https) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description fully bears behavioral disclosure. It notes payment requirements, the 402 error for unpaid requests, and the use of POST. It does not cover rate limits or other behaviors, but for a simple fetch this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences: purpose, request format and error condition, and pricing/wallet requirements. No extraneous information, well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description lists all return fields (title, description, image, etc.) and explains the 402 error. For a simple tool with one parameter, this provides sufficient context for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a single 'url' parameter described as 'The page URL (http/https)'. The description adds that the tool uses POST, but does not explain the parameter format beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches a URL and returns Open Graph card data, listing specific fields (title, description, image, etc.). This distinguishes it from siblings like web_extract, which likely extracts all content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when the tool is appropriate: it's a paid service requiring a funded wallet, and unpaid requests return 402. However, it does not explicitly advise when not to use it or mention alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 returns 402. (PAID x402 service — USDC on Base; the MCP server needs a funded wallet to settle.)
| Name | Required | Description | Default |
|---|---|---|---|
| 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: it monitors burn events, returns pool/token/amounts, is a paid service (402 for unpaid), and requires a funded wallet. This is transparent about cost and error condition.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with core purpose and parameter list, then output and payment info. It is concise and well-structured, though could separate output format more clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 4 parameters, the description covers purpose, parameters, output fields, cross-reference, and payment model. It lacks return format details but is sufficient for an agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 4 parameters with descriptions, so baseline is 3. The description adds extra context by explaining 'since' as block number, 'limit' as max 1–200 default 50, 'dex' as filter, and 'minQuote' as threshold, enhancing usability beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides liquidity-pull/rug alerts on Base by monitoring burn events on recently-launched DEX pools. It specifies the output includes pool, token, and WETH/USDC amounts, which distinguishes it from sibling tools like 'new_pairs' or 'token_safety', though it could explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for detecting rug pulls via burn events, but lacks explicit guidance on when to use versus alternatives or when not to use. It mentions cross-checking with token safety, but no exclusions or context for non-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every LLM model available through true402's pay-per-call inference, with live per-token pricing (3% over provider cost, min $0.0001/request). Returns each model's id, provider, and input/output token prices across OpenAI, Anthropic, Google, Groq, Mistral and Together — so an agent can pick a model and know the exact cost before paying via x402 (USDC on Base, no account or API key).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses return fields (id, provider, prices), pricing model (3% over cost, min fee), and payment method (x402). Missing details on pagination or limits, but acceptable for a listing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single paragraph, front-loaded with purpose. Concise but could be slightly shorter. No wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description details return values (id, provider, prices). Covers essential behavior. No obvious gaps given zero parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0 parameters and schema description coverage is 100%. Description does not need to add param info; baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists LLM models with live pricing, using specific verbs ('list', 'returns'). It distinguishes from sibling tools (e.g., chat, address_safety) which have unrelated purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage: when an agent needs to pick a model and know cost before paying. No explicit when-not or alternatives, but sibling tools are unrelated, so no confusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recently-created Base DEX pairs (Uniswap V3 + Aerodrome) from a background log-watcher — fresh token launches for trading agents/snipers. POST { since?, limit?, dex?, withToken? }; each pair gives the new token, quote (WETH/USDC), pool, fee|stable, block + approx age. Bundle with /v1/token-safety for a pre-trade rug/honeypot check. Unpaid returns 402. (PAID x402 service — USDC on Base; the MCP server needs a funded wallet to settle.)
| Name | Required | Description | Default |
|---|---|---|---|
| dex | No | Filter: 'uniswap-v3' | 'aerodrome' | |
| limit | No | Max pairs (1–200, default 50) | |
| since | No | Only pairs first seen at or after this block | |
| withToken | No | Only token launches (default true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool is a paid service (returns 402 if unpaid) and requires a funded wallet on Base. It also mentions the return includes block and approx age. Missing details like rate limits or error handling, but this is adequate disclosure for a paid tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is front-loaded with the core purpose in the first sentence. It compresses parameters, return fields, use-case advice, and payment info into a few sentences. While efficient, it is slightly dense and could be structured more clearly. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of output schema and annotations, the description explains the data source, DEXes, token details, use case, bundling suggestion, and payment requirement. It covers most essential context for an agent to decide to use the tool, though it lacks explicit error scenarios or exact JSON structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all parameters have descriptions in the schema. The description simply lists the parameters without adding extra meaning beyond what the schema provides, thus minimal added value. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it returns recently-created Base DEX pairs from a background log-watcher for trading agents/snipers. This verb+resource combination distinguishes it from sibling tools like token_safety or whale_swaps, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explicitly suggests bundling with /v1/token-safety for rug/honeypot checks, indicating a common use case. It implies usage for fresh token launches, but does not explicitly state when not to use this tool or name alternative tools beyond the bundle suggestion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a site's robots.txt + llms.txt and report whether the major AI crawlers are allowed/blocked, plus sitemaps. POST { url }; unpaid returns 402. (PAID x402 service — USDC on Base; the MCP server needs a funded wallet to settle.)
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Any URL on the site |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
In absence of annotations, the description discloses the POST method, 402 error for unpaid requests, and payment mechanism (USDC on Base). It doesn't cover rate limits or other edge cases, but addresses critical behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundancy. First sentence defines core purpose concisely; second sentence adds essential payment context. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 1 parameter and no output schema, the description covers purpose, behavior, and payment requirement fully. No gaps for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of the single 'url' parameter. Description adds no additional meaning beyond the schema description 'Any URL on the site', thus baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches robots.txt and llms.txt, reports AI crawler status, and includes sitemaps, using a specific verb 'Fetch' and distinct resource. It differentiates from siblings like 'headers_check' or 'seo_audit'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking AI crawler permissions and sitemaps, and notes payment requirements. It lacks explicit when-not-to-use or alternative tools, but the uniqueness of the tool makes usage context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Audit a web page for SEO + GEO (generative-engine optimization). POST { url, mode? }; an unpaid request returns 402 with payment requirements. After payment, returns a structured JSON report (per-category scores + issues). Flat-priced per request. (PAID x402 service — USDC on Base; the MCP server needs a funded wallet to settle.)
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The page URL to audit (http/https) | |
| mode | No | Which analysis to run (default both) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the paywall behavior (402 response, flat pricing, USDC on Base, MCP wallet needed) and return format (structured JSON with scores). It does not mention side effects or rate limits, but covers the major behavioral aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose and is concise (4-5 sentences). Every sentence adds value, including payment and output details. No wasted words, though it could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
In the absence of an output schema, the description explains the return format (JSON with per-category scores and issues). It also covers the payment flow and prerequisites, but does not enumerate all possible error states beyond 402.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for parameters, and the description adds value by specifying the HTTP method (POST), the optional nature of 'mode' (default both), payment details, and output structure. This goes beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool audits a web page for SEO and GEO, with specific verb 'Audit' and resource 'web page'. It distinguishes from sibling tools like 'headers_check' and 'robots_check' by being broader and including payment details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the payment requirement (402 for unpaid) and the workflow, but does not explicitly state when to use this tool versus alternatives like 'web_extract' or 'headers_check'. However, the payment and return format provide clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The flagship composite for a Base ERC-20 — one call instead of five. Runs the full token-safety check (ERC-20 conformance, ownership, mint-capability, WETH/USDC liquidity depth, buy/sell honeypot simulation), enriches it with the live recent liquidity-removal (rug) + whale-swap activity on the token, and returns a single avoid|caution|ok verdict with reasons plus the underlying reports. POST { token }. Cheaper than buying token-safety + liquidity-pulls + whale-swaps separately. Unpaid returns 402. (PAID x402 service — USDC on Base; the MCP server needs a funded wallet to settle.)
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | Chain to check; only 'base' is supported (default) | |
| token | Yes | ERC-20 contract address (0x…) on Base |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the composite nature, the verdict format, the paid service requirement (USDC on Base with funded wallet), and the 402 error for unpaid calls.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is detailed but front-loaded with the core purpose. Some redundancy (e.g., repeating 'PAID x402 service'), but overall efficient for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and tool complexity, the description adequately covers return values (verdict, reasons, underlying reports) and operational context (payment, chain support). Complete for an agent to understand and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds that 'token' is an ERC-20 address on Base and 'chain' defaults to 'base', but these are already in the schema descriptions. No additional semantic enrichment beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: a composite that runs token-safety checks, liquidity removal, and whale activity on a Base ERC-20, returning a single verdict. It distinguishes from sibling tools (token_safety, liquidity_pulls, whale_swaps) by being a one-call alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'one call instead of five' and 'cheaper than buying... separately', indicating when to use this composite over individual tools. Also notes unpaid requests return 402, implying payment is required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rug/honeypot safety check for an ERC-20 token on Base (from on-chain reads — no API key): ERC-20 conformance, ownership renounce, mint-capability, WETH/USDC liquidity depth across Uniswap V3 + Aerodrome, and a buy/sell honeypot simulation (a gas-free eth_call that round-trips a tiny WETH→token→WETH trade to detect tokens you can buy but not sell). Returns a 0–100 score + risk flags. POST { token }; unpaid returns 402. (PAID x402 service — USDC on Base; the MCP server needs a funded wallet to settle.)
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | 'base' (default) | |
| token | Yes | ERC-20 contract address on Base |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses paid nature (x402), explains honeypot simulation as a gas-free eth_call, and mentions return format (0-100 score + risk flags) and 402 for unpaid requests.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is informative yet reasonably concise for the complexity, with clear structure: purpose, checks, return, payment. Slightly long but every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity (multi-check, paid service) and no output schema, description covers purpose, checks, return format, payment requirement, chain, and technical details (eth_call). No obvious gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (baseline 3). Description adds value by specifying that 'token' is an ERC-20 address on Base, that 'chain' defaults to 'base', and provides context about on-chain reads.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it performs a rug/honeypot safety check for ERC-20 tokens on Base, listing specific checks (conformance, ownership, mint, liquidity, honeypot simulation). It distinguishes from sibling tools that cover other domains (chat, SEO, etc.).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use (safety check for ERC-20 on Base) and mentions paid service. Lacks explicit when-not-to-use or comparison to siblings, but context is clear and sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a web page and return clean readable text + light markdown + title/description/links. POST { url }; an unpaid request returns 402. Flat-priced per request. (PAID x402 service — USDC on Base; the MCP server needs a funded wallet to settle.)
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The page URL to extract (http/https) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses key behaviors: returns formatted content, has a flat pricing model, and a 402 error for unpaid requests. However, it lacks details on error handling for invalid URLs, timeouts, or content size limits, which would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: two sentences that cover functionality and payment model, plus a parenthetical note. Each sentence contributes value, and the key information is front-loaded. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter, no output schema, and no annotations, the description adequately covers the tool's core functionality and payment model. It could be improved by mentioning error cases beyond 402 and content limitations, but overall it is fairly complete for a simple extraction tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'url' is already described in the input schema as 'The page URL to extract (http/https)'. The tool description does not add additional semantics beyond this, and with 100% schema coverage, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (fetch), resource (web page), and output (clean readable text, light markdown, title/description/links). It distinguishes from sibling tools like link_preview and robots_check by specifying the complete extraction of text and metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies the HTTP method (POST), the required parameter (url), and importantly, the payment requirement and the 402 error for unpaid requests. It does not explicitly state when not to use the tool, but the payment context implies usage only with a funded wallet.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 returns 402. (PAID x402 service — USDC on Base; the MCP server needs a funded wallet to settle.)
| Name | Required | Description | Default |
|---|---|---|---|
| dex | No | Filter: 'uniswap-v3' | 'aerodrome' | |
| min | No | Only swaps of at least this USD size (default 10000) | |
| limit | No | Max swaps (1–200, default 50) | |
| since | No | Only swaps at or after this block | |
| direction | No | Filter: 'buy' | 'sell' (of the non-quote token) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It discloses payment model (402 if unpaid), result fields, and usdValue calculation. Could add rate limits or auth details, but current info is solid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One well-structured paragraph: purpose first, then parameter list, then result fields, then payment note. Every sentence adds value, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers result content (pool, token, quote, USD size, direction, block, age, txHash) and usdValue computation. Lacks default ordering or sorting details, but complete enough for a fetch tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. Description adds defaults (min=10000, limit=50) and clarifies direction refers to 'non-quote token', providing value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns 'recent large DEX Swap events' for whale-following/copy-trading, specifying DEXs (Uniswap V3 + Aerodrome) and chain (Base). It uniquely identifies the tool's function among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides usage context (whale-following signal), parameter hints (POST with filter options), and payment requirement ('PAID x402 service'). No explicit when-not or alternatives, but sufficient implied usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0address_safetydeployer_checkliquidity_pulls1 field changedInput schema / properties / dex / enumAdded value: +[
+ "uniswap-v3",
+ "aerodrome"
+]new_pairs1 field changedInput schema / properties / dex / enumAdded value: +[
+ "uniswap-v3",
+ "aerodrome"
+]whale_swaps2 fields changedInput schema / properties / dex / enumAdded value: +[
+ "uniswap-v3",
+ "aerodrome"
+]Input schema / properties / direction / enumAdded value: +[
+ "buy",
+ "sell"
+]v0.7.1chatheaders_checklink_previewliquidity_pullslist_modelsnew_pairsrobots_checkseo_audittoken_reporttoken_safetyweb_extractwhale_swapsEach tool targets a distinct operation: address safety, deployer reputation, web checks, token analysis, on-chain monitoring, and LLM inference. There is no functional overlap between any two tools.
Most tools use a descriptive verb_noun pattern (e.g., address_safety, token_report). The exception is 'chat', which breaks the pattern but is still clear and functional.
14 tools is well-scoped for a server covering blockchain safety, web diagnostics, and LLM services. Each tool addresses a specific need without unnecessary redundancy.
The set covers the full lifecycle of its domain: individual checks (address, token, deployer), aggregated reports (token_report), on-chain monitoring (new_pairs, liquidity_pulls, whale_swaps), web analysis (link_preview, seo_audit, headers_check, robots_check), and LLM capabilities (chat, list_models). No obvious gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Monetize any MCP server: x402 paywall, pay-per-call billing in USDC on Base, agent marketplace.
15 paid AI agent primitives via x402 (USDC on Base). Pay-per-call MCP server.
Agent-commerce MCP server for x402/USDC payments and affiliate splits on Base.
MCP server for AI agents to discover campaigns by humans and donate USDC directly on Base.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/true402/mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
