Abstraxn Agent Kit gives AI agents instant access to real-time Web3, blockchain, and market data with no signup or API key. Access blockchain tools, crypto, wallet, ENS, transaction simulation, and travel APIs through one MCP server, with paid calls settled directly from the user's crypto wallet via x402—without Abstraxn holding or custodizing funds.
Scored across 12 tools
Domain prefixes make most tools clearly distinct (weather, travel, social, places), but crypto/token functionality is split across market.crypto, network.token_price, and web3.lookup, so an agent could pick between paid and free equivalents for the same price/metadata need. The detailed descriptions resolve the ambiguity only if read carefully.
Every tool follows a consistent lowercase `domain.operation` pattern with snake_case, making the surface predictable. There are minor stylistic deviations in the operation portion (lookup/search/forecast versus noun names like blocknumber or transaction_status), but no chaotic mixing of conventions.
Twelve tools is within the ideal range and the domain-prefixed namespaces keep the surface manageable. Several tools bundle many internal actions, so the effective surface is larger than the count suggests, and a couple of redundant price/metadata tools could be consolidated.
The read/lookup surface is broadly covered: crypto markets, chain status, gas, transfer preparation, token metadata/price, transaction status, places, solar, travel, weather, social identity, and wallet/ENS/simulation. The gaps are mostly intentional read-only boundaries (no signing/broadcast) and minor optional features like travel booking or deeper social lookups.
Crypto market-data lookups (CoinGecko-sourced pricing and market data), paid per call in USDC/USDm directly from the caller's own wallet via the x402 protocol — no Abstraxn account needed. Pick one action:
search ($0.001): fuzzy-search coins by name/symbol. Requires q. Call this first to resolve a coin id before using price_feed or historical_data, both of which need an id (e.g. "bitcoin"), not a ticker.
price_feed ($0.001): current price (and optionally 24h change / market cap) for one or more coins. Requires ids (comma-separated coin ids). Optional currencies (comma-separated fiat codes, default "usd"), include_24h (default true), include_mcap (default false).
market_data ($0.002): coins ranked by market cap (or another order) — use for "top N coins" / market overview questions. Optional currency (default "usd"), category, order (default "market_cap_desc"), limit (1-250, default 100), page (default 1).
historical_data ($0.003): historical price/market cap/volume series for one coin. Requires id. Optional currency (default "usd"), days (lookback window or "max", default 30), interval (e.g. "daily").
trending ($0.001): currently trending coins by search interest. No extra parameters.
token_prices ($0.005): DEX-derived prices for up to 200 tokens in one call. Requires tokens, an array of {chain, token_address} objects.
Prices above are indicative — the exact charge for a given call is always whatever the live payment challenge specifies for that request. The first call (no paymentPayload) returns paymentRequired; retry with the same arguments plus paymentPayload to complete payment and get the real result.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | search: coin name or symbol to search for, e.g. "btc". | |
| id | No | historical_data: coin id, e.g. "bitcoin". | |
| ids | No | price_feed: comma-separated coin IDs, e.g. "bitcoin,ethereum". | |
| days | No | historical_data: lookback window in days, or "max". Default 30. | |
| page | No | market_data: page number, default 1. | |
| limit | No | market_data: max results, default 100. | |
| order | No | market_data: sort order, default "market_cap_desc". | |
| action | Yes | Which market-data operation to perform. | |
| tokens | No | token_prices: array of {chain, token_address} pairs to price, max 200 entries. | |
| category | No | market_data: category filter, e.g. "decentralized-finance-defi". | |
| currency | No | market_data / historical_data: currency code, default "usd". | |
| interval | No | historical_data: data granularity, e.g. "daily". | |
| currencies | No | price_feed: comma-separated fiat currency codes, default "usd". | |
| include_24h | No | price_feed: include 24h price change (default true). | |
| include_mcap | No | price_feed: include market cap (default false). | |
| paymentPayload | No | x402 payment payload from a previous `paymentRequired` challenge. Omit on the first call. |
| Name | Required | Description |
|---|---|---|
| error | No | |
| paymentRequired | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, but the description adds crucial context: the per-call payment via x402 from the caller's wallet, the fact that the first call returns paymentRequired and must be retried with paymentPayload, and that prices are indicative with the exact charge from the live payment challenge. This goes well beyond the annotations and illuminates the actual call flow.
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 lengthy but exceptionally well-structured with bulleted actions, pricing, required parameters, and defaults. Every sentence earns its place, and the front-loaded payment model gives immediate context. The structure is scannable and directly maps to the complex multi-action tool, making the length justified.
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 tool with 6 actions and 16 parameters, the description covers each action's purpose, pricing, required and optional parameters, defaults, and the non-trivial payment challenge flow. Since an output schema exists, there is no need to describe return values. Minor omissions like supported chains for token_prices are not essential for tool selection and invocation.
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?
Although the schema has 100% description coverage, the description enriches parameter understanding by grouping parameters per action, marking required parameters (e.g., 'Requires q', 'Requires ids', 'Requires tokens'), and clarifying critical semantics like using coin IDs rather than tickers. It also explains the paymentPayload lifecycle, which the schema only labels as a generic object.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as 'Crypto market-data lookups' with CoinGecko-sourced pricing and market data, establishing a specific verb+resource. It further enumerates six distinct actions (search, price_feed, market_data, historical_data, trending, token_prices), each with a clear functional role, making it easily distinguishable from sibling network/web3/travel 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 provides excellent within-tool usage guidance, such as 'Call this first to resolve a coin id before using price_feed or historical_data' and explains market_data is for 'top N coins' / market overview questions. However, it does not explicitly contrast alternatives across sibling tools (e.g., when to use network.token_price instead), so it stops short of fully explicit 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.
Read the current chain head — EVM block number or Solana slot — for a supported network. Free, read-only, no wallet needed.
Use this to confirm a network is progressing before submitting a transaction, correlate off-chain events with on-chain height, or choose a safe starting point when scanning logs.
Pass chain as one of: solana, solana-devnet, ethereum, sepolia, polygon, amoy, bsc, bsc-testnet, base, base-sepolia, tempo, tempo-testnet, arbitrum-one, monad, skale-base-sepolia. Omit chain (or pass all) to query every resolvable chain in one call.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | Blockchain network, or "all" (default) for every supported chain. One of: solana, solana-devnet, ethereum, sepolia, polygon, amoy, bsc, bsc-testnet, base, base-sepolia, tempo, tempo-testnet, arbitrum-one, monad, skale-base-sepolia, all |
| Name | Required | Description |
|---|---|---|
| slot | No | Solana slot number. |
| chain | No | |
| error | No | |
| blocks | No | Per-chain results, present for multi-chain queries. |
| message | No | |
| blockNumber | No | Hex-encoded EVM block number. |
| blockNumberDecimal | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds behavioral context beyond these: it clarifies that the operation is free, requires no wallet, and that omitting chain (or passing 'all') queries every resolvable chain in one call. This extra detail about multi-chain behavior and cost is valuable beyond the structured annotations.
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 well-structured: the first sentence states the core purpose, the second paragraph gives concrete use cases, and the third covers parameter details. It is compact and front-loaded, with no filler. The chain list repetition is slightly redundant with the schema but serves as helpful inline reference.
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 an output schema present, the description correctly focuses on usage context rather than return format. It covers the key aspects: purpose, supported networks, use cases, default behavior, and non-functional properties (free, read-only, no wallet). This makes the tool fully understandable for an agent to select 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?
The input schema already documents the 'chain' parameter with a full enum and description, including the default behavior for 'all'. Schema description coverage is 100%, so the bar for added value is lower. The description reiterates the chain list and default behavior but adds little new semantic meaning beyond what the schema provides.
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 reads the current chain head (EVM block number or Solana slot) for a supported network. It uses a specific verb ('Read') and resource, and distinguishes it from siblings like network.transaction_status and market.crypto by focusing on block height.
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 clear use cases: confirming network progression before a transaction, correlating off-chain events with on-chain height, and choosing a safe starting point for log scanning. It does not explicitly name alternative tools, but the context implies when this tool is appropriate versus transaction status or token pricing tools, and notes it is free and read-only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current gas price and EIP-1559 fee hints for an EVM chain. Free, read-only, no wallet needed.
Use this to estimate transaction cost or explain fees to a user before they send a transaction. chain is required. Supported chains: ethereum, sepolia, polygon, amoy, bsc, bsc-testnet, base, base-sepolia, tempo, tempo-testnet, arbitrum-one, monad, skale-base-sepolia.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | Yes | EVM network slug. One of: ethereum, sepolia, polygon, amoy, bsc, bsc-testnet, base, base-sepolia, tempo, tempo-testnet, arbitrum-one, monad, skale-base-sepolia |
| Name | Required | Description |
|---|---|---|
| chain | No | |
| error | No | |
| message | No | |
| gasPrice | No | Current gas price in wei. |
| timestamp | No | Unix ms timestamp of the reading. |
| gasPriceGwei | No | Current gas price in gwei. |
| maxFeePerGas | No | |
| supportsEip1559 | No | |
| maxPriorityFeePerGas | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds useful context: 'Free, read-only, no wallet needed' and the requirement that 'chain' is required. This adds value beyond the annotations without contradicting them.
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-loaded with the core purpose, and includes only necessary details. 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?
This is a simple single-parameter tool with an output schema available. The description sufficiently covers what the tool does, when to use it, and the required chain input. No missing critical information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description repeats the supported chains and requirement, but adds no new meaning beyond the schema. The baseline of 3 applies because the schema already documents the only parameter fully.
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 and resource: 'Get the current gas price and EIP-1559 fee hints for an EVM chain.' This is specific and differentiates from sibling tools like network.blocknumber or market.crypto.
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 clear usage context: 'Use this to estimate transaction cost or explain fees to a user before they send a transaction.' However, it does not explicitly mention when not to use or name alternative tools, so it stops short of fully distinguishing from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build an unsigned native or token transfer transaction for a supported chain, from an explicit sender you provide. Free, read-only against the chain (nonce/gas/fees are read live) — this tool never signs, broadcasts, holds a key, or enforces any allowlist/spend limit. This server never binds a caller wallet, so from is always required.
Supported chains: solana, solana-devnet, ethereum, sepolia, polygon, amoy, bsc, bsc-testnet, base, base-sepolia, tempo, tempo-testnet, arbitrum-one, monad, skale-base-sepolia.
Token (token field):
Solana: 'SOL' (native, default) or 'USDC'.
EVM: native symbol (default), 'USDC', 'USDC.e' where configured for the chain, or a raw 0x contract address (decimals are read live from the contract; token_decimals is only a fallback if that read fails).
Gas: the sender pays gas in the chain's native token once they sign — this server never sponsors it.
Raw calldata (EVM only): pass data (hex, 0x-prefixed) with to as the contract call target and amount as the native value to send (use "0" for a pure call).
Privacy (private, EVM only): requests SKALE BITE encryption, only supported on skale-base-sepolia, where it defaults to true — pass private: false there for a plaintext transfer. Rejected on every other chain.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Recipient address (0x for EVM, base58 for Solana). | |
| data | No | Hex-encoded calldata for a raw EVM contract call (0x-prefixed). Requires `to` as the call target. | |
| from | Yes | Sender address (0x for EVM, base58 for Solana). | |
| chain | Yes | Destination chain. One of: solana, solana-devnet, ethereum, sepolia, polygon, amoy, bsc, bsc-testnet, base, base-sepolia, tempo, tempo-testnet, arbitrum-one, monad, skale-base-sepolia | |
| token | No | Token symbol (native/USDC/USDC.e) or EVM contract address. Omit for the chain's native token. | |
| amount | Yes | Amount in human units (e.g. "0.1", "100"). Use "0" for a contract call that sends no native value. | |
| private | No | Request BITE privacy encryption. Only valid on skale-base-sepolia (defaults true there); rejected elsewhere. | |
| token_decimals | No | Fallback decimals for an EVM ERC-20 if a live decimals() read fails (default 18). |
| Name | Required | Description |
|---|---|---|
| to | No | |
| from | No | |
| chain | No | |
| error | No | |
| token | No | |
| amount | No | |
| policy | No | |
| status | No | |
| message | No | |
| decimals | No | |
| execution | No | |
| transaction | No | |
| amountAtomic | No | |
| tokenContract | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description extensively discloses behavioral traits beyond annotations: it's read-only, never signs or broadcasts, does not hold keys, enforces no allowlists/spend limits, and requires 'from' always. This complements readOnlyHint=true, idempotentHint=true, and destructiveHint=false perfectly, adding concrete details about live reads (nonce/gas/fees) and privacy behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections and bullet points, front-loading the key purpose. All sentences add value, but it's somewhat lengthy; could be slightly more concise without losing clarity.
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 (8 parameters, 15 chains, mixed EVM/Solana semantics, privacy options), the description is thoroughly complete. No output schema is needed for return values as the description covers the transaction building process 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 description coverage is 100%, so baseline is 3. The description adds significant semantic value beyond the schema: explains token field semantics (Solana vs EVM, raw contract address, decimals fallback), gas responsibility, raw calldata usage for EVM, and privacy specifics. Minor improvement possible with more examples or edge cases.
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: preparing an unsigned native or token transfer transaction for supported chains. It specifies the verb 'build', the resource 'unsigned transaction', and distinguishes from broadcasting/signing tools. The scope and limitations are explicit.
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 guidance on when to use this tool (free, read-only, never signs or broadcasts) and lists supported chains and token types. However, it does not explicitly state when NOT to use it or provide alternative tools for signing or broadcasting, though the sibling tools indicate this is a unique capability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read ERC-20 token metadata — name, symbol, decimals, total supply — for a token contract on an EVM chain. Free, read-only.
Pass token as a contract address (0x…) or symbol USDC / USDC.e on chains where a lookup is configured. This server never holds a caller wallet, so no balance is ever returned — only public token metadata. Both chain and token are required. Supported chains: ethereum, sepolia, polygon, amoy, bsc, bsc-testnet, base, base-sepolia, tempo, tempo-testnet, arbitrum-one, monad, skale-base-sepolia.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | Yes | EVM network for the token contract. | |
| token | Yes | ERC-20 contract address (0x…) or symbol USDC / USDC.e where configured for the chain. |
| Name | Required | Description |
|---|---|---|
| name | No | |
| chain | No | |
| error | No | |
| symbol | No | |
| message | No | |
| decimals | No | |
| timestamp | No | |
| totalSupply | No | Raw total supply (base units). |
| tokenAddress | No | |
| totalSupplyFormatted | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive hints, but the description adds meaningful behavioral context: the server never holds caller wallets, so no balance is returned, and symbol lookups only work on configured chains. This goes well beyond the structured annotations and clarifies limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with the core purpose in the first sentence. Each subsequent sentence adds necessary operational detail (token format, no balance, required fields, supported chains) with no filler. The organized structure makes it easy for an agent to scan.
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 read-only tool with two parameters and an output schema present, the description is complete. It covers what the tool does, how to pass parameters, safety characteristics, supported chains, and requirements. The output schema handles return value details, so no further description is needed.
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 baseline is 3. The description adds value by restating that both parameters are required, providing concrete examples like 'USDC' / 'USDC.e', and noting that symbol lookup is conditional on chain configuration. This extra context justifies a score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Read ERC-20 token metadata — name, symbol, decimals, total supply — for a token contract on an EVM chain.' This clearly distinguishes the tool from siblings like network.token_price by focusing on metadata, not pricing, and explicitly notes it never returns balances.
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 clear context for when to use this tool: it is free, read-only, and returns only public metadata. It also explains the token parameter format (address or symbol) and caveats that symbol lookup depends on chain configuration. However, it does not explicitly name alternative tools or state 'use X instead' for cases like price queries, which keeps it just below a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a spot token price from a public market API (CoinGecko). Free — no payment or wallet needed. Defaults to ETH/USD.
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | No | CoinGecko token id (e.g. "ethereum", "bitcoin", "solana"). Defaults to "ethereum". | |
| vsCurrency | No | Quote currency code. Defaults to "usd". |
| Name | Required | Description |
|---|---|---|
| error | No | |
| price | No | |
| source | No | e.g. "coingecko". |
| symbol | No | |
| message | No | |
| vsCurrency | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, open-world, and non-destructive. The description adds that no payment or wallet is needed, which is useful cost/auth context beyond annotations. It doesn't disclose error/rate-limit behavior, but with annotations covering safety, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, front-loaded with the core function, then cost and default behavior. Every 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?
Given the tool's simplicity, the presence of a rich output schema, full parameter coverage, and annotations, the description covers the essential behavioral context (public API, free, defaults). No major gaps for an AI agent to correctly select and invoke this 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?
Input schema covers both parameters with descriptions and defaults. The description's 'Defaults to ETH/USD' adds no new information beyond schema (symbol defaults to ethereum, vsCurrency to usd). With 100% schema coverage, the description's contribution to parameter meaning is minimal, but not incomplete.
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 fetches a spot token price from CoinGecko, using a specific verb and resource. It does not explicitly compare to sibling tools like market.crypto, but the scope is well defined. Given the mention of CoinGecko and spot price, it is easy to distinguish from other network tools, though not explicitly.
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 gives context that the API is public and free, and mentions default ETH/USD, which guides basic usage. However, it does not state when to prefer this tool over market.crypto or other siblings, nor any exclusions (e.g., not for historical data). Usage is implied but not explicitly detailed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the status of a transaction. Supports both EVM (transaction hash) and Solana (signature). Free, read-only.
Use this to confirm a transfer landed, debug a failed transaction, or report status to a user. Both chain and transaction_hash are required. Available chains: solana, solana-devnet, ethereum, sepolia, polygon, amoy, bsc, bsc-testnet, base, base-sepolia, tempo, tempo-testnet, arbitrum-one, monad, skale-base-sepolia.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | Yes | Blockchain network. One of: solana, solana-devnet, ethereum, sepolia, polygon, amoy, bsc, bsc-testnet, base, base-sepolia, tempo, tempo-testnet, arbitrum-one, monad, skale-base-sepolia | |
| transaction_hash | Yes | Transaction hash (EVM, 0x + 64 hex) or Solana signature (base58). |
| Name | Required | Description |
|---|---|---|
| to | No | |
| from | No | |
| chain | No | |
| error | No | |
| value | No | |
| status | No | e.g. "success", "failed", "not_found", "pending". |
| gasUsed | No | |
| message | No | |
| gasPrice | No | |
| timestamp | No | |
| blockNumber | No | |
| transaction_hash | No | |
| blockNumberDecimal | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint true and destructiveHint false. The description adds useful context beyond annotations: 'Free, read-only' and the support for both transaction hash formats. No contradictions exist.
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 front-loaded with purpose, followed by usage context, requirements, and a chain list. It is slightly redundant with the schema's enum list, but overall it is compact and every section serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and rich annotations, the description covers all necessary context: use cases, supported networks, parameter requirements, and safety profile. It lacks only minor behavioral details (e.g., pending timeouts) that are not essential for this 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 description coverage is 100% with detailed descriptions for both chain and transaction_hash, including enum values and format hints. The description adds little beyond repeating requirements and chain list, so it does not meaningfully enhance schema-provided semantics.
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 opens with 'Check the status of a transaction' – a clear verb+resource pair. It explicitly states support for both EVM and Solana, distinguishing it from sibling tools like network.gas_info or network.blocknumber. The purpose is unambiguous.
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 gives explicit use cases: 'confirm a transfer landed, debug a failed transaction, or report status to a user.' It also notes both parameters are required. While it does not name alternatives or exclusion criteria, the context is clear and sufficient given the sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Places, solar, and aerial-view lookups, paid per call directly from the caller's own wallet via the x402 protocol — no Abstraxn account needed. Pick one action:
text_search_full ($0.08): full-detail place text search. Requires textQuery. Optional maxResultCount (1-5, default 5), excludeFields (default ["photos"]), pageToken, locationBias ({circle:{center:{latitude,longitude},radius}}), includedType, languageCode (default "en"), openNow, minRating (0-5), priceLevels.
text_search_partial ($0.02): same as text_search_full but returns fewer fields per place — cheaper for quick lookups. Same parameters.
nearby_search_full ($0.08): full-detail search for places within a radius. Requires locationRestriction ({circle:{center:{latitude,longitude},radius (0-50000)}}) — do NOT send a bare top-level latitude/longitude/radius. Optional includedTypes/excludedTypes (max 50 each), maxResultCount (1-5, default 5), excludeFields (default ["photos"]), languageCode (default "en"), rankPreference (POPULARITY default, or DISTANCE).
nearby_search_partial ($0.02): same as nearby_search_full, fewer fields, cheaper. Same parameters.
place_details_full ($0.05): full details for one place. Requires placeId — the exact place id returned by an earlier text_search/nearby_search result; do not invent or guess it. Optional excludeFields (default ["photos"]), languageCode (default "en").
place_details_partial ($0.02): same as place_details_full, fewer fields, cheaper. Same parameters.
solar_building_insights ($0.02): rooftop solar potential for one location. Requires latitude (-90..90) and longitude (-180..180). Optional requiredQuality (LOW/MEDIUM/HIGH, default HIGH).
solar_data_layers ($0.08): raw solar data layers for an area. Requires latitude, longitude. Optional radiusMeters (0.1-175, default 50), view (default "FULL_LAYERS"), requiredQuality (default HIGH), pixelSizeMeters (default 0.25, documented as one of 0.1/0.25/0.5/1.0 but not schema-enforced), exactQualityRequired (default false).
solar_rgb_image ($0.05): renders one of the solar_data_layers assets as a viewable image. Either id (the exact asset id already returned by an earlier solar_data_layers call — "Mode A"; do not invent or guess it) OR both latitude and longitude ("Mode B") is required — provide exactly one mode, not both. Optional radiusMeters (0.1-100, default 30, Mode B only), layer (default "rgb"), month (1-12), hour (0-23), format (png/jpeg, default png), scale (1-2, default 1), crop (default false), quality (1-100, default 85).
aerial_view_lookup_video ($0.01): check whether a rendered aerial-view video already exists / poll its render status. Exactly one of address or videoId is required — videoId must be the exact value returned by an earlier aerial_view_render_video call; do not invent or guess it.
aerial_view_render_video ($0.01): kick off rendering a new aerial-view video for an address. Requires address. Poll aerial_view_lookup_video with the returned videoId until ready.
Pagination: text_search_full/partial and nearby_search_full/partial return nextPageToken when more results exist — repeat the ORIGINAL call (same textQuery / locationRestriction / etc.) with pageToken set to page further. pageToken must be the exact nextPageToken value from that earlier response — do not invent or guess it.
excludeFields: colon-separated nested-path syntax trims nested response fields, e.g. "organization:technologies" excludes just that sub-field. All place-search/details actions default-exclude photos if excludeFields is omitted — pass excludeFields: [] to include photos.
Prices above are indicative — the exact charge for a given call is always whatever the live payment challenge specifies for that request. The first call (no paymentPayload) returns paymentRequired; retry with the same arguments plus paymentPayload to complete payment and get the real result.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | solar_rgb_image (Mode A): asset id from a prior solar_data_layers call. | |
| crop | No | solar_rgb_image: crop to a circle, default false. Optional. | |
| hour | No | solar_rgb_image: hour for hourlyShade layer. Optional. | |
| view | No | solar_data_layers: which layer set to return, default FULL_LAYERS. Optional. | |
| layer | No | solar_rgb_image: which layer to render, default "rgb". Optional. | |
| month | No | solar_rgb_image: month for monthlyFlux/hourlyShade layers. Optional. | |
| scale | No | solar_rgb_image: image scale factor, default 1. Optional. | |
| action | Yes | Which places/solar/aerial-view operation to perform. | |
| format | No | solar_rgb_image: output image format, default png. Optional. | |
| address | No | aerial_view_render_video: REQUIRED address to render. aerial_view_lookup_video: exactly one of address/videoId is required. | |
| openNow | No | text_search_full / text_search_partial: only return places currently open. Optional. | |
| placeId | No | place_details_full / place_details_partial: REQUIRED place id. | |
| quality | No | solar_rgb_image: JPEG quality (1-100), default 85. Optional. | |
| videoId | No | aerial_view_lookup_video: exactly one of address/videoId is required. | |
| latitude | No | solar_building_insights / solar_data_layers / solar_rgb_image (Mode B): latitude. | |
| longitude | No | solar_building_insights / solar_data_layers / solar_rgb_image (Mode B): longitude. | |
| minRating | No | text_search_full / text_search_partial: minimum average rating filter (0-5). Optional. | |
| pageToken | No | text/nearby search: pagination token from a previous nextPageToken. Optional. | |
| textQuery | No | text_search_full / text_search_partial: free-text query, e.g. "coffee shops in Brooklyn". | |
| priceLevels | No | text_search_full / text_search_partial: filter by one or more price levels. Optional. | |
| includedType | No | text_search_full / text_search_partial: restrict to one place type, e.g. "restaurant". Optional. | |
| languageCode | No | text/nearby search, place details: response language, default "en". Optional. | |
| locationBias | No | text_search_full / text_search_partial: soft location bias. Optional. | |
| radiusMeters | No | solar_data_layers: radius in meters (0.1-175, default 50). solar_rgb_image (Mode B only): radius in meters (0.1-100, default 30). Optional. | |
| excludeFields | No | Nested-path field names to exclude from the response (colon-separated for nested paths, e.g. "organization:technologies"). Defaults to ["photos"] on every place-search/details action if omitted — pass [] to include photos. Optional. | |
| excludedTypes | No | nearby_search_full / nearby_search_partial: place types to exclude. Optional. | |
| includedTypes | No | nearby_search_full / nearby_search_partial: place types to include. Optional. | |
| maxResultCount | No | text/nearby search: max results per page (1-5, default 5). Optional. | |
| paymentPayload | No | x402 payment payload from a previous `paymentRequired` challenge. Omit on the first call. | |
| rankPreference | No | nearby_search_full / nearby_search_partial: result ranking, default POPULARITY. Optional. | |
| pixelSizeMeters | No | solar_data_layers: pixel resolution in meters, default 0.25. One of 0.1/0.25/0.5/1.0 by convention but not schema-enforced. Optional. | |
| requiredQuality | No | solar_building_insights / solar_data_layers: minimum imagery quality, default HIGH. Optional. | |
| locationRestriction | No | nearby_search_full / nearby_search_partial: REQUIRED hard boundary — {circle:{center:{latitude,longitude}, radius (0-50000)}}. | |
| exactQualityRequired | No | solar_data_layers: fail instead of falling back to lower quality, default false. Optional. |
| Name | Required | Description |
|---|---|---|
| error | No | |
| paymentRequired | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the bar is lower. The description adds significant behavioral context: the x402 payment flow (first call returns paymentRequired, retry with paymentPayload), pagination loops, default excludeFields behavior, and the two modes for solar_rgb_image (Mode A with id, Mode B with lat/lng). It does not contradict any annotation. Slightly less than 5 because the description is lengthy and some details (like defaults) are also in the schema.
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 well-structured with a bulleted list of actions, making it scannable. It front-loads the core concept (paid per call, pick one action). However, it is verbose, repeating 'same parameters' for partial variants and including many examples. Given the complexity (11 actions, 34 parameters, payment protocol), the length is justified. A score of 5 would require slightly more conciseness, such as summarizing partial variants more compactly.
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 high complexity (34 parameters, 11 actions, nested objects, payment protocol, output schema exists), the description is remarkably complete. It covers every action with required and optional parameters, defaults, special behaviors (modes, pagination, field exclusion syntax), and the two-step payment flow. It also notes that prices are indicative. The output schema is not shown, but the description does not need to explain return values. No gaps are apparent.
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%, so baseline is 3. The description adds substantial value beyond the schema: it explains the payment flow for paymentPayload, the colon-separated nested syntax for excludeFields, the two operational modes for solar_rgb_image, and the constraint that locationRestriction must be a nested circle object (not bare lat/lng/radius). It also provides default values and usage patterns (e.g., 'pageToken must be the exact nextPageToken from that earlier response'). This enriches the parameter semantics significantly.
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 explicitly states the tool's purpose: 'Places, solar, and aerial-view lookups, paid per call directly from the caller's own wallet via the x402 protocol'. It enumerates 11 distinct actions, each with a brief description of what it does and how it differs from others (e.g., full vs partial, search vs details). This clearly distinguishes between sibling actions and states the core resource (places, solar, aerial views).
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 guidance for each action: required parameters, optional parameters, defaults, and critical constraints (e.g., 'do NOT send a bare top-level latitude/longitude/radius' for nearby_search_full, 'do not invent or guess it' for placeId and videoId). It also explains the two-step payment protocol ('first call returns paymentRequired; retry with paymentPayload'), pagination mechanics, and when to use partial vs full actions (cheaper, fewer fields). No alternative tools are needed since siblings are unrelated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Flight and hotel search, paid per call in USDC/USDm directly from the caller's own wallet via the x402 protocol — no Abstraxn account needed. Pick one action:
flight_search ($0.02): live flight fares via Google Flights. Requires origin, destination, departureDate. Optional returnDate, adults, children, travelClass, stops, maxPrice, currency.
hotel_search ($0.02): live hotel prices/ratings via Google Hotels. Requires q (city or hotel name), checkInDate, checkOutDate. Optional adults, children, sortBy, minPrice, maxPrice, hotelClass, currency.
Prices above are indicative — the exact charge for a given call is always whatever the live payment challenge specifies for that request. The first call (no paymentPayload) returns paymentRequired; retry with the same arguments plus paymentPayload to complete payment and get the real result.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | hotel_search: city or hotel name to search for, e.g. "hotels in Paris". | |
| stops | No | flight_search: stop preference — 0=nonstop only, 1=up to 1 stop, 2=up to 2 stops. Optional. | |
| action | Yes | Which travel operation to perform. | |
| adults | No | flight_search / hotel_search: number of adult passengers/guests. Optional. | |
| origin | No | flight_search: departure airport IATA code, e.g. "JFK". | |
| sortBy | No | hotel_search: sort order — 3=lowest price, 8=highest rating, 13=most reviewed. Optional. | |
| children | No | flight_search / hotel_search: number of children. Optional. | |
| currency | No | flight_search / hotel_search: currency code, default "USD". | |
| maxPrice | No | flight_search / hotel_search: maximum price filter. Optional. | |
| minPrice | No | hotel_search: minimum price per night filter. Optional. | |
| hotelClass | No | hotel_search: star rating filter, 2-5. Optional. | |
| returnDate | No | flight_search: return date for round trips, YYYY-MM-DD. Optional. | |
| checkInDate | No | hotel_search: check-in date, YYYY-MM-DD. | |
| destination | No | flight_search: arrival airport IATA code, e.g. "LAX". | |
| travelClass | No | flight_search: cabin class — 1=Economy, 2=Premium Economy, 3=Business, 4=First. Optional. | |
| checkOutDate | No | hotel_search: check-out date, YYYY-MM-DD. | |
| departureDate | No | flight_search: departure date, YYYY-MM-DD. | |
| paymentPayload | No | x402 payment payload from a previous `paymentRequired` challenge. Omit on the first call. |
| Name | Required | Description |
|---|---|---|
| error | No | |
| paymentRequired | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations, disclosing that calls are paid per use via x402 from the caller's own wallet, no account needed, pricing is indicative, and the two-step payment challenge flow. This explains the tool's key behavioral trait (pay-per-call) that annotations alone don't convey.
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 lengthy but well-structured with bullet points and action-specific blocks. Every sentence provides necessary information (pricing, parameters, payment flow). It is appropriately detailed for a tool with 18 parameters and two modes, though slightly dense.
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 complex tool with two actions, 18 params, and a payment protocol, the description covers the purpose, usage, required params, payment flow, and pricing. An output schema exists, so return values are covered. The description gives the agent everything needed to invoke the tool 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 100%, so baseline is 3. The description adds value by grouping parameters under each action, marking which are required vs optional, and explaining the paymentPayload special role. This helps the agent understand the parameter relationships beyond individual schema entries.
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 explicitly states 'Flight and hotel search' with a clear verb and resource, and distinguishes the two actions (flight_search and hotel_search) with their specific purposes. It is clearly differentiated from sibling tools like network.* or market.crypto, which are unrelated to travel.
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 detailed usage context: how to choose an action, required and optional parameters per action, and the exact payment flow (first call returns paymentRequired, then retry with paymentPayload). It doesn't mention alternatives or exclusions, but sibling tools are unrelated so no explicit 'when not to use' is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Weather data from a global weather data provider — current conditions, short-range forecast, astronomy, historical, marine, and location search. Free, read-only, no wallet needed. Every action requires q, a location: a city name (e.g. "Paris"), "lat,lon" (e.g. "48.85,2.35"), a US/UK/Canadian postal code, or an IATA airport code. Pick one action:
current: current conditions for q. Optional aqi (default false) adds basic air quality data.
forecast: forecast for q. Optional days — this deployment runs on a data plan capped at 3 days, so only 1-3 is accepted; omit for the provider default. Optional aqi, alerts (default false, adds active weather alerts for the location where available).
astronomy: sunrise/sunset/moonrise/moonset/moon phase for q on date (required, YYYY-MM-DD).
search: resolve a fuzzy q into matching locations (name, region, country, lat/lon) — use this first if you only have an approximate place name and need to disambiguate.
history: past weather for q on date (required, YYYY-MM-DD, must be yesterday). This deployment enforces a free-tier data plan that only allows yesterday's date — any other date is rejected before a provider call is made.
marine: marine/sailing conditions for q. This deployment runs on a data plan limited to 1 day of data with no tide information.
Results are for general informational purposes only — do not use them as the sole basis for decisions involving personal safety, aviation, marine navigation, or emergency planning.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Location: city name, "lat,lon", postal code, or airport code. Required for every action. | |
| aqi | No | current / forecast / history: include basic air quality data (default false). | |
| date | No | astronomy / history: date in YYYY-MM-DD format. Required for both. | |
| days | No | forecast: number of forecast days (1-3 on this deployment's plan). Omit for the provider default. | |
| action | Yes | Which weather operation to perform. | |
| alerts | No | forecast: include active weather alerts for the location (default false). |
| Name | Required | Description |
|---|---|---|
| error | No | |
| message | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only and non-destructive, and the description adds important deployment limitations: forecast capped at 3 days, history only yesterday, marine limited to 1 day with no tides. It also includes an appropriate safety disclaimer about informational use.
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 long but efficiently organized: a lead sentence establishes scope, followed by one bullet per action with its relevant parameters and limitations. Every sentence adds non-redundant information that an agent needs for correct invocation.
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 six-action tool, the description covers all actions, location formats, per-action parameter applicability, deployment limits, and caveats. The presence of an output schema covers return-value details, so the description is complete for selection and invocation.
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?
Although the schema covers all parameters, the description adds real operational meaning: q format examples (city, lat,lon, postal code, IATA), which parameters apply to which action, and constraints like yesterday-only dates. This goes well beyond the schema's basic field 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 identifies the tool as a weather data provider covering current conditions, forecast, astronomy, history, marine, and location search. This specificity distinguishes it from unrelated sibling tools like network, crypto, and market 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?
Each action is documented with its own usage context, including explicit guidance to use 'search' first for approximate place names. Deployment-specific constraints like the 3-day forecast cap and yesterday-only history clarify exactly when requests will fail.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Multi-chain wallet, token, ENS, and transaction-simulation lookups, paid per call in USDC/USDm directly from the caller's own wallet via the x402 protocol — no Abstraxn account needed. Pick one action:
wallet_balances ($0.005): token balances for a wallet across 20+ chains. Requires chain and address.
wallet_transactions ($0.005): transaction history with asset transfers for a wallet. Requires address. Optional chain, limit.
wallet_pnl ($0.01): realized and unrealized profit/loss per token for a wallet. Requires chain and address.
token_metadata ($0.002): name/symbol/decimals for a token contract. Requires chain and address.
ens_resolve ($0.001): resolve an ENS name to an Ethereum address. Requires name.
ens_reverse ($0.001): resolve an Ethereum address to its ENS name. Requires address.
tx_simulate ($0.01): simulate an EVM transaction before sending — gas estimate, execution trace, revert reason. Requires network_id, from, to. Optional value, data, gas.
Prices above are indicative — the exact charge for a given call is always whatever the live payment challenge specifies for that request. The first call (no paymentPayload) returns paymentRequired; retry with the same arguments plus paymentPayload to complete payment and get the real result.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | tx_simulate: recipient/contract address for the simulated transaction. | |
| gas | No | tx_simulate: gas limit override. Optional. | |
| data | No | tx_simulate: hex-encoded calldata. Optional. | |
| from | No | tx_simulate: sender address for the simulated transaction. | |
| name | No | ens_resolve: ENS name to resolve, e.g. "vitalik.eth". | |
| chain | No | wallet_balances / wallet_transactions / wallet_pnl / token_metadata: chain name, e.g. "ethereum", "base", "solana". | |
| limit | No | wallet_transactions: max transactions to return, default 100. | |
| value | No | tx_simulate: transaction value in wei, as a string. Optional, default "0". | |
| action | Yes | Which web3 operation to perform. | |
| address | No | Address to look up — a wallet address for wallet_balances / wallet_transactions / wallet_pnl / ens_reverse, or a token contract address for token_metadata. | |
| network_id | No | tx_simulate: EVM chain id as a string, e.g. "1" or "8453". | |
| paymentPayload | No | x402 payment payload from a previous `paymentRequired` challenge. Omit on the first call. |
| Name | Required | Description |
|---|---|---|
| error | No | |
| paymentRequired | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint=true annotation, the description discloses significant behavioral traits: the pay-per-call mechanism with indicative prices, the exact charge determined by the live payment challenge, and the two-step payment flow with `paymentPayload`. It also notes that no Abstraxn account is needed. These details are not deducible from annotations alone and add substantial transparency. There is no contradiction with annotations.
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 well-structured with a clear overview sentence, a bulleted list of actions with prices and parameter requirements, and a concise note about the payment challenge flow. Every sentence provides useful information, and the format is easy to parse. Despite its length, it is not verbose or redundant.
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 (7 actions, 12 parameters, payment protocol), the description is remarkably complete. It covers all actions, their costs, required and optional parameters, the payment handshake, and clarifies the no-account requirement. With an output schema present and high schema coverage, it doesn't need to explain return values. There are no significant 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?
The schema already has descriptions for all 12 parameters (100% coverage), so baseline is 3. The description adds value by explicitly mapping which parameters are required or optional per action, and by providing examples like 'vitalik.eth' for ENS. This helps an agent select the correct parameters for a given action, which the schema alone does not do (the schema only requires `action`, not per-action prerequisites).
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 starts with a specific verb and resource: 'Multi-chain wallet, token, ENS, and transaction-simulation lookups'. It then enumerates seven distinct actions, each with a precise verb phrase (e.g., 'wallet_balances: token balances for a wallet across 20+ chains'). This clearly differentiates from sibling tools like market.crypto and network.token_price, which likely cover different lookup domains.
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 gives clear context for when to use each action, including required and optional parameters for each. For example, 'Requires `chain` and `address`' for wallet_balances, and 'Optional `chain`, `limit`' for wallet_transactions. It also explains the payment flow (first call returns paymentRequired, retry with paymentPayload). However, it doesn't explicitly mention alternatives or exclusion cases like 'use network.token_price for simple price queries', so it lacks explicit when-not guidance.
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.
weather.forecastnetwork.prepare_transferplaces.lookupsocial.profile_lookupmarket.cryptonetwork.blocknumbernetwork.gas_infonetwork.token_infonetwork.token_pricenetwork.transaction_statustravel.searchweb3.lookup
Add one secure layer between your agents and this server.
social.profile_lookupSocial / person profile lookup (pay-per-call)ARead-onlyIdempotent Inspect
Resolve person / social-profile identity for a batch of records, paid per call directly from the caller's own wallet via the x402 protocol — no Abstraxn account needed. Supports two modes per record:
Fuzzy match: supply
first_nameand/orlast_nameplusemailsand/orphones.Reverse lookup: supply only
emailsand/orphones, no name required.Every record needs a caller-chosen
record_id(any string) to correlate it with its match in the response, plus at least one non-empty first_name/last_name, or at least one non-empty entry in emails, or at least one non-empty entry in phones — an empty array counts as not provided. Optional top-levelmatch_condition_fields(e.g.["linkedin_url"]) restricts results to matches that include ALL of the named fields.The exact response shape (field names/nesting per match) is passed through unchanged from the upstream provider — read whatever comes back rather than assuming a fixed shape.
Charges ~$0.02 per call — the exact charge for a given call is always whatever the live payment challenge specifies for that request. The first call (no
paymentPayload) returnspaymentRequired; retry with the same arguments pluspaymentPayloadto complete payment and get the real result.Output Schema
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description thoroughly explains the payment flow (first call returns paymentRequired, retry with paymentPayload), the batch processing nature, and the fact that response shape is passed through from upstream provider unchanged. Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint as true/false, and the description adds significant behavioral context beyond these (payment requirements, two modes, response shape variability).
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 well-structured, front-loading the core purpose and payment model, then breaking down modes and requirements. It is slightly verbose in the parameter details section (could be more terse), but every sentence serves a purpose and the structure aids readability.
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 complexity (3 parameters, nested objects, payment protocol, output schema exists), the description is largely complete. It covers input requirements, payment flow, mode selection, result shape variability, and optional filtering. It does not explicitly state what happens on error or how to interpret the response beyond 'pass through', which is a minor gap, but the output schema helps mitigate this.
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%, so the schema already documents all parameters. The description adds significant value by explaining the two modes of operation (fuzzy match vs reverse lookup), the requirement for at least one non-empty field per record (with specific clarification about empty arrays), and the purpose of match_condition_fields. It also clarifies that record_id is caller-chosen for correlation.
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 person/social-profile identity for a batch of records, explicitly distinguishing between fuzzy match and reverse lookup modes. It provides specific verb+resource (resolve person/social-profile identity) and explains the two operational modes, making it easy to understand what the tool does and how it differs from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use each mode (fuzzy match vs reverse lookup), details the required inputs per record, explains the payment protocol (x402, pay-per-call, first call returns paymentRequired), and describes the optional match_condition_fields filter. This is comprehensive and leaves no ambiguity about invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.