Skip to main content
Glama
Sign In
pathiel

pathiel

by Julian-dev28
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

get_history

Read-only

Retrieve an account's ledger records (fills, funding, deposits, withdrawals, or transfers) for PnL review and audits, filtered by coin and time window.

Instructions

Get the account's ledger, one kind per call. kind=fills (default): executed trades with price, size, side, fee and closed PnL, the latest fills by default, narrowed by coin and limit; start_time and end_time cut a time window (for another wallet, within its newest 2000 fills, the venue's cap). kind=funding: funding paid or received per coin between start_time and end_time. kind=deposits, withdrawals or transfers: money in, out and between perp, spot, sub-accounts and vaults since start_time; withdrawal_id checks one withdrawal's settlement. pathiel cannot move funds (its API wallet can trade, never withdraw), so these are records only. address reads any wallet. Rows come oldest first; limit (default 100, max 2000) keeps the newest. Use for PnL review and audits; for resting or cancelled orders use get_orders. Needs a configured account or an address; with neither it returns {error, no_account: true}. Returns {count, fills[]} for fills and {count, rows[]} for the other kinds.

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_history"
  }
}

Input Schema

NameRequiredDescriptionDefault
coinNokind=fills or funding: only this coin.
kindNoWhich ledger.fills
limitNoMost rows to return.
addressNoAny 0x address to read instead of the configured account (read-only; needs no key).
end_timeNoUntil this time (fills and funding). Unix time in milliseconds.
start_timeNoFrom this time. Unix time in milliseconds.
withdrawal_idNokind=withdrawals: the tx hash of one withdrawal to check.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.6.1

TDQS

A4.4/5.0
Behavior3/5

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

Annotations only declare readOnlyHint=true, so the description must add context, and it does: it discloses that pathiel cannot move funds and the API wallet can trade but never withdraw, so all rows are records only; that address is read-only and needs no key; that a foreign wallet is capped at the newest 2000 fills by the venue; and that rows come oldest first. However, this is a read-only list tool whose safety profile is already fully covered by readOnlyHint, and the description omits pagination/truncation behavior when more than 2000 rows are requested.

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?

Dense and front-loaded: the verb, resource and kind enumeration lead, usage and error behavior close. Every clause carries information, but the single-paragraph packing of seven parameters' semantics makes it harder to scan than a short structured list would be.

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?

Despite no output schema, the description states the return shapes explicitly ({count, fills[]} for fills, {count, rows[]} for the other kinds) and covers the no-account error path, the unit of time parameters, and the row ordering. For a 7-parameter read tool this is complete enough to call correctly on the first attempt.

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%, so baseline is 3, but the description genuinely adds semantics the schema lacks: the non-obvious rule that rows come oldest first while limit (default 100, max 2000 — neither bound appears in the schema) keeps the newest, the 2000-fill venue cap for foreign wallets, and which parameters apply to which kind. It does not add format detail for start_time/end_time beyond the schema's millisecond note.

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+resource ('Get the account's ledger') and immediately scopes it by an enumerated 'kind' dimension, covering fills, funding, deposits, withdrawals and transfers in one definition. It also names the sibling it is not: 'for resting or cancelled orders use get_orders.' An agent can distinguish this from get_orders and get_positions without opening any schema.

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?

Gives explicit when-to-use ('PnL review and audits'), an explicit alternative ('for resting or cancelled orders use get_orders'), and the precondition for calling it ('Needs a configured account or an address; with neither it returns {error, no_account: true}'). The per-kind usage split ('funding between start_time and end_time', 'withdrawal_id checks one withdrawal's settlement') further tells the agent which parameters pair with which mode.

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

Deploy Server

Other Tools