The x402-bazaar-mcp server gives AI agents pay-per-use access to on-chain data, DeFi tools, and AI utilities on the Base blockchain — no API keys or subscriptions, just USDC micro-payments.
Token & Contract Security
token_risk — Full safety score: honeypot detection, buy/sell taxes, ownership, holder concentration, LP lock %
contract_abi — Check Sourcify verification status and retrieve a contract's ABI
decode_selector — Resolve 4-byte function selectors to human-readable signatures
sanctions — Compliance screening for addresses
Prices & Market Data
token_price — Real-time USD price, 24h change, liquidity, and volume via DexScreener
multi_price — Prices for multiple tokens at once
trending_tokens — Up to 15 currently trending Base tokens
new_tokens — Recently launched tokens on Base
market_snapshot — Major crypto asset prices with intraday moves
price_alert — Webhook alert when a token crosses a price threshold (active 30 days)
Wallet & Address Intelligence
address_intel — EOA vs. contract, ETH/USDC balance, transaction count, and activity level
wallet_tokens — Portfolio of major Base tokens (ETH, WETH, USDC, DAI, cbETH, etc.) with live USD values
holders — Holder data for a token
basename — Resolve Base Name Service names
Transaction & Gas Tools
gas_oracle — Live Base gas fee estimates (slow/normal/fast tiers in Gwei)
tx_decode — Decode a transaction hash into a structured summary (from/to, value, status, gas, method, nonce)
Claude-Powered AI Utilities
ai_summarize — Summarize text into 3–5 bullet points
ai_extract — Extract named fields from unstructured text as JSON
ai_translate — Translate text into any target language
Miscellaneous
weather — Structured weather report for any city
quote — Rotating quote feed (cheapest endpoint; good for testing payment flow)
secure_token — Generate cryptographically secure, URL-safe random tokens server-side
Hosted, no install: point any MCP client at https://402.com.tr/mcp —
Streamable HTTP, one tool per catalogued service, no wallet held server-side. Or
run it locally with npx as described below; both talk to the same catalog. The
current tool list is always
the server card; a number
written here would be wrong the next time a service is added.
The Base token-safety toolkit for AI agents. An MCP (Model Context Protocol) server that gives your agent the checks it needs before it touches a Base token — including the only B20 (Base-native token standard) freeze/seize/rug suite anywhere — which also covers all 13 of Coinbase's tokenized equities, telling a real issuance apart from a token merely wearing an equity ticker by reading who administers the transfer policy on chain rather than by consulting a list of addresses, so a newly issued one is recognised the day it appears — pre-trade GO/HOLD/STOP gates, honeypot & sellability checks, wallet + approval audits, sign-guard, prices and AI reports. Every paid API in the x402 Bazaar catalog, exposed as a callable tool (Claude Desktop, Cursor, Cline, Windsurf, VS Code, Coinbase AgentKit, custom agents).
Bind these first: pre_trade_gate (any token), b20_gate (Base-native B20
tokens), sign_guard (before signing a tx).
No wallet needed to start. Run it with no key, no token and no config at all and it uses the free tier — one free call/day per service. When you outgrow that, a prepaid credit token keeps it walletless: one purchase, then every call is just an HTTP header. A wallet is only needed for the third mode, per-call payment.
Each tool call is otherwise backed by an x402 micro-payment in USDC on Base — no API keys, no subscriptions, no sign-up. The agent pays only for what it uses, typically fractions of a cent per call.
Works with zero config. Run it with no wallet and no token and it uses the free tier (one free call/day per service, then a preview) — so an agent can try every tool instantly. Unlock unlimited paid calls with either a prepaid credit token (one x402 purchase up front, then no wallet or signing per call) or a wallet key.
On startup the server fetches the live catalog from
https://402.com.tr/api/catalog and auto-registers one MCP tool per
service.
When an AI agent calls a tool the server picks a payment mode (below), hits the endpoint, and returns the response.
In wallet mode the x402 flow is transparent:
HTTP 402 → pay USDC on Base → retry → return response, gasless for the payer
(the facilitator pays gas).
Mode | Set | What happens | Wallet? Signing? |
Credits ⭐ |
| Sent as | No / No |
Wallet |
| Signs an x402 USDC payment locally per call | Yes / Yes |
Free | (nothing) | Free tier: 1 full call/day/service, then a preview | No / No |
Credits are the easiest paid mode day-to-day: buying the pack takes ONE x402
settlement (call the buy_credits tool in wallet mode, or pay
https://402.com.tr/api/x402/buy-credits?tier=0.25|1|5|20 from any x402 client),
which returns a ck_… token. Set it as X402_CREDIT_TOKEN and every later call
just draws down the balance — no private key ever touches this config again.
Tiers: $0.25 starter, $1, $5 (+10%), $20 (+20%).
Related MCP server: x402-mcp
Node.js ≥ 20
(optional, for paid calls) a prepaid credit token or a Base wallet private key whose address holds USDC on Base mainnet
npm install
# Zero-config — free tier, try every tool instantly:
npx x402-bazaar-mcp
# Paid via prepaid credits (recommended — no wallet, no signing):
X402_CREDIT_TOKEN=ck_your_token npx x402-bazaar-mcp
# Paid via wallet:
AGENT_PRIVATE_KEY=0xYOUR_PRIVATE_KEY npx x402-bazaar-mcpVariable | Required | Default | Description |
| no | — | Prepaid credit token ( |
| no | — | Hex private key for a Base wallet holding USDC. |
| no |
| Override the catalog URL (useful for local dev). |
With none of the above set, the server runs on the free tier.
Add the following to your claude_desktop_config.json
(usually ~/Library/Application Support/Claude/claude_desktop_config.json on
macOS or %APPDATA%\Claude\claude_desktop_config.json on Windows):
{
"mcpServers": {
"x402-bazaar": {
"command": "npx",
"args": ["-y", "x402-bazaar-mcp"],
"env": {
"X402_CREDIT_TOKEN": "ck_your_token"
}
}
}
}Omit the env block entirely to run on the free tier (great for a first
try), or use "AGENT_PRIVATE_KEY": "0x…" instead of the credit token to pay
from a wallet.
After saving, restart Claude Desktop. You should see the Bazaar tools appear in the tool list (hammer icon).
Add to ~/.cursor/mcp.json (global) or .cursor/mcp.json in your project:
{
"mcpServers": {
"x402-bazaar": {
"command": "npx",
"args": ["-y", "x402-bazaar-mcp"],
"env": { "X402_CREDIT_TOKEN": "ck_your_token" }
}
}
}In the Cline panel → MCP Servers → Configure (cline_mcp_settings.json):
{
"mcpServers": {
"x402-bazaar": {
"command": "npx",
"args": ["-y", "x402-bazaar-mcp"],
"env": { "X402_CREDIT_TOKEN": "ck_your_token" },
"disabled": false,
"autoApprove": []
}
}
}Add to ~/.codeium/windsurf/mcp_config.json:
{
"mcpServers": {
"x402-bazaar": {
"command": "npx",
"args": ["-y", "x402-bazaar-mcp"],
"env": { "X402_CREDIT_TOKEN": "ck_your_token" }
}
}
}Add to .vscode/mcp.json in your workspace (or run MCP: Add Server):
{
"servers": {
"x402-bazaar": {
"command": "npx",
"args": ["-y", "x402-bazaar-mcp"],
"env": { "X402_CREDIT_TOKEN": "ck_your_token" }
}
}
}Every client above works the same way: omit env to run on the free tier,
or swap the credit token for "AGENT_PRIVATE_KEY": "0x…" to pay from a wallet.
Because this is a standard MCP stdio server, any MCP-capable agent runtime can load and pay for the Bazaar's tools — including Coinbase's own agent stack, with no bespoke integration:
npx awal)Coinbase Agentic Wallets ship
native x402 support and an MCP interface. Point the wallet's MCP config at
npx x402-bazaar-mcp, and the agent can call — and pay for — any Bazaar service
straight from its MPC-secured wallet, gasless on Base. The x402 payment handshake
is handled for you: HTTP 402 → pay USDC on Base → retry → response.
Two ways in:
As MCP tools — load this server into your AgentKit agent's MCP config
(command: "npx", args: ["-y", "x402-bazaar-mcp"], and X402_CREDIT_TOKEN
or AGENT_PRIVATE_KEY in env). The agent gains every Bazaar tool —
B20 freeze/seize checks, pre-trade gates, honeypot/sellability, deployer
reputation, exit liquidity, live DEX prices, gas, tx decode, Claude reports —
as pay-per-call actions, no action provider to write.
Via AgentKit's native x402 support — AgentKit's wallet can settle x402
payments directly, so an agent can GET https://402.com.tr/api/x402/<service>
and pay the returned 402 from its own wallet. The 402 body includes a
machine-readable alternatives block (starter credits first) so the agent can
pick the cheapest on-ramp programmatically.
Either way the agent pays only for the calls it makes, in USDC on Base, gasless.
Add it as an MCP server in one command:
# Free tier (zero config):
claude mcp add x402-bazaar -- npx -y x402-bazaar-mcp
# Or paid via prepaid credits:
claude mcp add x402-bazaar -e X402_CREDIT_TOKEN=ck_your_token -- npx -y x402-bazaar-mcpThen ask Claude Code to check a token, price a portfolio, or screen an address — it calls the right Bazaar tool and settles the micro-payment automatically.
Agents need fresh on-chain data and AI utilities but don't want to manage RPC endpoints, scrapers, security heuristics, or per-provider API keys. One MCP server plus a credit token (or a funded wallet) gives them everything — contract safety checks, live DEX prices, gas estimates, transaction decoding, and Claude-powered reports — all pay-per-use, with no subscriptions or sign-up required.
Tools are loaded live from the catalog, so the list stays current. At the time of writing it includes:
Tool | Price | What it does |
| $0.10 | The one call before a trade — risk + sellability + route + deployer → GO/HOLD/STOP |
| $0.03 | Token safety score (honeypot, taxes, ownership, holders) for any Base token |
| $0.08 | Can you actually SELL it? Honeypot/tax/lp simulation verdict |
| $0.12 | Claude-written full due-diligence report on a token |
| $0.02 | Screen an address against the OFAC sanctions list |
| $0.02 | Top holders, concentration (whale risk) & LP lock for a token |
| $0.02 | DEX price + liquidity for a Base token |
| $0.02 | Prices for up to 10 Base tokens in one call |
| $0.02 | EOA/contract, ETH+USDC balance, activity for any address |
| $0.02 | Portfolio of major Base tokens + USD value |
| $0.01 | Live Base gas estimates (slow/normal/fast) |
| $0.02 | Structural decode of a Base transaction |
| $0.02 | Is a contract verified? Get its ABI (Sourcify) |
| $0.01 | Resolve Basenames ↔ addresses on Base |
| $0.01 | Trending & freshly listed Base tokens |
| $0.05 | Register an alert when a token crosses a price (webhook or poll) |
| $0.25–$20 | Buy a prepaid credit pack (tier param) — unlocks walletless calls |
Prices shown as of this release — the authoritative price is always in the live
catalog and in each 402 challenge. The table above is a sample: the tool list is
loaded live from the catalog at startup, so the server always exposes
everything the marketplace currently sells — including the
B20 safety suite, the web and business checks (url_extract, email_verify,
domain_check) and anything added since this README was written.
Once installed, just ask your agent naturally — it picks the right tool and pays per call:
"Is
0x…a safe token to buy on Base? Check the risk and current price."
The agent calls token_risk and token_price, each settling a tiny USDC payment
from your wallet, and answers with the on-chain data.
"Is this NVDA token on Base the real Coinbase one?"
b20_safety answers from the chain rather than from a list: it reads who
administers the token's transfer policy and reports whether that is the operator
behind Coinbase's confirmed issuances. A lookalike can copy the ticker, the name
and even a 0xb200… vanity address; it cannot borrow the policy administrator.
The same answer carries the issuer's powers — holder-eligibility gating, gated
mint, and the rebase multiplier that redenominates every balance at once — as
facts about a regulated instrument, not as a risk score to be alarmed by.
token_risk — low-risk token{
"address": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
"isContract": true,
"token": {
"name": "USD Coin",
"symbol": "USDC",
"decimals": 6,
"totalSupply": "4800000000000000"
},
"ownership": {
"owner": "0x0000000000000000000000000000000000000000",
"renounced": true
},
"upgradeableProxy": false,
"security": {
"isHoneypot": false,
"buyTaxPct": 0,
"sellTaxPct": 0,
"isOpenSource": true,
"isMintable": false,
"transferPausable": false,
"canTakeBackOwnership": false,
"hiddenOwner": false,
"holderCount": 182430,
"topHolderPct": 12.47,
"top10HolderPct": 41.22,
"lockedLpPct": 100,
"creatorPct": 0,
"isInDex": true,
"isAntiWhale": false,
"antiWhaleModifiable": false,
"tradingCooldown": false,
"slippageModifiable": false,
"isTrueToken": true,
"isAirdropScam": false,
"creatorAddress": "0x6B175474E89094C44Da98b954EedeAC495271d0F",
"creatorBalance": "0"
},
"riskScore": 0,
"riskLevel": "low",
"flags": [],
"sources": ["base-rpc", "goplus"],
"coverage": "RPC base + GoPlus security (honeypot, taxes, holders, holder concentration, LP lock, creator holdings, source, ownership controls).",
"checkedAt": "2026-06-23T09:14:02.381Z"
}token_price — DEX price and liquidity{
"address": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
"priceUsd": "0.9998",
"priceChange24h": -0.03,
"liquidityUsd": 4721850.44,
"volume24h": 18340210.77,
"dexId": "uniswap",
"pairAddress": "0x88A43bbDF9D098eEC7bCEda4e2494615dfD9bB9C",
"baseToken": {
"name": "USD Coin",
"symbol": "USDC"
},
"checkedAt": "2026-06-23T09:14:03.105Z"
}Human-readable catalog & docs: https://402.com.tr/agents
Machine-readable catalog (used by this server): https://402.com.tr/api/catalog
x402 well-known: https://402.com.tr/.well-known/x402
Prepaid credits (recommended) keep wallets out of your agent config — buying
the pack takes one x402 settlement, but after that the ck_… token is all the
agent holds: a bearer capability worth only its remaining balance, so a leaked
token can lose at most what's left on it, never a wallet. Buy a small pack and
rotate it if needed.
If you use wallet mode instead, your private key is only used locally inside this process to sign payment authorizations. It is never sent to the Bazaar server or any third party. Use a dedicated spending wallet (not your main wallet) and keep only a small USDC balance on it.
MIT
EOA vs contract, ETH + USDC balance, transaction count and activity level — straight from Base RPC. Useful for counterparty and wallet checks.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description discloses that the data comes 'straight from Base RPC', implying a live read operation with no destructive effects. However, it does not address rate limits or data freshness.
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 two sentences, front-loading the key outputs and source, with no extraneous words. Every sentence contributes 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?
Despite lacking an output schema, the description enumerates all return fields (EOA/contract, balances, transaction count, activity level) and notes the data source (Base RPC), making the tool's behavior fully understandable.
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 schema has 100% coverage with one 'address' parameter described as 'Address', but the tool description adds important context: the address is on Base chain and what data will be returned, enhancing interpretability beyond the schema alone.
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 returns EOA vs contract classification, ETH and USDC balances, transaction count, and activity level for an address on Base, distinguishing it from sibling tools like wallet_tokens which focus on token holdings.
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 notes the tool is useful for counterparty and wallet checks, providing clear context for use, but doesn't explicitly contrast with alternatives or specify when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pull named fields out of any text as clean JSON (e.g. name, email, company, date). Powered by Claude structured outputs.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Source text | |
| fields | No | Fields (comma-separated) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It notes that output is 'clean JSON' and powered by Claude structured outputs, but does not disclose limitations, error handling, or response size constraints. This is adequate but minimal.
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 wasted words. The first sentence states purpose with concrete examples, the second adds technical context. This is optimally concise for the information provided.
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 two-parameter tool with no output schema or annotations, the description covers purpose, output format, and example fields. However, it could clarify behavior for missing fields or large text inputs. Nearly complete given the tool's simplicity.
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 basic descriptions for 'text' and 'fields'. The description adds example fields (name, email, etc.) and clarifies the JSON output format, but doesn't explain the comma-separated syntax or constraints. 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 uses a specific verb 'Pull' and clearly states the resource 'named fields out of any text' with examples (name, email, company, date). It distinguishes itself from siblings like ai_summarize and ai_translate by focusing on structured extraction.
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?
No explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or comparisons to sibling tools like ai_summarize or ai_translate, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Paste text and get a 3-5 bullet summary from Claude. Pay-per-call — no API key or subscription needed on your side.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to summarize |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It only discloses the pay-per-call model and that it uses Claude. It does not disclose rate limits, auth requirements, input size limits, or any side effects (e.g., no destructive behavior).
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: first states purpose and output format, second explains payment model. Efficient, front-loaded, and 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?
For a simple tool with one parameter and no output schema, the description covers purpose, output format, and pricing. It could mention input size constraints or error handling, but overall it is fairly complete.
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 single parameter 'text' is described in the schema as 'Text to summarize'. The description adds no additional meaning (e.g., length limits, formatting). With 100% schema coverage, baseline is 3.
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 verb (summarize), resource (text), and output format (3-5 bullet points). It distinguishes itself from sibling tools like 'ai_translate' or 'ai_extract' by explicitly targeting summarization.
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 pay-per-call and no API key needed, which implies when to use (quick summaries without setup), but it does not provide when-not-to-use guidelines or explicitly compare with other tools for alternative actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Translate text into a target language with Claude. One micro-payment per translation.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to translate | |
| to | No | Target language |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions a micro-payment per translation, which is a cost implication not in the schema. However, it omits other traits like statelessness, rate limits, or error handling.
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 zero waste. The purpose is front-loaded, and the cost info is a separate terse statement. Efficient and clear.
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 no output schema, the description covers purpose and cost but does not hint at the return format or error conditions. It is adequate but not fully comprehensive.
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 both parameters described in the schema. The description adds no additional meaning beyond what the schema already provides, so 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 tool translates text into a target language using Claude, a specific verb and resource. It distinguishes from sibling tools like ai_extract and ai_summarize, which perform different tasks.
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?
No guidance on when to use this tool versus alternatives. It lacks context for prerequisites, language support, or exclusions. The cost hint is present but not actionable usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Checks Sourcify for a Base contract's verification status and returns its ABI as function/event name lists + item count (full or partial match). No API key required.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Contract address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It states partial matches are possible and no API key is needed, but omits failure modes or rate limits.
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 a single efficient sentence with no wasted words, covering purpose and key details.
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 one parameter and no output schema, the description adequately explains input and output format, though error states could be mentioned.
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 schema covers the single 'address' parameter completely. The description adds value by specifying it's a Base contract address, which is absent from the schema description.
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 checks Sourcify for a Base contract's verification status and returns its ABI as function/event name lists plus item count, distinguishing it from sibling tools that handle other blockchain data.
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 retrieving a contract's ABI without an API key, but does not explicitly mention when to prefer it over alternatives like decode_selector or tx_decode.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolves a 4-byte function selector (e.g. 0x70a08231) to candidate human-readable signatures via 4byte.directory. Accepts a bare selector or full calldata.
| Name | Required | Description | Default |
|---|---|---|---|
| selector | Yes | Function selector |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full responsibility. It mentions resolving via 4byte.directory, implying an external API call, but does not disclose rate limits, authentication needs, or side effects. The acceptance of full calldata is a behavioral nuance, but overall transparency is low.
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 concise, consisting of one clear sentence and a clarifying phrase. It is front-loaded with the primary action. No unnecessary words, though structuring could be improved slightly.
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 a single parameter, no output schema, and no annotations, the description provides a minimum viable explanation of what it does and what it accepts. However, it lacks details on return format, candidate count, or potential errors, leaving some gaps for an agent.
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 schema covers 100% of parameters, with the parameter 'selector' described only as 'Function selector'. The description adds meaningful context by stating it accepts a bare selector or full calldata, which clarifies input flexibility beyond the 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 resolves a 4-byte function selector to candidate human-readable signatures via 4byte.directory. It uses a specific verb 'resolves' and identifies the resource. However, it does not explicitly differentiate from sibling tools like contract_abi or tx_decode, which may have overlapping functionality.
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 does not provide guidance on when to use this tool versus alternatives. It mentions it accepts a bare selector or full calldata, but does not specify prerequisites, limitations, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns current Base gas fees (baseFee, maxPriorityFee) and three tiered suggestions (slow, normal, fast) in Gwei, derived live from the Base RPC. Built for agents that time or cost-estimate transactions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description discloses live source (Base RPC) and unit (Gwei), and implies read-only behavior. However, no annotations provided and description does not cover potential limitations, rate limits, or error behavior.
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 concise sentences, front-loaded with return values. Every word adds value; no redundancy.
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?
Description fully explains return format (baseFee, maxPriorityFee, three suggestions in Gwei) and source (live Base RPC). Adequate for a simple oracle 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?
Input schema is empty (0 parameters), so schema description coverage is 100%. Description adds no parameter info, but none needed. Baseline score 4 for 0-parameter tool.
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 explicitly states the tool returns Base gas fees (baseFee, maxPriorityFee) with three tiered suggestions in Gwei, derived live from Base RPC. It is distinct from sibling tools which cover unrelated domains like address intel, weather, 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?
Implied usage context ('Built for agents that time or cost-estimate transactions') but no explicit when-to-use or when-not-to-use guidance. No alternative tools mentioned, though siblings are unrelated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a snapshot of major crypto assets with a pseudo-random intraday move. One USDC micro-payment per call.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the move is pseudo-random and there is a micro-payment per call, which are important behavioral traits not covered by annotations. Lacks details on payment failure or prerequisites.
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 wasted words, and essential information is 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?
For a zero-parameter tool with no output schema, the description covers core behavior and cost but lacks detail on what exact assets are included and the output format.
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?
No parameters exist, so schema coverage is 100%. The description adds no parameter info, which is acceptable since there are none.
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 a snapshot of major crypto assets, which is a specific resource. However, it does not explicitly distinguish from sibling tools like quote or token_price, which also deal with crypto prices.
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?
No guidance on when to use this tool versus alternatives. The description only states what it does, without indicating when it is appropriate or not.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pay once to register a price-threshold alert on any Base token. Supply target price, direction (above/below), and an https webhook URL. A polling cron checks DexScreener and POSTs your webhook the moment it crosses. Expires after 30 days.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | Token address | |
| threshold | Yes | Price threshold (USD) | |
| direction | Yes | Direction (above/below) | |
| webhook | Yes | Webhook URL (https) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description effectively discloses key behaviors: polling mechanism, webhook POST, 30-day expiration, and cost implication. It provides a clear mental model, though lacks details on error handling or rate limits.
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 extremely concise: four sentences covering purpose, inputs, mechanism, and expiry without any redundant information. 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?
Given the tool's simplicity and lack of output schema, the description covers the essential aspects: registration, data source, webhook, and expiration. It could mention acknowledgment or error responses, but is largely complete.
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 description adds value beyond the input schema by specifying that direction accepts 'above/below' and that webhook must be https. Since schema coverage is 100%, baseline is 3, but the description enhances understanding of parameter constraints.
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 registers a price-threshold alert on Base tokens, using specific verbs and resources. It distinguishes itself from sibling tools like 'token_price' or 'market_snapshot' by focusing on alerting rather than querying.
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 when to use the tool (for ongoing price monitoring via webhook) but does not explicitly compare with alternatives or state when not to use it. No direct guidance on preferring this over other price-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A rotating quote feed. The cheapest possible paid endpoint — perfect for testing your wiring.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It mentions the quote feed is rotating and paid, but fails to disclose behavioral details such as rate limits, authentication needs, or whether data is read-only or modified.
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 two sentences with no wasted words, front-loading the core purpose and a key usage hint. 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 no parameters and no output schema, the description is adequately complete. It states the tool's function and suggests a use case. It could elaborate on the return format, but overall it serves its purpose.
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?
There are zero parameters, so schema coverage is 100%. The description adds no parameter information, but none is needed. Baseline 4 applies as per rules for 0 parameters.
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 identifies the tool as a rotating quote feed, distinguishing it from sibling tools like weather or token_price. It also emphasizes its low cost, making its purpose very specific.
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 suggests use for testing wiring, providing context for when to use it. However, it does not give explicit exclusions or alternative tools, leaving the guidance implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate N url-safe random tokens server-side. Demonstrates a paid utility endpoint with a query parameter.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | How many |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must bear full burden. It only states it is 'server-side' and 'url-safe', but fails to disclose cost implications, rate limits, maximum count, or whether the endpoint is safe to call without side effects.
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 sentence is concise, but includes unnecessary meta remark 'Demonstrates a paid utility endpoint' that does not aid tool selection. Could be more 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?
No output schema and missing return format. Description does not explain what 'url-safe random tokens' are or their structure. Agent cannot determine how to process the result. Complexity is low but completeness is lacking.
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 description 'How many' for count. Description repeats 'N' but adds no extra meaning. Since coverage is high, 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 states 'Generate N url-safe random tokens server-side', which clearly indicates the action and resource. It distinguishes from sibling tools like token_price or token_risk which deal with crypto tokens. However, it lacks specification of token length or default count.
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?
No guidance on when to use this tool versus alternatives. The description mentions 'Demonstrates a paid utility endpoint', which is meta and not useful for selection. No context on prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pass a Base token contract address and get the current USD price, 24h change, liquidity, and volume from DexScreener (highest-liquidity pair auto-selected). No API key required.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Token contract address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that no API key is required and that the highest-liquidity pair is auto-selected. This goes beyond the minimal schema. It does not mention error handling or rate limits, but for a simple read tool, the behavioral information is adequate.
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 concise, consisting of two sentences with no redundant information. It is front-loaded with the core action and provides necessary details efficiently.
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?
The description covers the main purpose, input, output data, and authentication. However, it does not describe the return format or potential errors (e.g., if no pair found). Given the lack of an output schema, additional context would improve completeness.
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 schema already describes the parameter 'address' as 'Token contract address'. The tool description adds 'Base token' which is slightly more specific but does not significantly enhance understanding. 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 tool's function: get current USD price, 24h change, liquidity, and volume for a Base token on DexScreener. It specifies the required input (contract address) and the source. However, it does not explicitly differentiate from sibling tools like 'quote' or 'market_snapshot', which may offer similar price data.
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?
No guidance is provided on when to use this tool versus alternatives. The description implies it is for Base tokens but does not mention when not to use it, nor does it reference any sibling tools. There is no context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pass a token contract address and get a risk score + flags (ERC-20 conformance, ownership renounce, upgradeable proxy) computed live from Base. Built for trading bots and agents that vet tokens before buying.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Token contract address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the risk score and flags are computed live from Base, and lists the specific flags (ERC-20 conformance, ownership renounce, upgradeable proxy). It implies a read-only operation without destructive effects, which is adequate for a risk assessment 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?
The description is two sentences with zero wasted words. The first sentence front-loads the action and key outputs, and the second sentence adds the audience and 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?
Despite lacking an output schema, the description adequately covers the input (address) and output (risk score + flags). It mentions the key flags but does not specify the output format or how the score is presented. For a simple tool with one parameter, it is mostly complete but could briefly describe the return 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?
The schema already describes the only parameter 'address' as 'Token contract address' with 100% coverage. The description repeats this ('Pass a token contract address') without adding new syntax or format details, meeting the baseline but not exceeding it.
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 takes a token contract address and returns a risk score and flags including ERC-20 conformance, ownership renounce, and upgradeable proxy. It specifies the live computation from Base and targets trading bots and agents for token vetting, effectively distinguishing it from siblings like 'secure_token'.
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 explicitly states the use case: vetting tokens before buying by obtaining a risk score and flags. It provides clear context but does not mention when not to use or suggest alternatives among siblings, which is a minor gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetches the DexScreener boosts feed filtered to Base — up to 15 trending tokens with address, description, boost amount, and link. Great for discovery bots.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the output fields and result count (up to 15). It is clearly a read-only fetch. It does not mention error handling, data freshness, or rate limits, but for a simple, no-parameter tool, 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?
Two concise sentences: the first describes the function and output, the second adds the use case. No wasted words, front-loaded with key information.
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 or annotations, the description covers the essential aspects: source, filter, output fields, and count. It could mention result ordering or potential empty result handling, but it is sufficiently complete for a simple discovery 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 tool has zero parameters and schema coverage is 100%, so the description needs no parameter details. The absence of parameters is already clear from the empty input 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 fetches the DexScreener boosts feed filtered to Base, specifying the data returned (up to 15 tokens with address, description, boost amount, link). The verb 'Fetches' and specific resource distinguish it from sibling token tools like token_price or token_risk.
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 phrase 'Great for discovery bots' implies a use case, providing context on when to use this tool. However, it does not explicitly mention when not to use it or suggest alternative sibling tools, but the unique purpose makes this less critical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Provide a Base transaction hash and get a structured summary: from/to, ETH value, status, gas used, block, method selector, and nonce — straight from Base RPC.
| Name | Required | Description | Default |
|---|---|---|---|
| hash | Yes | Transaction hash |
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 data comes 'straight from Base RPC,' implying a real-time read operation. It does not explicitly state side effects, rate limits, or error handling, but for a simple query tool, this is adequate. The description does not contradict any hidden behaviors.
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 a single, well-structured sentence of 23 words. It front-loads the action ('Provide a Base transaction hash and get...') and lists key outputs efficiently. No extraneous information is present, making it highly concise.
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?
Despite the absence of an output schema, the description fully explains what the tool returns: from/to, ETH value, status, gas used, block, method selector, and nonce. It also clarifies the data source. For a tool with one parameter and no nested objects, this provides complete contextual information.
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 the parameter 'hash' described as 'Transaction hash.' The description adds value by specifying 'Base transaction hash,' clarifying the blockchain context. This extra detail helps the agent understand the required input beyond the schema, justifying a score above baseline.
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 verb 'get' and the resource 'structured summary' of a Base transaction. It lists specific fields (from/to, ETH value, status, gas used, block, method selector, nonce), making the tool's purpose precise and easily distinguishable from sibling tools like decode_selector, which focuses only on method selectors.
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 indicates when to use this tool: when you have a Base transaction hash and want a summary. However, it does not mention when not to use it or provide alternatives (e.g., decode_selector for just method selectors). This lack of exclusions or context reduces guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns native ETH plus WETH, USDC, USDbC, DAI, cbETH balances for any Base address, enriched with live USD values via DexScreener. Only non-zero holdings are returned.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Wallet address |
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 that it returns only non-zero holdings and enriches with live USD values via DexScreener. However, it does not mention error handling, rate limits, or what happens for invalid addresses.
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 concise sentences, front-loaded with the core functionality, 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 simplicity (1 parameter, no output schema), the description covers the key aspects but lacks detail on the return format or structure of the enriched balances.
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 'address' has a schema description 'Wallet address', which is sufficient. The tool description does not add extra meaning beyond the schema, but schema coverage is 100%, so 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 specifies the exact tokens (ETH, WETH, USDC, USDbC, DAI, cbETH) and network (Base), with a clear verb 'returns'. It distinguishes from siblings like token_price and market_snapshot.
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 explicitly states the context: 'for any Base address' and the condition 'only non-zero holdings are returned'. It does not provide explicit when-not-to-use or alternatives, but the 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.
Pass a city and get a structured weather report. Mirrors the canonical x402 /weather example so you can compare wire formats.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | City |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, rate limits, or what constitutes the 'structured report'. The mention of mirroring a canonical example is vague and does not compensate for missing behavioral context.
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 concise with two sentences. The first sentence clearly states the operation, and the second provides useful context without unnecessary words. Every sentence serves a purpose.
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?
The tool is simple with one parameter and no output schema. The description adequately explains the input and that output is a structured report, but lacks details about output fields or behavior. It is minimally complete.
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 one parameter 'city' described as 'City'. The description adds no further meaning beyond the schema, such as format examples or constraints. Baseline 3 is appropriate as the schema already documents the parameter.
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 verb ('Pass' and 'get') and the resource ('structured weather report for a city'). It also distinguishes itself by referencing a canonical example, making its purpose evident and distinct from 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?
No guidance on when to use this tool versus alternatives. While the sibling tools are diverse, the description does not explicitly state when to prefer this tool or any exclusions. It merely implies usage for city weather queries.
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.
v0.1.1address_intelai_extractai_summarizeai_translatecontract_abidecode_selectorgas_oraclemarket_snapshotprice_alertquotesecure_tokentoken_pricetoken_risktrending_tokenstx_decodewallet_tokensweatherMost tools have distinct purposes; minor overlap exists between address_intel and wallet_tokens (both provide balances) and between token_price and token_risk (both analyze tokens), but descriptions clarify differences.
All names use snake_case, but the naming pattern is inconsistent: some start with nouns (address_intel, token_price) while others start with categories (ai_extract, ai_summarize) or are generic (weather, quote). No verb_noun pattern is followed.
17 tools is slightly above average but justifiable for a multi-purpose server. Each tool provides a distinct utility, though the overall set feels a bit scattered.
The tool set covers a broad collection of independent utilities (blockchain, AI, general). Within blockchain read operations, it's fairly complete, but missing features like historical data or write capabilities. For a 'bazaar' concept, coverage is adequate.
15 paid AI agent primitives via x402 (USDC on Base). Pay-per-call MCP server.
Monetize any MCP server: x402 paywall, pay-per-call billing in USDC on Base, agent marketplace.
Pay-per-call tools for autonomous agents, settled in USDC on Base via x402.
x402 MCP for agents: crypto prices, funding, DeFi yields, Polymarket, Base RPC + MCP security.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/sukrutkrdg/x402-bazaar-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
