Skip to main content
Glama

FiatDock

by com.fiatdock
OverviewDiscussionsAdmin

Wallet portfolio on Base (every token, priced) ($0.0045)

wallet_portfolio
Read-onlyIdempotent

PAID ($0.0045 USDC via x402). What a Base address owns, in one call: the ETH balance read from the chain, every ERC-20 it holds with balance, market price and USD value, and a USD total. Tokens with no confident market price are listed but not counted; tokens flagged as airdropped spam (a well-known ticker from another contract, or a link or claim bait in the name) are listed, flagged and NOT counted. Send no body to get the wallet that pays. Very large wallets can time out (502, not charged). Without payment this returns the 402 challenge; the fiatdock-mcp npm package pays automatically. Any answer the tool cannot produce is >= 400 and is NOT charged.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
addressNoA 40-hex EVM address (0x…) on Base. Omit the whole body to get the paying wallet
paymentNoBase64 of a single x402 v2 PaymentPayload (EIP-3009 transferWithAuthorization on Base USDC). OMIT it on the first call: the 402 you get back carries `howToPay.payloadTemplate` — the exact envelope to fill in — plus the price and the EIP-712 domain. Send it on the second call to complete the purchase; it is forwarded as the PAYMENT-SIGNATURE header, never as body data. Nothing is charged for the 402 itself, and a call that fails after payment settles nothing.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
ethYesThe native ETH balance (read from the chain), its price and USD value
asOfYesISO time the token-balance index and the prices were read (the oldest of them)
noteYesWhat the total counts, and its limits
sourceYesWhere the data came from
tokensYesERC-20 holdings, highest USD value first (up to 100)
addressYesThe address read
networkYesChain (base)
defaultedNoPresent only when the body was empty: which subject the answer is for, and why
truncatedYesTrue when more than 100 tokens were held, or more than one call reads (300); the counts and the total then cover the tokens read
tokenCountYesERC-20 tokens held
totalValueUsdYesETH + every priced, unflagged ERC-20, in USD
pricedTokenCountYesTokens counted in the total: priced AND not flagged
flaggedTokenCountYesTokens flagged as likely airdropped spam (a well-known Base ticker from another contract, or a link or claim bait in the name) — listed, never counted

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedOutput schema / properties / asOf / description
      Previous value: -"ISO time the explorer and price data were read"New value: +"ISO time the token-balance index and the prices were read (the oldest of them)"
    • changedOutput schema / properties / flaggedTokenCount / description
      Previous value: -"Tokens the explorer flags (likely spam imitating a real token) — listed, never counted"New value: +"Tokens flagged as likely airdropped spam (a well-known Base ticker from another contract, or a link or claim bait in the name) — listed, never counted"
    • changedOutput schema / properties / truncated / description
      Previous value: -"True when more than 100 tokens were held"New value: +"True when more than 100 tokens were held, or more than one call reads (300); the counts and the total then cover the tokens read"
  2. Added

TDQS

A4.2/5.0
Behavior5/5

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

Goes well beyond the annotations: discloses the x402 paid flow, that unpriced and spam-flagged tokens are listed but excluded from the total, that omitting the body returns the paying wallet, that huge wallets can 502 without charge, that a 402 challenge is returned without charge, and that failures >=400 are not billed. This is exactly the extra behavioral context annotations can't carry.

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-loads the core purpose and is dense with useful detail, but the payment-flow sentences run long and form a near wall of text. Efficient overall, with minor redundancy around the payment/charge behavior.

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?

An output schema exists, yet the description still covers edge cases an agent needs: unpriced tokens, spam filtering, timeout behavior, and the full payment lifecycle. Nothing required to call this correctly is missing.

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

Parameters3/5

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

Schema coverage is 100%, so both parameters are already documented. The description reinforces the key nuance ('send no body to get the wallet that pays'), matching the schema, but adds no syntax or format detail beyond it. Baseline 3 is appropriate.

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?

States a specific verb and resource ('what a Base address owns, in one call') and enumerates the exact outputs: ETH balance, every ERC-20 with balance/price/USD value, and a USD total. This scope cleanly distinguishes it from siblings like eth_balance and usdc_balance, which cover only one asset.

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?

The intended usage (fetch a wallet's full priced portfolio) is clearly implied, and the payment/error context frames how to call it. But it never names an alternative or states when to prefer this over eth_balance, usdc_balance, or token_report, so the caller must infer the choice.

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

All FiatDock toolsInspect
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