Abstraxn

Wallet / token / ENS / tx-simulation lookups (pay-per-call)

web3.lookup

Read-onlyIdempotent

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.

Input Schema

TableJSON Schema

Name	Required	Description
`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.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`error`	No
`paymentRequired`	No

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and idempotentHint=true, but the description adds vital behavioral details: the payment protocol, the two-step paymentRequired flow, and the note that prices are indicative while exact charges come from the live challenge. This goes beyond the structured annotations and helps the agent manage the payment round-trip.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is structured as a bullet list with one line per action, each containing price, scope, and required parameters. It is front-loaded with the main purpose and payment model, and no sentence is redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 12 parameters and a pay-per-call flow, the description covers all major aspects: payment challenge handling, per-action requirements, optional parameters, and the nature of results (e.g., tx_simulate returns gas estimate and trace). The presence of an output schema means return values don't need to be detailed, but the description still gives a preview.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema covers all 12 parameters with descriptions, so baseline is 3. The description adds per-action parameter requirements, examples (e.g., 'vitalik.eth' for ens_resolve, chain names like 'ethereum', 'base', 'solana'), and clarifies which parameters are required for each action. This makes it easier to construct a correct call.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Multi-chain wallet, token, ENS, and transaction-simulation lookups' which clearly states the tool's function. It enumerates seven distinct actions (wallet_balances, wallet_transactions, etc.), each with a specific purpose, distinguishing it from sibling tools focused on network or market data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on which action to use for each lookup, including required parameters for each. It notes the pay-per-call x402 flow and the need to retry with paymentPayload, but it does not explicitly contrast with sibling tools or state when this tool should not be used.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Abstraxn tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0

Disambiguation4/5

Tools are grouped by domain (market, network, places, social, travel, web3) and each has a distinct purpose. However, within the 'network' group, tools like token_price, token_info, and market.crypto/price_feed could be confused for similar price lookups, but descriptions clarify their differences (free vs paid, DEX vs CoinGecko).

Naming Consistency3/5

The naming uses a dot-separated domain prefix (e.g., market.crypto, network.blocknumber, places.lookup) which is consistent in structure, but the action selection within each tool (e.g., search vs price_feed) is not reflected in the tool name itself. This hybrid approach is clear but not strictly uniform.

Tool Count4/5

With 11 tools covering a wide range of domains (crypto, network, places, social, travel, web3), the count is appropriate for a multi-purpose server. Each domain has a focused set of actions, so the tool count feels well-scoped without being excessive.

Completeness3/5

The server covers a broad but shallow surface across multiple domains. For example, crypto market data is well-covered, but places lacks a reverse geocode or photo tool. Travel has only flight and hotel search, missing car rentals or activities. The network domain is relatively complete for read operations, but lacks write support beyond prepare_transfer.

Resources

Need Help?