Skip to main content
Glama

get_pnl_summary

Read-onlyIdempotent

Calculate wallet-level net profit and loss across EVM, TRON, and Solana over a chosen time period. Returns total PnL in USD with per-chain and per-asset breakdowns.

Instructions

Wallet-level net PnL over a preset time window across EVM (Ethereum/Arbitrum/Polygon/Base/Optimism), TRON, and Solana. Returns the headline pnlUsd (= ending value − starting value − net user contribution), with per-chain and per-asset breakdown. Math: starting quantity per asset is reconstructed as currentQty − netFlowQty (clamped at zero when negative — user received the asset entirely within the window), priced at the period's start via DefiLlama historical, then pnlUsd = walletValueChange − (inflowsUsd − outflowsUsd). Use this for the simple 'how much did I make?' question; pair with get_portfolio_diff for the same window when the user wants the price-vs-quantity decomposition narrative. Periods: 24h / 7d / 30d / ytd / inception (capped at 365d in v1 — "since wallet creation" is not literal because the underlying history fetcher caps at ~50 items per chain). At least one of wallet / tronAddress / solanaAddress is required. v1 caveats: wallet token balances only (DeFi position interest accrual collapses into the residual); gas costs not subtracted; Solana program-interaction txs (Jupiter swaps, MarginFi actions, native staking actions) are skipped from net-flow accounting because their balance deltas mix intra-tx swap legs; truncation flagged when history caps. Bitcoin is intentionally NOT supported in v1 — the BTC path lacks in-window flow accounting and a price-effect-only number would be misleading.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
walletNoEVM wallet (Ethereum / Arbitrum / Polygon / Base / Optimism). Used to fetch current balances and walk EVM tx history for the period.
tronAddressNoTRON mainnet base58 address (T-prefix). Folds TRX + TRC-20 balances and TRON history into the PnL.
solanaAddressNoSolana mainnet base58 pubkey. Folds SOL + SPL balances and Solana history into the PnL.
periodNoTime window. "24h" / "7d" / "30d" are rolling; "mtd" is calendar-month-to-date (UTC, from the 1st of the current month); "ytd" is calendar-year-to-date (UTC); "inception" is a 365-day rolling window in v1 — "since wallet creation" is approximated, not literal, to keep the history fetch bounded. Periods longer than ~30d may under-count flows because the underlying history fetcher caps at ~50 items per chain; the response surfaces `truncated: true` when this happens.30d
Behavior5/5

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

Annotations already declare readOnlyHint=true, but the description adds substantial caveats: v1 limitations (capped history, gas not subtracted, Solana swap legs skipped, Bitcoin unsupported) and truncation flag when history caps. This goes beyond basic read-only behavior.

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?

The description is thorough and well-structured, but slightly verbose. However, every sentence serves a purpose, and key info is front-loaded.

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?

Given no output schema, the description covers all necessary contextual info: what's included/excluded, period definitions, chain support, caveats, and truncation behavior. It is highly complete for a complex tool.

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% with detailed descriptions. The description adds context like requiring at least one address and explaining the 'inception' period's 365-day cap. It adds value but the schema already handles param meaning well.

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 clearly specifies the tool's purpose: 'Wallet-level net PnL over a preset time window across EVM...' and provides a detailed mathematical formula. It distinguishes itself from the sibling `get_portfolio_diff` by noting when to pair them.

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 states when to use ('simple how much did I make?') and when to pair with `get_portfolio_diff` for decomposition. Also lists period options and required addressing at least one chain address.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/szhygulin/recon-crypto-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server