This MCP server provides 14 pay-per-use tools for blockchain, AI, and utility tasks, funded via USDC micropayments on Base mainnet — no API keys or subscriptions required.
Blockchain & Utility Tools ($0.001–$0.010):
anchor_hash ($0.005): Anchor any 32-byte hash simultaneously to Base and Solana mainnets, returning both transaction URLs as cryptographic proof of existence.
screen_wallet ($0.001): OFAC SDN sanctions and AML screening for EVM or Solana wallets, returning flagged programs and a low/medium/high risk verdict.
attest_decision ($0.010): Verify a wallet signature over an (input_hash, output_hash, decision) tuple and dual-chain anchor the result on Base and Solana, creating an auditable receipt for AI agent decisions.
decode_tx ($0.001): Structurally decode any mainnet transaction (Base, Ethereum, or Solana) by hash.
resolve_name ($0.001): Cross-chain name resolution for ENS (.eth) and Bonfida SNS (.sol) names to wallet addresses.
token_price ($0.001): USD spot price, 24h change, and market cap for any token by symbol or chain + contract address.
decode_calldata ($0.001): Decode raw EVM calldata into a human-readable function name, signature, and typed parameter values.
parse_datetime ($0.001): Convert freeform datetime strings (e.g. "tomorrow at noon", "in 2 hours") into structured ISO 8601 format, unix epoch, and more.
intel_wallet ($0.005): Bundled wallet intelligence — balances across Base, Ethereum, and Solana, transaction count, ENS/SNS identity, and sanctions verdict in a single call.
LLM-Powered Tools ($0.01–$0.05):
roast: Generate a witty 3–5 paragraph roast of any target (wallet, tweet, code, idea, etc.).
oracle: Yes/no/maybe answer to any question with a reason, plus a dual-chain anchored cryptographic receipt.
tldr: Summarize a URL (up to 500KB) or pasted text into 3–5 concise bullet points.
aura: Returns a color, tier (S/A/B/C/D/F), score (0–9999), and punchy aura reading for any input.
grade: Assigns an academic letter grade (A+ to F) with red-pen marginalia and a summary paragraph for any input.
All calls are debited automatically from a configured Base wallet via the x402 micropayment protocol.
Enables automatic USDC micropayments via Coinbase's x402 protocol for pay-per-use access to the MCP server's tools.
Provides tools for transaction decoding, calldata decoding, and other blockchain operations on the Ethereum mainnet.
Provides tools for anchoring hashes, wallet screening, transaction decoding, and name resolution on the Solana mainnet.
MCP server exposing 14 anchor-x402 services as tools any Claude Desktop / Cursor / Codex / Continue agent can call. Pay-per-use USDC via x402 on Base mainnet — no API keys, no subscriptions.
This package (stdio) needs a funded EVM private key in the local process (ANCHOR_WALLET_PRIVATE_KEY) and pays for each call on your behalf. Convenient, but you are handing a hot key to a process.
Streamable HTTP — POST https://api.anchor-x402.com/mcp — needs no install and no key handover. It exposes all 18 services (four more than this package: roll_random, investigate_wallet, ledger_summary, ledger_report), and you pay per call with a PAYMENT-SIGNATURE header, so your key never leaves your side.
{
"mcpServers": {
"anchor-x402": { "url": "https://api.anchor-x402.com/mcp" }
}
}Clients that speak remote MCP natively take the url form above. For one that only launches stdio processes, bridge it:
{
"mcpServers": {
"anchor-x402": {
"command": "npx",
"args": ["-y", "mcp-remote", "https://api.anchor-x402.com/mcp"]
}
}
}Protocol revisions supported: 2026-07-28, 2025-11-25, 2025-06-18, 2025-03-26 — both the stateless era and the initialize handshake era, on one endpoint. server/discover and tools/list are free; tools/call is paid.
Payment is the ordinary x402 dance, surfaced inside MCP rather than around it: an unpaid tools/call returns a result (not a JSON-RPC error) with isError: true and the challenge in structuredContent.accepts, plus the canonical payment-required header. Sign one of the options and retry the identical call with PAYMENT-SIGNATURE. The challenge comes back as a result on purpose — an agent can read it and pay, whereas a JSON-RPC error would be swallowed by the client before the model ever saw it.
Server card: /.well-known/mcp/server-card.json. A worked client, including the adapter that bridges a stock x402 fetch wrapper to the MCP result shape, is in examples/agent/mcp-paid-call.mjs.
The rest of this README covers the stdio package.
Related MCP server: x402-bazaar-mcp
Fourteen tools, $0.001–$0.05 per call.
Commodity primitives (9, $0.001–$0.02):
Tool | Price | What it does |
| $0.005 | Anchor any 32-byte hash to Base + Solana mainnet in parallel; returns both tx URLs |
| $0.02 | Wallet risk pre-flight — OFAC sanctions + address-reputation (drainer/phishing/mixer) → allow/review/block |
| $0.010 | Attest a decision — sign it yourself or let the treasury sign — then dual-chain anchor; free re-verify at /v1/attest/verify |
| $0.001 | Structured decode of any mainnet tx (Base / Ethereum / Solana) |
| $0.001 | Cross-chain name resolution (ENS, Bonfida SNS) |
| $0.001 | USD spot price for any token by symbol or chain+contract |
| $0.001 | 4byte selector + ABI param decode for raw EVM calldata |
| $0.001 | Freeform datetime string → structured ISO 8601 |
| $0.005 | Bundled wallet intelligence: balances + activity + identity + sanctions in one call |
Universal LLM endpoints (5, $0.01–$0.05) — added in v0.2:
Tool | Price | What it does |
| $0.05 | Witty 3-5 paragraph roast of any target — wallet, tweet, code, idea, anything |
| $0.05 | Yes/no oracle. Returns YES/NO/MAYBE + reason + dual-chain anchored |
| $0.01 | Summarize a URL (fetches up to 500KB) or pasted text into 3-5 concise bullets |
| $0.01 | Returns color, tier (S/A/B/C/D/F), score 0-9999, and a punchy 2-3 sentence aura read |
| $0.01 | Academic letter grade (A+ to F) with red-pen marginalia and one-paragraph summary |
The investigator (/v1/investigate, $1.77 async) and the hosted chatbot at chat.anchor-x402.com are not included in the MCP — they're accessed directly via the HTTP API and the browser respectively.
The MCP server pays for itself — your wallet gets debited automatically for each call. No prepay, no API key, no account.
Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"anchor-x402": {
"command": "npx",
"args": ["-y", "anchor-x402-mcp"],
"env": {
"ANCHOR_WALLET_PRIVATE_KEY": "0xYOUR_BASE_WALLET_PRIVATE_KEY"
}
}
}
}Restart Claude Desktop. Ask: "Anchor the hash 7646dda1564bde0ef3f3971f4c002962df64246da4aa1d8c47247e7632494710 on mainnet" — it'll call anchor_hash and pay $0.005 USDC from your wallet.
Add to your project's .mcp.json:
{
"anchor-x402": {
"command": "npx",
"args": ["-y", "anchor-x402-mcp"],
"env": {
"ANCHOR_WALLET_PRIVATE_KEY": "0xYOUR_BASE_WALLET_PRIVATE_KEY"
}
}
}Edit ~/.codex/config.toml:
[mcp_servers.anchor-x402]
command = "npx"
args = ["-y", "anchor-x402-mcp"]
[mcp_servers.anchor-x402.env]
ANCHOR_WALLET_PRIVATE_KEY = "0xYOUR_BASE_WALLET_PRIVATE_KEY"Restart codex. Type /mcp to confirm anchor-x402 shows in the loaded servers list.
Settings → Integrations → MCP servers → Add server. Paste:
{
"command": "npx",
"args": ["-y", "anchor-x402-mcp"],
"env": {
"ANCHOR_WALLET_PRIVATE_KEY": "0xYOUR_BASE_WALLET_PRIVATE_KEY"
}
}Save, restart, the 14 tools appear in any chat with tool-use enabled.
Edit ~/.cursor/mcp.json (global) or <project>/.cursor/mcp.json (project-scoped):
{
"mcpServers": {
"anchor-x402": {
"command": "npx",
"args": ["-y", "anchor-x402-mcp"],
"env": {
"ANCHOR_WALLET_PRIVATE_KEY": "0xYOUR_BASE_WALLET_PRIVATE_KEY"
}
}
}
}from openai_agents import Agent, MCPServerStdio
mcp = MCPServerStdio(
command="npx",
args=["-y", "anchor-x402-mcp"],
env={"ANCHOR_WALLET_PRIVATE_KEY": "0xYOUR_BASE_WALLET_PRIVATE_KEY"},
)
agent = Agent(name="researcher", model="gpt-4o", mcp_servers=[mcp])Same package, same env, programmatic instead of config-driven.
Same shape — command: npx, args: [-y, anchor-x402-mcp], env carries your wallet key. The MCP SDK handles transport.
Or install via Smithery one-liner:
npx -y @smithery/cli install anchor-x402-mcp --client claude(replace --client claude with cursor, codex, windsurf, etc.)
ANCHOR_WALLET_PRIVATE_KEY=0xYOUR_KEY npx anchor-x402-mcpSpeaks MCP over stdio. Pipe into any MCP-compatible client.
The wallet you set as ANCHOR_WALLET_PRIVATE_KEY needs USDC on Base mainnet. Any amount works — even $1 buys 100 anchor calls or 1000 commodity-tier calls. Send USDC to your wallet's Base address:
USDC contract on Base: 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913
Bridge from Ethereum mainnet via bridge.base.org
Buy directly on Coinbase and withdraw to Base
The MCP server signs payments via x402 — Coinbase's open HTTP-native micropayments protocol. Each request:
Hits an anchor-x402 endpoint
Gets a 402 with payment requirements
Server signs a USDC transfer authorization with your private key
Retries the request with the signed payment — the API settles via Coinbase's facilitator
You see the response, your wallet's USDC balance ticks down by the call price. Sub-second, no ledger, no account.
Variable | Required? | Purpose |
| Yes for paid calls | EVM private key. The wallet pays for x402 calls. |
| No | Override the API base URL. Default: |
If ANCHOR_WALLET_PRIVATE_KEY is unset, paid tool calls return a friendly 402 message explaining how to set it. /health and /openapi.json (not exposed as tools, but reachable via direct curl) work without payment.
The private key lives in your MCP client's config file. Treat it like a hot wallet — only fund what you're willing to spend autonomously.
Recommended: generate a fresh wallet specifically for agent use. Top up periodically; don't reuse a wallet that holds significant funds.
The MCP server only signs USDC payment authorizations to anchor-x402's known treasury addresses (visible in the 402 response). It cannot drain your wallet to arbitrary addresses.
Source code is fully open at github.com/hypeprinter007-stack/anchor-x402-mcp. Audit before installing.
Every anchor_hash and attest_decision call returns Base + Solana tx URLs. These are independently verifiable on the public block explorers — agents can confirm an anchor exists without re-paying:
Base: https://basescan.org/tx/<base.tx> — Input Data field contains the merkle root
Solana: https://solscan.io/tx/<solana.tx> — Memo program data contains the same hex
The on-chain bytes are the receipt; the API response is just a convenience wrapper around them. See the on-chain verifiability primer for the full verification recipe.
"Payment required (402). Set ANCHOR_WALLET_PRIVATE_KEY..." You haven't configured a wallet. Add the env var to your MCP config and restart Claude Desktop.
"Payment failed (402). The wallet may be out of USDC..."
Your wallet ran out. Send USDC on Base to the wallet address shown in the server's startup log (it logs payer=0x… to stderr).
"anchor-x402 request failed: ..."
Network or DNS issue. Check https://api.anchor-x402.com/health returns 200; if not, see the status page.
Live API: https://api.anchor-x402.com
MCP over HTTP: https://api.anchor-x402.com/mcp — all 18 tools, no key handover
MCP server card: https://anchor-x402.com/.well-known/mcp/server-card.json
Site / trust portal: https://anchor-x402.com
Server source: https://github.com/hypeprinter007-stack/anchor-x402
MCP server source (this repo): https://github.com/hypeprinter007-stack/anchor-x402-mcp
x402 protocol: https://github.com/coinbase/x402
MCP spec: https://modelcontextprotocol.io
MIT
Anchor a 32-byte hash to BOTH Base mainnet (as EIP-1559 calldata) and Solana mainnet (via the Memo program) in a single call. Returns both transaction hashes plus block-explorer URLs as cryptographic proof of when the hash existed. Pure infrastructure — no opinions about content. Use for DAO vote receipts, AI decision attestations, contract notarization, scientific data integrity, audit trails. $0.005 USDC.
| Name | Required | Description | Default |
|---|---|---|---|
| hash | No | Pre-computed 32-byte hex hash (64 chars, no 0x prefix). Mutually exclusive with `data`. | |
| data | No | Arbitrary JSON to be canonicalized + SHA-256'd by the server. Mutually exclusive with `hash`. | |
| note | No | Optional 200-char note included in the response (NOT on-chain). |
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 the cost ($0.005 USDC), the dual-chain anchoring, and that it returns transaction hashes and URLs. It states 'pure infrastructure — no opinions about content', but does not discuss permanence, reversibility, or potential errors. This is adequate but not highly detailed.
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 paragraph that front-loads the core purpose, then details returns, use cases, and cost. It is dense but not overly long. Minor redundancy ('Pure infrastructure') could be trimmed, but overall it is 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?
Given the tool has no output schema, the description explains the return values (both transaction hashes plus block-explorer URLs). It covers intended use cases, cost, and behavior. It lacks details about prerequisites (e.g., needing USDC balance) or error scenarios, but for a simple tool with three parameters it is reasonably 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 input schema covers all 3 parameters with full descriptions. The description adds meaning: it clarifies that 'data' is canonicalized and SHA-256'd by the server, and that 'note' is optional and off-chain. This goes beyond the schema, which only describes the 'hash' parameter's format and mutual exclusivity.
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: anchoring a 32-byte hash to both Base mainnet and Solana mainnet in a single call. It specifies the verb 'anchor' and the resource (hash), and distinguishes from siblings like 'attest_decision' which likely handles decision attestations rather than generic hash anchoring.
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 explicit use cases (DAO vote receipts, AI decision attestations, etc.), giving clear context for when to use the tool. However, it does not explicitly mention when not to use alternatives or compare to sibling tools like 'attest_decision'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify a wallet signature over (input_hash, output_hash, decision) with domain separation, then dual-chain anchor the resulting Merkle root on Base and Solana mainnet. Returns the verified signer plus on-chain proof URLs. Use when an AI agent's decision needs a cryptographic, auditable receipt — autonomous trade approvals, AI-assisted contract decisions, model-output attestation for liability records. $0.010 USDC.
| Name | Required | Description | Default |
|---|---|---|---|
| input_hash | Yes | 64-char hex SHA-256 of the agent's input. | |
| output_hash | Yes | 64-char hex SHA-256 of the agent's output / decision payload. | |
| decision | Yes | Free-form short label, e.g. "APPROVED", "REJECTED", "CONFIDENCE=0.93" (max 64 chars). | |
| scheme | Yes | Signature scheme. | |
| signature | Yes | 0x-prefixed hex (eip191) or base58 (ed25519). | |
| signer_pubkey | No | Required for ed25519 (Solana base58 pubkey). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description fully discloses the verification process, domain separation, dual-chain anchoring, return values, and cost ($0.010 USDC), meeting the burden.
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 cover the core function and use cases, with cost appended. Every sentence earns its place; 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?
Explains return value (signer + proof URLs) and includes cost. Lacks error handling or prerequisites, but sufficient for a straightforward tool with clear inputs.
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 parameters with descriptions (100% coverage). Description adds no extra parameter details beyond the overall process, so 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?
Clearly states the tool verifies a wallet signature and anchors a Merkle root on two chains, with specific verbs and resources. No confusion with 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?
Explicitly lists use cases (autonomous trade approvals, AI-assisted contract decisions, etc.) and provides context. Lacks explicit 'when not to use', but sufficient for the intended purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Aura read of any target — returns color (free-form e.g. 'molten gold with copper veins'), tier (S/A/B/C/D/F), score (0-9999), and a 2-3 sentence punchy description. Universal input — wallet, tweet, project, person, idea, meme. Use for viral / shareable content, brand vibes, social. $0.01 USDC.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Anything to read the aura of (max 4000 chars). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses output format, input type, and cost ($0.01 USDC). No annotations exist, so description carries burden. Could mention data sources or rate limits, but remains sufficient for a simple 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?
Three sentences: output, input scope, use cases and cost. Front-loaded with key information, 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 simple tool (1 param, no output schema), description covers purpose, input, output, cost, and use cases comprehensively.
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 describes 'target' with max chars. Description adds examples (wallet, tweet, project) and emphasizes universality, enriching 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?
Description clearly states the tool reads aura of any target and returns specific outputs (color, tier, score, description). It distinguishes from siblings by its unique function (aura reading) and universal input.
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 explicit use cases: 'viral / shareable content, brand vibes, social'. Does not mention 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.
Decode raw EVM calldata into a human-readable function name, canonical signature, and typed parameter values. Resolves the 4-byte selector against openchain.xyz's signature directory, then ABI-decodes the args. Use for tx inspection before signing, mempool analysis, debug. EVM-only (chain='ethereum'); 'solana' returns 400. $0.001 USDC.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | Yes | EVM-only; 'solana' returns 400. | |
| calldata_hex | Yes | Raw EVM calldata (>=4 byte selector), with or without 0x prefix. | |
| contract_address | No | Optional. Reserved for future on-chain ABI lookups. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: resolves 4-byte selector via openchain.xyz, ABI-decodes args, provides cost ($0.001 USDC), and specifies error for solana. No contradictions.
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?
Concise, front-loaded with main purpose, logically structured with key details (behavior, use cases, constraints) in minimal 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?
Provides sufficient context for a tool with no output schema: purpose, external resolution, cost, constraints. Lacks details on failure cases (e.g., invalid calldata, missing signature), but coverage is adequate for typical use.
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 parameters (100% coverage). Description adds minor value by reinforcing chain constraint and calldata requirements, but largely repeats schema descriptions. No significant extra semantic insight.
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 'decode' and the resource 'raw EVM calldata', listing specific outputs (function name, signature, typed parameter values). It distinguishes from siblings like decode_tx by specifying EVM-only and calldata-level decode.
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 lists use cases (tx inspection before signing, mempool analysis, debug) and constraints (EVM-only, solana returns 400). However, no direct mention of alternatives among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Structured decode of any mainnet transaction by hash. Supply chain ('base' | 'ethereum' | 'solana') and tx_hash. Returns from/to/value/gas/status/calldata for EVM, or slot/fee/signers/program_calls for Solana. Mined txs cached in-process. Use for tx inspection, audit, agent UX (rendering tx summaries to users). $0.001 USDC.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | Yes | ||
| tx_hash | Yes | EVM 0x+64hex or Solana base58 signature. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description provides some behavioral info: 'Mined txs cached in-process' and pricing ($0.001). However, it does not disclose authentication requirements, rate limits, or error conditions, leaving 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?
Three sentences, front-loaded with the core action. No redundant information. However, could be slightly more structured by separating output details from pricing.
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 simple schema and no output schema, the description covers inputs, outputs (per chain), use cases, caching, and pricing. It is sufficiently complete for an agent to decide 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 50% (only tx_hash described). The tool description reiterates that chain is from the given enum list and tx_hash is the hash, adding minimal value beyond schema. It does not explain what the returned fields mean in detail.
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 it decodes a mainnet transaction by hash, specifying the input requirements (chain and hash) and output fields per chain. Differentiates from sibling tools like decode_calldata which only decode calldata, not full transactions.
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 examples of use cases (tx inspection, audit, agent UX) but does not explicitly state when not to use it or mention alternatives. Lacks guidance on when to prefer this over decode_calldata for calldata-only needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Academic letter grade (A+ to F) with 3-7 red-pen marginalia one-liners and a one-paragraph teacher summary. Universal input — code, pitch deck, tweet, wallet, idea. Use for sharp feedback at low cost, prompt engineering eval, pre-investment screen. $0.01 USDC.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Anything to grade (max 6000 chars). |
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 the output format (grade, marginalia, summary) and cost but omits behavioral traits like data persistence, idempotency, or potential 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?
The description is two sentences, front-loading the core function (grade with marginalia and summary) and then adding usage and cost. Every sentence provides necessary information without waste.
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 the output and input constraints (6000 chars via schema). It covers the essential aspects for an agent to decide if and when to use it.
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 required parameter 'target'. The description adds value beyond the schema by calling the input 'universal' and listing examples (code, pitch deck, etc.), which helps the agent understand acceptable inputs.
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 tool grades by providing a letter grade (A+ to F) with marginalia and a summary, and clarifies the universal input type. It distinguishes from siblings like 'roast' by focusing on academic-style grading with specific output components.
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 use cases (sharp feedback, prompt engineering eval, pre-investment screen) and cost ($0.01 USDC). While it doesn't mention when not to use or name alternatives, the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Unified wallet intelligence bundle. ONE call returns balances on Base + Ethereum + Solana, USDC across chains, transaction count, ENS/SNS reverse lookup, and sanctions verdict — all aggregated from 8–10 parallel free public sources. Replaces a wallet-investigation script with a single $0.005 call. Use for KYB pre-flight, counterparty research, fraud detection. $0.005 USDC.
| Name | Required | Description | Default |
|---|---|---|---|
| wallet | Yes | EVM 0x… address (40 hex) or Solana base58 pubkey. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description discloses cost ($0.005 USDC) and the data sources (8-10 parallel free public sources) but lacks details on rate limits, authentication needs, error handling, or data freshness. Adequate but not comprehensive.
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?
Three sentences with no wasted words. Front-loaded with the core value proposition: 'Unified wallet intelligence bundle. ONE call returns...' 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?
Given the tool's complexity (multi-chain, multiple data points), the description covers the major return elements. Missing details like error cases or data update frequency, but overall sufficient for an agent to understand what it does.
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?
Only one parameter 'wallet' with schema description 'EVM 0x… address (40 hex) or Solana base58 pubkey.' Schema coverage is 100%, making the description sufficient. No additional insight beyond the schema is provided.
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 is a 'Unified wallet intelligence bundle' returning balances on Base, Ethereum, Solana, USDC across chains, transaction count, ENS/SNS reverse lookup, and sanctions verdict. It distinguishes from sibling tools like screen_wallet by advertising aggregated data from 8–10 sources in one call.
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 lists use cases: 'KYB pre-flight, counterparty research, fraud detection'. Does not explicitly state when not to use or compare to alternatives, but the context is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Yes/no oracle with dual-chain anchored verdict. LLM answers YES / NO / MAYBE with one-sentence reason, then anchors sha256(question|answer|timestamp) to Base + Solana mainnet so anyone can prove the question was asked at a specific time. Use for prediction-market commits, conditional contracts, time-stamped opinions, settling bets. $0.05 USDC.
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | A yes/no question (max 1000 chars). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: LLM provides answer with reason, anchors a SHA256 hash to Base and Solana, and costs $0.05 USDC. It sets proper expectations about verifiability and cost.
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 a single focused paragraph covering key points. It is concise but could be broken into bullet points for easier parsing. 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?
For a simple one-parameter tool with no output schema, the description covers purpose, behavior, cost, and use cases. It lacks explicit return format specification, but the context 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?
Schema coverage is 100% and already describes the 'question' parameter as a yes/no question. The description adds context about the answer format (one-sentence reason) but does not significantly enhance understanding 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?
Description clearly states the tool is a yes/no oracle that returns an answer (YES/NO/MAYBE) with a reason and anchors it to two blockchains for verifiability. It distinguishes itself from sibling tools like 'attest_decision' or 'grade' by its blockchain anchoring and specific use cases.
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 lists use cases: prediction-market commits, conditional contracts, time-stamped opinions, settling bets. This helps the agent decide when to use this tool over siblings, though it does not explicitly state 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.
Parse any freeform datetime string ('tomorrow at noon', 'yesterday', '2026-05-13T15:30Z', 'in 2 hours') into a fully structured normalized form: ISO 8601, unix epoch, components (year/month/day/hour/min/sec/weekday), relative seconds + human form, confidence score. Saves agent LLM tokens on date parsing. $0.001 USDC.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | Freeform datetime string. | |
| base_time | No | Optional ISO 8601 reference; defaults to now UTC. | |
| timezone | No | Optional IANA tz name (e.g. 'America/New_York'); defaults to UTC. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses cost ($0.001 USDC) and explains the output structure (ISO 8601, unix epoch, components, confidence). It does not mention error handling or limits, but overall provides good 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 a single sentence that includes examples, output list, and cost info. It is concise but somewhat dense; slight improvement could come from breaking into bullet points or shorter 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?
Given no output schema, the description thoroughly explains the return format (ISO 8601, unix epoch, components, confidence). It also adds context on pricing. However, it does not cover error cases or rate limits, leaving minor 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%, so the description does not need to repeat parameter definitions. It adds value by providing example inputs ('tomorrow at noon') and stating the default behavior for optional parameters, going beyond the schema's minimal descriptions.
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 specific verbs ('Parse') and resource ('freeform datetime string') and lists detailed output components. It clearly distinguishes itself from siblings like anchor_hash or decode_calldata which serve entirely 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?
The description includes a clear usage hint ('Saves agent LLM tokens on date parsing') implying efficiency is a reason to use this tool. However, it does not explicitly state when not to use it or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cross-chain name resolution. Pass a name like 'vitalik.eth' or 'bonfida.sol' and get back the resolved address(es) across supported registries. Currently supports ENS (.eth) and Bonfida SNS (.sol). Cached 1h server-side. $0.001 USDC.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Human-readable name, e.g. 'vitalik.eth' or 'bonfida.sol'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavioral traits: it mentions server-side caching (1 hour) and cost ($0.001 USDC). It also notes that only two registries are currently supported, setting correct expectations.
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 with three sentences, each serving a purpose: stating the function, giving usage examples, and providing operational details (registries, caching, cost). 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 is complete. It explains purpose, input format, supported services, caching behavior, and cost, covering all relevant aspects.
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 covers the only parameter (name) with 100% description coverage. The description adds value by providing example values ('vitalik.eth', 'bonfida.sol') and clarifying the format, which goes beyond the schema's generic 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 resolves human-readable names across blockchains, specifying supported registries (ENS, SNS) and giving examples ('vitalik.eth', 'bonfida.sol'). It distinguishes from siblings like anchor_hash or decode_calldata, which are unrelated.
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 (cross-chain name resolution) but does not explicitly state when not to use it or provide alternatives. However, the context is clear enough for an AI agent to decide appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Witty, observational roast of any target — a wallet address, tweet, code snippet, startup idea, person, meme, anything. Returns a 3-5 paragraph LLM roast and a one-sentence neutral summary of the target. Clever, not mean-spirited. Use for entertainment, demo content, social. $0.05 USDC.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Anything to roast — free text up to 8000 chars. |
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 the tone ('clever, not mean-spirited') and output structure, as well as cost ($0.05 USDC). However, it does not mention side effects, response time, or that it uses an LLM, which is acceptable for a simple generation tool but not exhaustive.
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: two sentences covering purpose, examples, output, tone, usage, and cost. Every sentence earns its place with 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 there is no output schema, the description adequately explains the return format (3-5 paragraph roast + neutral summary). For a generation tool with minimal parameters, this covers all necessary 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?
The single parameter 'target' is fully described in the schema (100% coverage). The description adds value by expanding on what constitutes a target (anything, including examples) and specifying the character limit (8000 chars), going beyond the schema's brief 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 generates a witty, observational roast with specific examples of targets (wallet address, tweet, etc.) and mentions the output format (3-5 paragraph roast + neutral summary). This distinguishes it from sibling tools like 'grade' or 'tldr'.
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 'Use for entertainment, demo content, social,' providing clear context for when to use. It does not explicitly mention when not to use or list alternatives, but the unique nature of this tool among siblings makes this sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sanctions + AML screening for any EVM or Solana wallet address. Returns sanctions match (boolean), specific OFAC SDN programs flagged (Tornado Cash, Lazarus Group, Hydra Market, Garantex, Blender.io etc.), inferred chain, and a low/medium/high risk verdict. Use for AML pre-flight checks before any treasury transfer, KYC onboarding, vendor diligence, payroll wallet verification, marketplace counterparty checks. $0.001 USDC.
| Name | Required | Description | Default |
|---|---|---|---|
| wallet | Yes | EVM 0x… address (40 hex) or Solana base58 pubkey. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses return fields (sanctions match, OFAC programs, chain, risk verdict) and cost. No mention of rate limits or error handling, but key behaviors are covered.
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?
Four concise sentences, front-loaded with purpose. Every sentence adds value (purpose, inputs, outputs, use cases, cost). 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?
Given no annotations or output schema, the description adequately explains inputs, outputs, use cases, and cost. Could elaborate on error cases or chain detection, but overall sufficient for a single-parameter 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 parameter description. Description reinforces accepted address formats (EVM hex or Solana base58) and adds context about chain inference. Goes beyond schema by specifying output details.
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 'Sanctions + AML screening for any EVM or Solana wallet address', using specific verb (screening) and resource. Distinguishes from siblings like intel_wallet or decode_tx by focusing on sanctions compliance.
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 lists use cases: AML pre-flight checks, KYC onboarding, vendor diligence, etc. Does not mention when not to use or alternatives, but the guidance is clear and comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Summarize a URL or pasted text into 3-5 concise bullets. Fetches up to 500KB on the URL path, strips HTML with BeautifulSoup. Use for research distillation, link-rot insurance, agent reading lists. Exactly one of text or url. $0.01 USDC.
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | Pasted text to summarize. Omit if providing `url`. | |
| url | No | URL to fetch + summarize. Omit if providing `text`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description bears full weight. It discloses fetching up to 500KB, stripping HTML via BeautifulSoup, and a cost of $0.01 USDC. No destructive behavior is implied. It could mention auth or rate limits, but the transparency is good for a simple 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?
Three sentences each adding value: main action, technical detail, usage and constraints, and cost. Front-loaded with purpose, no wasted words. Excellent conciseness.
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 but the description covers purpose, behavior, constraints, use cases, and cost. It doesn't specify error handling (e.g., if both parameters provided) or output format details beyond '3-5 bullets,' but given no output schema, this is nearly 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 description coverage is 100% with each parameter described. The description adds the mutual exclusivity rule 'Exactly one of text or url' and context for the URL parameter regarding size limits. This adds meaningful guidance 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 summarizes a URL or pasted text into 3-5 concise bullets, with specific verb and resource. It includes details like fetching up to 500KB and stripping HTML, and is distinct from siblings like 'roast' or 'decode_tx'.
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 explicit use cases: 'research distillation, link-rot insurance, agent reading lists.' It also states the mutual exclusivity constraint 'Exactly one of text or url.' However, it does not name alternatives or specify when not to use the tool, though no direct alternative exists among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
USD spot price for any major token. Pass either symbol (BTC, ETH, SOL, USDC, etc.) OR (chain + contract). Returns USD price, 24h change percent, market cap, fetched-at timestamp. CoinGecko-backed, cached 60s. $0.001 USDC.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | No | Token symbol like 'ETH'. Mutually exclusive with chain+contract. | |
| chain | No | Chain slug: base, ethereum, solana, polygon, arbitrum, optimism, bsc, avalanche. | |
| contract | No | Token contract address. Required with chain. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description fully covers behavior: CoinGecko-backed, cached 60s, cost $0.001 USDC, and returns USD price, 24h change, market cap, and timestamp. No contradictions.
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 packed with all necessary information: purpose, parameters, source, caching, cost, and return fields. 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?
Despite missing output schema, description compensates by listing return fields (price, change %, market cap, timestamp). Covers input options, source, caching, and cost. Fully sufficient for a simple lookup 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%, so description adds marginal value. It reiterates mutual exclusivity (already in schema) and provides example values, enhancing usability but not essential.
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 it returns USD spot price for major tokens, specifying two input options (symbol or chain+contract). Distinct from siblings which deal with hashes, attestations, decoding, 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 tells agent to pass either 'symbol' OR 'chain+contract', with examples. Does not explicitly exclude alternatives, but siblings are unrelated so usage is clear.
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.
v0.2.1auragradeoracleroasttldrv0.1.2anchor_hashattest_decisiondecode_calldatadecode_txintel_walletparse_datetimeresolve_namescreen_wallettoken_priceScored across 14 tools
Multiple clusters have fuzzy boundaries: intel_wallet subsumes screen_wallet's sanctions verdict, roast/aura/grade all accept the same universal target inputs, and anchor_hash/attest_decision/oracle all produce dual-chain anchored proofs with only subtle workflow differences. Descriptions carry some disambiguating detail, but an agent could easily misselect between several pairs.
Seven tools follow a clean verb_noun snake_case pattern (anchor_hash, decode_tx, parse_datetime), but the set also mixes in noun_noun names (token_price, intel_wallet) and five bare single-word names (roast, oracle, tldr, aura, grade). The lack of a uniform convention makes the tool surface feel like two or three different servers bolted together.
14 tools is within a reasonable band and none are strictly redundant duplicates. However, the count is slightly inflated by unrelated mini-domains — anchoring infrastructure, wallet/chain data utilities, and LLM entertainment — which dilutes the server's focus.
For a server whose core promise is cryptographic proof, the anchor-and-prove lifecycle has an obvious gap: there is no verify_anchor or anchor-status tool to check that a previously anchored hash still exists on-chain, forcing agents to work around via decode_tx or explorer URLs. Individual utilities like resolve_name and token_price feel complete, but the wallet screening surface is awkwardly split between screen_wallet and intel_wallet.
Production-grade MCP gateway delivering 8 real-time AI tools with instant x402 micropayments settled in USDC on Base Mainnet or SPL-USDC on Solana. Features Basescan contract auditing, wallet analytics, headless browser scraping, and pre-scraped oracle data feeds.
Production-grade MCP gateway delivering 8 real-time AI tools with instant x402 micropayments settled in USDC on Base Mainnet or SPL-USDC on Solana. Features Basescan contract auditing, wallet analytics, headless browser scraping, and pre-scraped oracle data feeds.
x402 MCP for agents: crypto prices, funding, DeFi yields, Polymarket, Base RPC + MCP security.
15 paid AI agent primitives via x402 (USDC on Base). Pay-per-call MCP server.
