9つのanchor-x402サービスを、Claude Desktop / Cursor / Codex / Continueエージェントが呼び出せるツールとして公開するMCPサーバー。Baseメインネット上のx402を介したUSDCによる従量課金制 — APIキーやサブスクリプションは不要です。
9つのツール、1呼び出しあたり$0.001〜$0.010：
ツール | 価格 | 機能 |
| $0.005 | 32バイトのハッシュをBase + Solanaメインネットに並行してアンカーし、両方のトランザクションURLを返します |
| $0.001 | EVMまたはSolanaウォレットのOFAC SDN制裁スクリーニング |
| $0.010 | (input_hash, output_hash, decision)に対するウォレット署名を検証し、結果をデュアルチェーンアンカーします |
| $0.001 | メインネットトランザクション（Base / Ethereum / Solana）の構造化デコード |
| $0.001 | クロスチェーン名前解決（ENS, Bonfida SNS） |
| $0.001 | シンボルまたはチェーン+コントラクトによるトークンのUSDスポット価格 |
| $0.001 | 生のEVM calldataの4byteセレクター + ABIパラメーターデコード |
| $0.001 | フリーフォームの日時文字列 → 構造化されたISO 8601 |
| $0.005 | バンドルされたウォレットインテリジェンス：残高 + アクティビティ + ID + 制裁情報を1回の呼び出しで取得 |
このMCPサーバーは自己完結型です。呼び出しごとにウォレットから自動的に引き落とされます。前払いやAPIキー、アカウントは不要です。
Related MCP server: x402-bazaar-mcp
~/Library/Application Support/Claude/claude_desktop_config.json (macOS) または %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"
}
}
}
}Claude Desktopを再起動します。次のように尋ねてください："Anchor the hash 7646dda1564bde0ef3f3971f4c002962df64246da4aa1d8c47247e7632494710 on mainnet" — これにより anchor_hash が呼び出され、ウォレットから$0.005 USDCが支払われます。
プロジェクトの .mcp.json に追加します：
{
"anchor-x402": {
"command": "npx",
"args": ["-y", "anchor-x402-mcp"],
"env": {
"ANCHOR_WALLET_PRIVATE_KEY": "0xYOUR_BASE_WALLET_PRIVATE_KEY"
}
}
}~/.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"codex を再起動します。/mcp と入力して、読み込まれたサーバーリストに anchor-x402 が表示されることを確認します。
設定 → 統合 → MCPサーバー → サーバーを追加。以下を貼り付けます：
{
"command": "npx",
"args": ["-y", "anchor-x402-mcp"],
"env": {
"ANCHOR_WALLET_PRIVATE_KEY": "0xYOUR_BASE_WALLET_PRIVATE_KEY"
}
}保存して再起動すると、ツール使用が有効なチャットで9つのツールが表示されます。
~/.cursor/mcp.json (グローバル) または <project>/.cursor/mcp.json (プロジェクトスコープ) を編集します：
{
"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])同じパッケージ、同じ環境変数で、設定駆動ではなくプログラムから利用可能です。
同じ形式です — command: npx, args: [-y, anchor-x402-mcp], 環境変数にウォレットキーを保持します。MCP SDKがトランスポートを処理します。
または Smithery のワンライナーでインストールします：
npx -y @smithery/cli install anchor-x402-mcp --client claude(--client claude を cursor, codex, windsurf などに置き換えてください)
ANCHOR_WALLET_PRIVATE_KEY=0xYOUR_KEY npx anchor-x402-mcpstdio経由でMCPを話します。MCP互換クライアントにパイプしてください。
ANCHOR_WALLET_PRIVATE_KEY に設定したウォレットには、Baseメインネット上のUSDCが必要です。金額はいくらでも構いません。$1あれば100回のアンカー呼び出し、または1000回のコモディティ層の呼び出しが可能です。ウォレットのBaseアドレスにUSDCを送金してください：
Base上のUSDCコントラクト: 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913
bridge.base.org を介してEthereumメインネットからブリッジ
Coinbaseで直接購入し、Baseに送金
MCPサーバーは x402（CoinbaseのオープンなHTTPネイティブマイクロペイメントプロトコル）を介して支払いに署名します。各リクエストの流れ：
anchor-x402 エンドポイントにヒット
支払い要件を含む402レスポンスを取得
サーバーが秘密鍵でUSDC転送承認に署名
署名済み支払いを添えてリクエストを再試行 — APIはCoinbaseのファシリテーターを介して決済
レスポンスが表示され、ウォレットのUSDC残高が呼び出し価格分だけ減少します。サブ秒単位、台帳不要、アカウント不要です。
変数 | 必須? | 目的 |
| 有料呼び出しには必須 | EVM秘密鍵。ウォレットがx402呼び出しの支払いを行います。 |
| いいえ | APIベースURLを上書きします。デフォルト: |
ANCHOR_WALLET_PRIVATE_KEY が設定されていない場合、有料ツールの呼び出しは設定方法を説明するフレンドリーな402メッセージを返します。/health および /openapi.json（ツールとしては公開されていませんが、直接 curl でアクセス可能）は支払いなしで動作します。
秘密鍵はMCPクライアントの設定ファイルに保存されます。ホットウォレットとして扱ってください — 自律的に使用しても問題ない金額のみをチャージしてください。
推奨：エージェント専用の新しいウォレットを生成してください。定期的に補充し、多額の資金が入っているウォレットを再利用しないでください。
MCPサーバーは、anchor-x402の既知のトレジャリーアドレス（402レスポンスで確認可能）へのUSDC支払い承認にのみ署名します。任意の宛先にウォレットの資金を流出させることはできません。
ソースコードは github.com/hypeprinter007-stack/anchor-x402-mcp で完全に公開されています。インストール前に監査してください。
すべての anchor_hash および attest_decision 呼び出しは、Base + SolanaのトランザクションURLを返します。これらは公開ブロックエクスプローラーで個別に検証可能です。エージェントは再支払いなしでアンカーの存在を確認できます：
Base: https://basescan.org/tx/<base.tx> — Input Dataフィールドにマークルルートが含まれています
Solana: https://solscan.io/tx/<solana.tx> — Memoプログラムデータに同じ16進数が含まれています
オンチェーンのバイトデータがレシートであり、APIレスポンスはそれらを便利にラップしたものです。完全な検証手順については オンチェーン検証入門 を参照してください。
"Payment required (402). Set ANCHOR_WALLET_PRIVATE_KEY..." ウォレットが設定されていません。MCP設定に環境変数を追加し、Claude Desktopを再起動してください。
"Payment failed (402). The wallet may be out of USDC..."
ウォレットの残高不足です。サーバーの起動ログに表示されているウォレットアドレス（stderrに payer=0x… と出力されます）にBase上のUSDCを送金してください。
"anchor-x402 request failed: ..."
ネットワークまたはDNSの問題です。https://api.anchor-x402.com/health が200を返すか確認してください。返さない場合は ステータスページ を確認してください。
ライブAPI: https://api.anchor-x402.com
サイト / トラストポータル: https://anchor-x402.com
サーバーソース: https://github.com/hypeprinter007-stack/anchor-x402
MCPサーバーソース (本リポジトリ): https://github.com/hypeprinter007-stack/anchor-x402-mcp
x402プロトコル: https://github.com/coinbase/x402
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.
x402 pay-per-call APIs over MCP, settled in USDC on Base for autonomous agents and developers.
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.
