MCP-Server, der alle 9 anchor-x402-Dienste als Tools bereitstellt, die von jedem Claude Desktop / Cursor / Codex / Continue-Agenten aufgerufen werden können. Pay-per-Use in USDC via x402 auf dem Base-Mainnet – keine API-Schlüssel, keine Abonnements.
Neun Tools, 0,001–0,010 $ pro Aufruf:
Tool | Preis | Funktion |
| 0,005 $ | Verankert jeden 32-Byte-Hash parallel auf dem Base- und Solana-Mainnet; gibt beide Transaktions-URLs zurück |
| 0,001 $ | OFAC-SDN-Sanktionsprüfung für jede EVM- oder Solana-Wallet |
| 0,010 $ | Überprüft eine Wallet-Signatur über (input_hash, output_hash, decision); verankert das Ergebnis auf beiden Chains |
| 0,001 $ | Strukturierte Dekodierung jeder Mainnet-Transaktion (Base / Ethereum / Solana) |
| 0,001 $ | Cross-Chain-Namensauflösung (ENS, Bonfida SNS) |
| 0,001 $ | USD-Spotpreis für jeden Token nach Symbol oder Chain+Contract |
| 0,001 $ | 4byte-Selektor + ABI-Parameter-Dekodierung für rohe EVM-Calldata |
| 0,001 $ | Freiform-Datumszeichenfolge → strukturierte ISO 8601 |
| 0,005 $ | Gebündelte Wallet-Intelligenz: Guthaben + Aktivität + Identität + Sanktionen in einem Aufruf |
Der MCP-Server finanziert sich selbst – Ihre Wallet wird automatisch für jeden Aufruf belastet. Kein Vorauszahlen, kein API-Schlüssel, kein Konto.
Related MCP server: x402-bazaar-mcp
Fügen Sie dies zu ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) oder %APPDATA%\Claude\claude_desktop_config.json (Windows) hinzu:
{
"mcpServers": {
"anchor-x402": {
"command": "npx",
"args": ["-y", "anchor-x402-mcp"],
"env": {
"ANCHOR_WALLET_PRIVATE_KEY": "0xYOUR_BASE_WALLET_PRIVATE_KEY"
}
}
}
}Starten Sie Claude Desktop neu. Fragen Sie: "Anchor the hash 7646dda1564bde0ef3f3971f4c002962df64246da4aa1d8c47247e7632494710 on mainnet" – es wird anchor_hash aufrufen und 0,005 USDC von Ihrer Wallet abbuchen.
Fügen Sie dies zur .mcp.json Ihres Projekts hinzu:
{
"anchor-x402": {
"command": "npx",
"args": ["-y", "anchor-x402-mcp"],
"env": {
"ANCHOR_WALLET_PRIVATE_KEY": "0xYOUR_BASE_WALLET_PRIVATE_KEY"
}
}
}Bearbeiten Sie ~/.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"Starten Sie codex neu. Geben Sie /mcp ein, um zu bestätigen, dass anchor-x402 in der Liste der geladenen Server erscheint.
Einstellungen → Integrationen → MCP-Server → Server hinzufügen. Einfügen:
{
"command": "npx",
"args": ["-y", "anchor-x402-mcp"],
"env": {
"ANCHOR_WALLET_PRIVATE_KEY": "0xYOUR_BASE_WALLET_PRIVATE_KEY"
}
}Speichern, neu starten, die 9 Tools erscheinen in jedem Chat, in dem die Tool-Nutzung aktiviert ist.
Bearbeiten Sie ~/.cursor/mcp.json (global) oder <project>/.cursor/mcp.json (projektbezogen):
{
"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])Das gleiche Paket, die gleiche Umgebung, programmatisch statt konfigurationsgesteuert.
Gleiche Form – command: npx, args: [-y, anchor-x402-mcp], die Umgebung enthält Ihren Wallet-Schlüssel. Das MCP-SDK übernimmt den Transport.
Oder installieren Sie es über den Smithery-Einzeiler:
npx -y @smithery/cli install anchor-x402-mcp --client claude(ersetzen Sie --client claude durch cursor, codex, windsurf usw.)
ANCHOR_WALLET_PRIVATE_KEY=0xYOUR_KEY npx anchor-x402-mcpSpricht MCP über stdio. Leiten Sie es an einen beliebigen MCP-kompatiblen Client weiter.
Die Wallet, die Sie als ANCHOR_WALLET_PRIVATE_KEY festlegen, benötigt USDC auf dem Base-Mainnet. Jeder Betrag funktioniert – selbst 1 $ reicht für 100 Anchor-Aufrufe oder 1000 Commodity-Aufrufe. Senden Sie USDC an die Base-Adresse Ihrer Wallet:
USDC-Contract auf Base: 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913
Bridge vom Ethereum-Mainnet via bridge.base.org
Direkt auf Coinbase kaufen und auf Base auszahlen
Der MCP-Server signiert Zahlungen über x402 – Coinbases offenes HTTP-natives Mikrozahlungsprotokoll. Jeder Aufruf:
Erreicht einen anchor-x402-Endpunkt
Erhält eine 402 mit Zahlungsanforderungen
Der Server signiert eine USDC-Überweisungsautorisierung mit Ihrem privaten Schlüssel
Wiederholt die Anfrage mit der signierten Zahlung – die API wird über Coinbases Facilitator abgewickelt
Sie sehen die Antwort, das USDC-Guthaben Ihrer Wallet verringert sich um den Aufrufpreis. Unter einer Sekunde, kein Ledger, kein Konto.
Variable | Erforderlich? | Zweck |
| Ja für bezahlte Aufrufe | EVM-Privatschlüssel. Die Wallet bezahlt für x402-Aufrufe. |
| Nein | Überschreibt die API-Basis-URL. Standard: |
Wenn ANCHOR_WALLET_PRIVATE_KEY nicht gesetzt ist, geben bezahlte Tool-Aufrufe eine freundliche 402-Nachricht zurück, die erklärt, wie man sie einrichtet. /health und /openapi.json (nicht als Tools verfügbar, aber über direktes curl erreichbar) funktionieren ohne Zahlung.
Der private Schlüssel befindet sich in der Konfigurationsdatei Ihres MCP-Clients. Behandeln Sie ihn wie eine Hot-Wallet – zahlen Sie nur das ein, was Sie bereit sind, autonom auszugeben.
Empfehlung: Erstellen Sie eine neue Wallet speziell für die Agentennutzung. Laden Sie sie regelmäßig auf; verwenden Sie keine Wallet wieder, die über nennenswerte Mittel verfügt.
Der MCP-Server signiert nur USDC-Zahlungsautorisierungen an die bekannten Treasury-Adressen von anchor-x402 (sichtbar in der 402-Antwort). Er kann Ihre Wallet nicht auf beliebige Adressen leeren.
Der Quellcode ist vollständig offen unter github.com/hypeprinter007-stack/anchor-x402-mcp. Prüfen Sie ihn vor der Installation.
Jeder anchor_hash- und attest_decision-Aufruf gibt Base- und Solana-Transaktions-URLs zurück. Diese sind auf den öffentlichen Block-Explorern unabhängig überprüfbar – Agenten können bestätigen, dass ein Anchor existiert, ohne erneut zu bezahlen:
Base: https://basescan.org/tx/<base.tx> – Das Feld „Input Data“ enthält den Merkle-Root
Solana: https://solscan.io/tx/<solana.tx> – Die Memo-Programmdaten enthalten denselben Hex-Wert
Die On-Chain-Bytes sind die Quittung; die API-Antwort ist nur ein praktischer Wrapper darum. Siehe den Leitfaden zur On-Chain-Überprüfbarkeit für das vollständige Verifizierungsrezept.
"Payment required (402). Set ANCHOR_WALLET_PRIVATE_KEY..." Sie haben keine Wallet konfiguriert. Fügen Sie die Umgebungsvariable zu Ihrer MCP-Konfiguration hinzu und starten Sie Claude Desktop neu.
"Payment failed (402). The wallet may be out of USDC..."
Ihrer Wallet ist das Guthaben ausgegangen. Senden Sie USDC auf Base an die Wallet-Adresse, die im Startprotokoll des Servers angezeigt wird (es protokolliert payer=0x… nach stderr).
"anchor-x402 request failed: ..."
Netzwerk- oder DNS-Problem. Prüfen Sie, ob https://api.anchor-x402.com/health 200 zurückgibt; falls nicht, siehe die Statusseite.
Live-API: https://api.anchor-x402.com
Website / Trust-Portal: https://anchor-x402.com
Server-Quelle: https://github.com/hypeprinter007-stack/anchor-x402
MCP-Server-Quelle (dieses Repo): https://github.com/hypeprinter007-stack/anchor-x402-mcp
x402-Protokoll: https://github.com/coinbase/x402
MCP-Spezifikation: 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.
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.
