Skip to main content
Glama
tamasPetki

HeadlessTracker

by tamasPetki
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Local

get_pnl

Returns aggregate profit and loss across all connected accounts, including current value, cost basis, and realized/unrealized PnL. Supports optional timeframes, cost-basis methods, and multi-currency conversion.

Instructions

Returns aggregate profit/loss across all configured accounts. Use this when the user asks: 'how am I doing', 'what's my P&L', 'am I up or down', 'show profit', 'show losses', or wants any portfolio performance summary. Returned fields per account and across the total: - currentValue (USD) — current portfolio value - costBasis (USD) — sum of avgCost * quantity (where the connector tracks it) - unrealizedPnl (USD) — currentValue - costBasis (for positions still held) - realizedPnl (USD) — already-closed P&L from connector metadata - notes — caveats per connector (e.g. MetaMask doesn't track cost basis) Inputs (optional): - account_id: scope to one account. - timeframe: '24h' | '7d' | '30d' | 'ytd' | 'all'. When set to anything other than 'all', the result includes a windowDelta block computed from CoinGecko historical prices. APPROXIMATION CAVEAT: it values your CURRENT basket at historical prices vs current prices — it does NOT account for trades within the window. Communicate this honestly to the user. Polymarket positions and tokens without a CoinGecko mapping are skipped (counted in skippedSymbols). CoinGecko free-tier historical is daily granularity, so '24h' = 'yesterday's close'. - include_history (boolean, default false): also pulls transactions and runs a cost-basis ledger over them, returning realizedFromHistory per account + total. Costs an extra round-trip per account but unlocks honest realized PnL on tokens born on-chain (LP rewards, swaps, native airdrops). Tokens that arrived via wallet transfer-in (no price) get unknownSalesCount not inflated knownRealized — explicit honesty about what cost basis we know. POLYMARKET-SPECIFIC: when include_history=true, the Polymarket account's realizedPnl is replaced by the cost-basis-from-/trades number. Default mode leaves Polymarket realizedPnl null because the connector's cashPnl mixes realized + unrealized — set include_history=true to get the real realized number. - method ('fifo' | 'average', default 'fifo'): cost basis method used when include_history=true. FIFO consumes oldest lot first per sell; Average Cost pools all priced acquisitions and sells out at the running average. If the user mentions 'average cost' / 'avg cost' / 'weighted', use 'average'. Both methods preserve the 'honest unknown' rule: any sell drawing from an unpriced deposit/transfer returns realizedPnl=null, NOT a fabricated number. Has NO effect when include_history=false. - currency ('USD' | 'EUR' | 'GBP' | 'HUF', default 'USD'): when set to anything other than USD, ALL numeric fields (currentValue, costBasis, realizedPnl, unrealizedPnl, windowDelta numbers, realizedFromHistory.knownRealized) are converted via live FX rates. The fx.source + fetchedAt are surfaced in meta.fx. Use this for currency-consistent rendering when the user asked their dashboard to be in HUF/EUR/GBP — otherwise per-tab currencies will mismatch. Returns position data only. Not financial advice.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
account_idNoScope to one account (e.g. 'bybit:UNIFIED'). Omit for P&L across all accounts.
timeframeNoDefault 'all'. Any non-'all' value adds a windowDelta block (current basket valued at historical vs current CoinGecko prices). APPROXIMATION: it does NOT account for trades within the window; surface that caveat. Daily granularity, so '24h' = since yesterday's close.
include_historyNoDefault false. When true, also fetches transactions and runs a cost-basis ledger for honest realizedFromHistory per account (one extra round-trip each). Required to get Polymarket's real realized P&L (null otherwise).
methodNoCost-basis method when include_history=true (default 'fifo'). Use 'average' if the user says 'average/avg/weighted cost'. No effect when include_history=false.
currencyNoDisplay currency for all numeric fields (default 'USD'). Non-USD converts via live FX; source/rate appear in meta.fx. Use for currency-consistent dashboards.

Tool Definition Quality

A4.6/5.0
Behavior5/5

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

With no annotations, the description fully covers behavioral traits: approximation caveats for windowDelta, CoinGecko limitations, skipping Polymarket and tokens without mapping, extra round-trips for include_history, cost basis method effects, and currency conversion with source disclosure. It also includes a disclaimer.

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

Conciseness3/5

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

The description is very long and detailed, which can hinder quick parsing by an AI agent. While it is well-structured with front-loaded purpose, the verbosity could be reduced for better conciseness.

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 thoroughly explains return fields and caveats (currentValue, costBasis, realizedPnl, etc.). It covers edge cases like Polymarket, unknown cost basis, and currency conversion, making it complete for a tool of this complexity.

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

Parameters5/5

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

Schema coverage is 100%, but the description adds significant value beyond the schema for each parameter: account_id omitting for cross-account, timeframe approximation and granularity, include_history trade-offs, method selection based on user language, and currency conversion details. This far exceeds baseline.

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 explicitly states it returns aggregate profit/loss across all accounts and gives specific user queries that trigger its use (e.g., 'how am I doing', 'what's my P&L'). It clearly distinguishes from sibling tools like get_holdings and get_transactions by focusing on P&L summary.

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

Usage Guidelines4/5

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

The description provides explicit triggers for when to use the tool and detailed guidelines for parameters (e.g., when to set include_history, timeframe, method, currency). It does not explicitly list when not to use it, but the context implies alternatives exist for specific positions.

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/tamasPetki/HeadlessTracker'

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