Agent Data API

optimism_wallet_profile

Who is this OP Mainnet address? Wallet age (first transfer), first funder, contract or EOA, ETH balance and nonce, the latest transfers in and out (native, ERC-20, NFTs), top counterparties by count, and recent large transfers in USD (ETH, WETH, USDC, USDT), from Alchemy's transfer index; plus, from our launch history, tokens it deployed and how many lost their liquidity, and deployers it funded. Costs $0.01 USDC on Base via x402.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "address": "<address>"
    },
    "name": "optimism_wallet_profile"
  }
}

Input Schema

Name	Required	Description	Default
`address`	Yes	Wallet or contract address on OP Mainnet

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 24, 2026

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations, the description carries the burden and does reasonably well: it discloses the two data sources (Alchemy's transfer index and 'our launch history') and an explicit price of $0.01 USDC on Base via x402, which is material prepayment context. It does not cover limits (how many transfers/counterparties are returned), behavior for unknown or non-existent addresses, or failure modes, which keeps it below 5.

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

Conciseness4/5

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

Front-loading the purpose as a question works well, and every clause enumerates a returned field rather than padding. It is one long run-on sentence, though, which makes it dense to parse compared to a short lead sentence plus a bulleted payload list.

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

Completeness4/5

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

With no output schema and no annotations, the description must describe returns itself, and it does so field-by-field, plus discloses the x402 cost. Gaps remain around result cardinality, edge cases (unfunded or unindexed addresses), and error behavior, which matter for a paid profiling call.

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?

Schema coverage is 100% for the single required address parameter, so the baseline is 4. The description adds modest value by framing that the address may be a contract or EOA and that all analysis is OP Mainnet-scoped, reinforcing the network constraint the schema's description states.

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 a specific question it answers ('Who is this OP Mainnet address?') and then enumerates the concrete resource set: wallet age, first funder, EOA vs contract status, ETH balance/nonce, transfers in and out, top counterparties, and large USD transfers. This clearly distinguishes it from sibling tools like optimism_wallet_balances (balances only) and optimism_transaction_summary (single transaction), so an agent can select it without opening the schema.

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

Usage Guidelines3/5

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

Usage is implied by the breadth of the returned dossier — an agent can infer this is the 'full profile' call for an OP Mainnet address. However, it never states when to prefer optimism_wallet_balances or optimism_transaction_summary instead, nor any exclusions, so the routing is left to inference.

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

All Agent Data API tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?