Wallet profile on Base. $0.01 per call in USDC. Read-only.
Returns ETH balance, nonce, whether the address is a contract or EOA, and balances of a curated major-token list (USDC/WETH/DAI/cbETH — not full portfolio enumeration, which needs an indexer on EVM).
address: 0x-prefixed EVM address on Base
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It states the per-call cost, confirms read-only semantics, and clarifies the curated token list limitation, which is meaningful beyond the basic operation.
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 compact and front-loaded with the most important facts: what it is, cost, and read-only nature. It then provides return details and the only parameter definition without redundancy or filler.
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 single-parameter read-only inspection tool with no output schema, the description sufficiently explains the return values, scope, limitations, cost, and required input format. Nothing critical is missing for an agent to select and call it 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 description coverage is 0%, so the description must compensate. It does so by specifying that address must be a 0x-prefixed EVM address on Base, which adds the necessary format and chain context that the input schema lacks.
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 inspecting a wallet profile on Base, listing the specific return fields (ETH balance, nonce, contract/EOA status, curated token balances). It also differentiates itself from full portfolio enumeration by noting that requires an indexer on EVM, which helps distinguish it from broader lookup 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?
It implies when to use this tool for a quick, read-only wallet profile and explicitly excludes full portfolio enumeration. However, it does not directly reference sibling tools like screen_token or simulate_transaction, leaving the comparison to alternatives somewhat implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool maps to a distinct concern: gas pricing, wallet inspection, token risk, transaction simulation, and service/payment meta-info. Even the two informational tools are cleanly separated by their purpose. No likely misselection.
Names mix verb_noun patterns like inspect_wallet and simulate_transaction with noun-based patterns like gas_price and service_info. All are readable and consistently snake_case, but there is no single predictable naming convention.
Six tools is a well-scoped size for a focused Base read-only lens service. Each tool serves a clear, non-redundant purpose.
The tool set covers the main Base workflows: gas pricing, wallet inspection, token risk screening, and transaction simulation. Missing transaction/block lookup and full portfolio enumeration are moderate gaps, but some are explicitly noted as indexer-dependent limitations.