A read-only MCP server for verifying x402 USDC payment settlements on Base mainnet — no private keys, no signing, no transaction broadcasting.
Generic Base Chain Reads
balance — Get the native ETH balance of any address
usdc_balance — Get the USDC balance of any address
block_number — Retrieve the latest block number
get_tx_receipt — Fetch a full transaction receipt including status, gas, and logs
call — Execute a read-only eth_call against any contract
recent_transfers — Query USDC Transfer events for an address over the last N blocks (filterable by direction)
x402 Payment Verification
verify_x402_settlement — Verify a transaction hash contains a USDC Transfer matching an expected recipient and amount
parse_x402_manifest — Fetch and parse a publisher's /.well-known/x402.json to discover payment requirements
usdc_recent_payments_to — List recent incoming USDC transfers to a specific address (merchant view)
probe_x402_endpoint — Check if a URL returns a canonical x402 402 response
decode_x402_payment_payload — Offline-decode a base64 X-PAYMENT header, extracting scheme, network, EIP-3009 authorization, and signature
TensorFeed-Specific Tools
verify_afta_federation — Check a domain's AFTA (Agent Fair-Trade Agreement) certification status
tf_payment_lookup — Verify whether a transaction hash is a USDC payment to TensorFeed's canonical wallet
x402_publisher_health — Get uptime and availability stats for a domain monitored by TensorFeed
afta_federation_members — Retrieve the canonical list of confirmed AFTA federation members
The server can be configured to use Alchemy's RPC endpoint for reading Base blockchain data, enabling reliable and faster on-chain verification of USDC settlements.
Provides tools for verifying x402 payment settlements on Base mainnet, a payment protocol developed by Coinbase, allowing agents to independently audit payment receipts on-chain.
Read-only MCP server for verifying x402 USDC settlements on Base mainnet. Drop it into any MCP-compatible agent (Claude Desktop, Claude Code, Cursor, ChatGPT) to independently audit x402 payment receipts on-chain, parse publisher .well-known/x402 manifests, and check AFTA federation status. No private keys, no signing, no broadcasts.
npm install -g @tensorfeed/x402-base-mcpCoinbase shipped Base MCP (the official mcp.base.org server, launched May 2026) as the transact-side MCP: it connects an agent to a Base Account and lets the agent propose swaps, transfers, and x402 payments that the user approves in-wallet.
This package, @tensorfeed/x402-base-mcp, is the verify-side MCP. Once an x402 payment has been made (by Base MCP, by a server-side @coinbase/x402 middleware, or by any other x402 client), this server lets the calling agent independently check the on-chain settlement, parse the publisher's /.well-known/x402 manifest, and audit the receipt. Read-only chain visibility, no wallet.
The two are complementary, not competing. Use Base MCP to pay. Use this MCP to verify.
Related MCP server: obolpay-x402-mcp
x402 is a payment protocol where agents pay merchants in USDC on Base for paid API responses. When an agent receives a payment receipt back, it has two options for confirming that the settlement actually happened the way the receipt claims:
Trust the merchant
Read the on-chain Transfer event itself
Most existing EVM MCP servers either require a private key (so the agent can also send transactions, which is operationally risky and unnecessary for verification), or are generic multi-chain readers that don't speak x402. This server is the read-only, x402-aware option. Drop it into a Claude Desktop or Claude Code session and any agent can verify x402 payments without operating a wallet.
The TensorFeed-flavor tools (verify_afta_federation, tf_payment_lookup) compose the same primitives against TF's canonical surfaces and demonstrate the pattern. Use them or ignore them; the generic tools work fine on their own.
Add to claude_desktop_config.json:
{
"mcpServers": {
"tensorfeed-x402-base": {
"command": "npx",
"args": ["-y", "@tensorfeed/x402-base-mcp"]
}
}
}claude mcp add tensorfeed-x402-base -- npx -y @tensorfeed/x402-base-mcpThe server defaults to the public Base RPC (https://mainnet.base.org), which is fine for casual use. For heavier workloads, set an Alchemy or Infura URL via TENSORFEED_RPC_URL. The URL must match the allowlist in src/rpc/allowlist.ts; anything else falls back to the public endpoint and logs a warning to stderr.
export TENSORFEED_RPC_URL="https://base-mainnet.g.alchemy.com/v2/YOUR_KEY"Affiliate links if you don't already have an account:
Alchemy: https://www.alchemy.com/
Infura: https://www.infura.io/
Tool | Description |
| Native ETH balance for an address |
| USDC (Circle native bridged) balance for an address |
| Latest Base block number |
| Full tx receipt with status, gas, and logs summary |
| Read-only contract call (eth_call, never broadcasts) |
| USDC Transfer events involving an address over N blocks |
Tool | Description |
| Given a tx hash, expected recipient, and expected USDC amount, returns a structured verdict on whether the on-chain Transfer event matches. |
| Fetches |
| USDC transfers TO an address over N blocks; the merchant-side view. |
| Probes any https URL and reports whether it returns a canonical x402-paid 402 response with |
| Offline decode of a base64 |
Tool | Description |
| Calls TensorFeed's AFTA certification endpoint for a domain, returns a scored checklist. |
| Checks whether a tx hash is a USDC payment to TensorFeed's canonical wallet on Base. |
| Returns current outcome + 24h/7d uptime + recent series for a domain monitored by TensorFeed's hourly x402 status probe. |
| Returns the canonical curated list of confirmed AFTA federation members (TF origin + federated members). |
Verify an x402 settlement (works on TensorFeed's first canonical V2 payment):
verify_x402_settlement({
tx_hash: "0xe20c57d8aa6df63f75ce7a4e4c0cab492eb7fa672a23cd8fd59967eb6b66bd67",
expected_recipient: "0x549c82e6bFC54bdaE9A2073744CBC2AF5D1FC6D1",
expected_amount_usdc: "0.02"
})
// returns { ok: true, verified: true, matches: [...] }Inspect a publisher's x402 manifest:
parse_x402_manifest({ domain: "tensorfeed.ai" })Check AFTA certification:
verify_afta_federation({ domain: "tensorfeed.ai" })Read-only chain-visibility MCP. The full picture is in SECURITY.md; the short version:
No private keys, no signing, no broadcasts. The server cannot move funds.
Input validators on every tool reject malformed inputs (bad checksums, malformed hashes, URL-shaped domains, private/loopback hostnames).
Output sanitization strips C0/C1 control characters and zero-width / direction-override marks from every string returned to the calling agent.
External strings carry an _origin: "external" marker so the calling agent knows the value came from a third party.
50 KB response cap on serialized tool output; oversized responses collapse to a structured stub.
RPC allowlist limits self-hosters to known endpoints; arbitrary URLs are rejected and fall back to public Base RPC.
No telemetry, no phone-home, no analytics.
Provenance: npm releases are published via GitHub Actions OIDC with cryptographic provenance attestations. Verify with npm audit signatures.
Report security issues to security@tensorfeed.ai. Please do not file a public issue or CVE for an unfixed vulnerability.
MIT
Coinbase Base MCP - the official transact-side MCP for Base. Pair with this package for a full pay + verify loop: Base MCP signs the x402 payment, this package independently confirms the settlement on-chain.
@tensorfeed/mcp-server - companion package, the TensorFeed data MCP (news, status, models, benchmarks, premium endpoints). Complementary role: this server verifies x402 payments on-chain; mcp-server wraps the TF data API as MCP tools.
TensorFeed - AI ecosystem data layer
TensorFeed developers - free + premium API for AI agents
Agent Fair-Trade Agreement (AFTA) - open standard for honest agent commerce
x402 spec - the payment protocol this MCP verifies
Returns the native ETH balance of an address on Base mainnet.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | EVM address (0x-prefixed, checksummed) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description indicates a read-only operation. No additional behavioral context like authentication or rate limits is given. Adequate for a simple balance query.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no wasted words, front-loaded verb, and clear resource. Highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool with one parameter and no output schema, the description covers the essential information. Could mention chain specificity more explicitly, but overall 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% for the single parameter, so description adds no new meaning beyond what the input schema already provides. Baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns native ETH balance of an address on Base mainnet, with a specific verb and resource, and distinguishes from sibling tools like usdc_balance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The context implies it's for ETH balance, but lacks explicit when-not or mention of siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the latest block number on Base mainnet.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only states returns block number, no mention of read-only nature, caching, or side effects. Adequate for trivial tool but could be more explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no fluff, perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and no output schema, description is complete: tells network and what it returns. Lacks explicit return type but adequate for simple 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?
No parameters, schema coverage 100%, baseline 4. Description adds no extra param info, but schema already fully documents them.
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 the latest block number on Base mainnet, specific verb+resource, distinguishes from siblings dealing with balances, transactions, 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?
Description implies use for getting current block number; no explicit when-not or alternatives, but context is clear as siblings are for different purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Performs an eth_call against a contract on Base mainnet. Read-only; never broadcasts a transaction.
| Name | Required | Description | Default |
|---|---|---|---|
| contract | Yes | Contract address (0x-prefixed) | |
| data | Yes | ABI-encoded calldata (0x-prefixed hex, up to 64 KB) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses the key behavioral trait of being read-only and not broadcasting transactions, though it omits details like failure modes or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence that is concise, front-loaded with key information, and contains 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?
The description covers purpose and behavior well, but with no output schema, it does not mention the return format of the eth_call, which could be useful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters, so description adds no extra meaning; baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs an eth_call against a contract on Base mainnet, specifies it is read-only and never broadcasts a transaction, and distinguishes it from other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates it is for read-only contract calls, but does not explicitly state when not to use it or provide alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the receipt for a transaction on Base mainnet, including status, gas used, and a summary of emitted logs.
| Name | Required | Description | Default |
|---|---|---|---|
| tx_hash | Yes | 32-byte tx hash (0x-prefixed) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions network specificity and return contents but lacks details on idempotency, error handling (e.g., invalid hash), or read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence that is front-loaded and contains no extraneous words. Highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple with one parameter and no output schema. Description effectively conveys return contents. Minor gap: no mention of behavior for missing/invalid hashes, but overall complete enough.
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 parameter fully (32-byte tx hash). Description adds network context but no additional param details beyond schema. Baseline score of 3 applies due to 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns the transaction receipt for Base mainnet, specifying included fields (status, gas used, logs). It distinguishes from sibling tools like balance or block_number.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving transaction receipts but provides no explicit guidance on when to use this tool versus alternatives like call or balance. No exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetches https://{domain}/.well-known/x402.json (or x402) and returns the structured manifest. Used to discover what an x402-paid publisher accepts (scheme, network, payTo, prices, paid endpoints).
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Bare hostname, e.g. "tensorfeed.ai" (no scheme or path) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the fetch action and return of structured manifest, but with no annotations to lean on, it omits details about error handling (e.g., missing manifest), network dependencies, or idempotency. It is adequate but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, both front-loaded with essential information. No fluff or redundancy—every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single parameter and no output schema, the description adequately covers the tool's purpose and output ('structured manifest'). Minor gaps exist (e.g., no mention of error conditions or manifest format), but overall it is complete for a simple fetch operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear description for domain. The description does not add extra meaning beyond the schema, hitting the baseline 3. No additional context 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 title and description clearly state the tool fetches and parses a publisher's x402 manifest, specifying the well-known URL path. It distinguishes from sibling tools like verify_x402_settlement by clarifying its role in discovery of accepted schemes, networks, and prices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('Used to discover what a publisher accepts'), providing clear guidance for when to call this tool before payment. However, it does not explicitly contrast with verification siblings or 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.
Returns USDC Transfer events involving the given address over the last N blocks on Base mainnet. Direction filter: in, out, or both.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | EVM address (0x-prefixed) | |
| blocks_back | No | How many blocks back to scan (1-10000, default 1000) | |
| direction | No | Filter to incoming, outgoing, or both (default both) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the blockchain and block range limits but does not state that the operation is read-only, lacks error handling details, and does not mention any rate limits or 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?
Two concise sentences front-load the purpose and key filtering options 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 no output schema and three well-described parameters, the description covers the core functionality adequately. Missing return format details but not critical for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description repeats the direction filter and block range but adds minimal new meaning beyond the schema 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 clearly states it returns USDC Transfer events involving a given address over a block range on Base mainnet, with a direction filter. This distinguishes it from siblings like 'usdc_balance' and 'usdc_recent_payments_to' by specifying events and filtering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description explains what it does but does not mention when not to use it or compare to other tools, leaving the agent to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
On-chain lookup: was this transaction hash a USDC payment to TensorFeed's canonical payment wallet (0x549c82e6bFC54bdaE9A2073744CBC2AF5D1FC6D1) on Base mainnet? Returns structured details if yes. For credit attribution and endpoint mapping, the paying agent should call https://tensorfeed.ai/api/payment/history with its bearer token.
| Name | Required | Description | Default |
|---|---|---|---|
| tx_hash | Yes | 32-byte tx hash (0x-prefixed) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a read-only on-chain lookup but does not explicitly state it has no side effects or require permissions. It also doesn't describe behavior for non-payment transactions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with key information front-loaded. No unnecessary words; each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the main purpose, target, chain, and follow-up action. Lacks specifics on return structure, but acceptable for a simple tool without output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the tx_hash format. The description adds meaningful context about the target wallet and chain, which helps the agent understand the parameter's role beyond syntax.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks if a transaction hash is a USDC payment to a specific wallet on Base mainnet, distinguishing it from sibling tools like usdc_balance or usdc_recent_payments_to.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage for verifying a specific tx hash, but no explicit when-to-use or when-not-to-use compared to alternatives. The follow-up API call is mentioned but not as a usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the USDC balance of an address on Base mainnet (Circle native bridged USDC).
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | EVM address (0x-prefixed, checksummed) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description only states it 'returns balance', with no disclosure of behavioral traits like rate limits, permissions, or response format. For a read query, minimal but acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that is front-loaded with the action and resource, 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?
The description is adequate for a simple balance query but lacks details on the return format (e.g., wei or decimal). No output schema exists to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter, and the description does not add any extra meaning beyond the schema's 'EVM address (0x-prefixed, checksummed)'. Baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'returns', the resource 'USDC balance', and specifies the network 'Base mainnet' and token type 'Circle native bridged USDC', distinguishing it from sibling 'balance' which likely gives native ETH balance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for USDC on Base but does not explicitly state when to use this vs alternatives like 'balance' (for native token) or 'usdc_recent_payments_to'. No when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns USDC transfers TO the given address over the last N blocks on Base mainnet. A convenience wrapper for x402 merchants verifying incoming agent payments.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Recipient address (0x-prefixed) | |
| blocks_back | No | How many blocks back to scan (1-10000, default 1000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Clearly states it is a read-only operation (returns transfers) and specifies scope (last N blocks, Base mainnet). Does not disclose potential limitations like pagination or rate limits, but for a simple query tool, adequately transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states core functionality, second provides usage context. No redundant or unnecessary information. Well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema, no annotations), the description provides the essential purpose and context. Lacks details about return format or ordering, but this is acceptable for a straightforward query tool with clear sibling differentiation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. Description adds minimal value by rephrasing blocks_back as 'over the last N blocks', but essentially repeats schema. Baseline 3 due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it returns USDC transfers TO a given address over the last N blocks on Base mainnet. Specifically identifies as a convenience wrapper for x402 merchants, distinguishing it from siblings like usdc_balance or recent_transfers.
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?
Describes the target use case (x402 merchants verifying incoming agent payments), giving clear context. Does not explicitly state when not to use or list alternatives, but the specificity provides good guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calls TensorFeed's canonical AFTA certification endpoint for a domain. Returns a scored checklist of which Agent Fair-Trade Agreement tenets the domain's public surfaces satisfy. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Bare hostname, e.g. "tensorfeed.ai" |
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 states 'Read-only' which discloses non-destructiveness, but fails to mention authentication requirements, rate limits, or whether the endpoint can be called repeatedly without side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences clearly state the purpose, destination endpoint, return type, and read-only nature. No wasted words; well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool with one parameter and no output schema, the description adequately explains input and output. It could mention the return format or possible error states, but it is sufficiently complete for this low-complexity case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single domain parameter, which is described as 'Bare hostname, e.g. tensorfeed.ai'. The description adds meaning by specifying it's for AFTA certification, going beyond the schema to clarify context.
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 calls TensorFeed's AFTA certification endpoint for a domain and returns a scored checklist. It distinguishes itself from sibling tools (balance, block_number, etc.) which focus on blockchain or payment tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when checking AFTA certification for a domain but does not explicitly state when to use vs alternatives or provide exclusions. Context is clear but lacking guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Given a tx hash, expected recipient, and expected USDC amount, returns a structured verdict on whether the on-chain USDC Transfer event actually matches the claimed settlement. Use to independently verify any x402 payment receipt.
| Name | Required | Description | Default |
|---|---|---|---|
| tx_hash | Yes | 32-byte tx hash (0x-prefixed) | |
| expected_recipient | Yes | Expected payTo wallet (0x-prefixed, checksummed) | |
| expected_amount_usdc | Yes | Expected USDC amount, e.g. "0.02" or 0.02 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It does not disclose behavioral traits such as rate limits, permission requirements, or side effects. It mentions 'returns a structured verdict' but does not describe the verdict structure, leaving uncertainty about output format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no redundancy. Every word adds value: specifies inputs, action, and purpose. Front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool lacks an output schema, and the description does not explain the return value format ('structured verdict' is vague). For a verification tool, the expected result (e.g., boolean, object with fields) is critical for usage. Missing details reduce completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since schema description coverage is 100%, baseline is 3. The description adds minimal context beyond schema (e.g., 'expected' for recipient and amount), but doesn't provide additional usage nuances. It is adequate but not enriching.
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 verb 'verify' and resource 'x402 settlement', clearly stating it checks on-chain USDC Transfer against claimed settlement with given parameters. It distinguishes from siblings like parse_x402_manifest or tf_payment_lookup by focusing on independent verification of payment receipt.
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 says 'Use to independently verify any x402 payment receipt', giving clear context for when to use. However, it lacks explicit when-not-to-use scenarios or comparisons to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose: balance, block_number, call, get_tx_receipt are standard chain queries; parse_x402_manifest, tf_payment_lookup, verify_afta_federation, verify_x402_settlement are x402-specific; recent_transfers, usdc_balance, usdc_recent_payments_to are USDC-focused. No overlapping ambiguity.
All names use snake_case and are descriptive, but conventions vary: some are pure nouns (balance, block_number), others verb_noun (parse_x402_manifest, verify_x402_settlement), and some have prefixes (usdc_balance, tf_payment_lookup). Mostly consistent with minor deviations.
11 tools is well within the optimal range for a domain-specific server. Each tool serves a clear need: blockchain basics, USDC operations, and x402 payment verification. No tool feels superfluous.
Covers essential blockchain querying (balance, block, tx) and comprehensive x402 payment verification (manifest, payment lookup, settlement, federation). Minor gaps like lack of transaction simulation or ABI resolution, but for its stated purpose it's quite complete.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
x402 MCP for agents: crypto prices, funding, DeFi yields, Polymarket, Base RPC + MCP security.
Pay-per-query x402 business intelligence on Base, settled in USDC via the native 402 payment flow.
Paid x402 MCP utilities for Base-USDC balances, blocks, gas, HTTPS headers, and agent profile bios.
Pay-per-call DeFi and macro intel for AI agents. x402 USDC tools via streamable HTTP /api/mcp.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/RipperMercs/tensorfeed-x402-base-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
