Skip to main content
Glama
Sign In

OpenFinance — Easy Trading: Crypto, Stocks, Perps & Prediction Markets

by tech.openfinance
OverviewDiscussionsAdmin

get_wallet_addresses

Get the caller's Privy-provisioned embedded wallet addresses. Returns both the Ethereum (EVM) address — the SAME address on every EVM chain: Ethereum mainnet, Polygon, Base, Arbitrum, Optimism, and Robinhood Chain (4663), where OpenFinance launches and USDG live — and the Solana address. Either field may be null if the user has not provisioned that chain's wallet yet.

This is usually step one for "what do I hold?": take the EVM address, then call onchain_get_address_holdings ONCE PER CHAIN (holdings are per-chain and cannot be batched). Do not report a balance from a single chain as the user's whole balance — include 4663, or a user whose tokens are all from this platform is told they hold nothing.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_wallet_addresses"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations and no output schema, the description carries the full disclosure burden and does well: it explains that the same EVM address works across all listed chains, that the Solana address is separate, and that either field may be null if the wallet is unprovisioned. It omits any statement about authentication or how the caller's identity is established, which is the remaining behavioral gap.

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-loaded with the core purpose in the first sentence, then the return contract, then usage flow. The chain enumeration and the 4663 aside are dense but each adds decision-relevant information; the prose is slightly longer than strictly needed for a no-parameter tool.

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, no annotations, and no parameters, the description is the sole source of information and it fills that role: return shape, nullability, cross-chain address equivalence, and the correct follow-up call sequence. Only the auth/identity precondition is left unstated.

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 tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. The description correctly spends its words on return semantics instead of inventing parameter guidance.

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 ('Get the caller's Privy-provisioned embedded wallet addresses') and enumerates exactly what is returned — an EVM address and a Solana address. It is clearly separable from the adjacent onchain_get_address_holdings, which retrieves holdings rather than addresses.

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

Usage Guidelines5/5

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

Explicitly positions itself as 'usually step one for what do I hold?', names the follow-up tool (onchain_get_address_holdings) and its constraint (ONCE PER CHAIN, cannot be batched). It also states an anti-pattern to avoid: reporting a single chain's balance as the whole balance, with the concrete 4663 case as justification.

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

All OpenFinance — Easy Trading: Crypto, Stocks, Perps & Prediction Markets 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