Skip to main content
Glama

land_resources_balances_history

Retrieve resource-balance history for a Splinterlands player, with optional date filtering, returning raw rows from the upstream endpoint.

Instructions

List the resource-balance history rows the upstream returns for one account and optional dates, as GET /land/resources/balances/history/{player} returns them. The player is a path segment on this route, not a query parameter. A successful response is {status, data}, where data is an array of rows carrying id, region_number, player, amount, end_balance, operation_id, resource_id, trx_id, created_date, balance_history and counterparty. The numeric fields are JSON numbers, created_date is a timestamp string, balance_history is an array and counterparty is a string; a fresh 2026-09-29 row contained nested token legs with token, amount, type, counterparty and per-leg trx_id. This server returns these fields unchanged and does not convert, round, total or compare them. Both YYYY-MM-DD and full ISO-8601 timestamps were accepted for startDate and endDate and produced identical results for the same calendar range. A malformed date returned HTTP 500, while a far-past date range returned a successful empty array, so this tool does not describe malformed dates as empty or unfiltered results. An unknown player returned HTTP 200 with an empty array; an empty result therefore does not establish that the account exists or does not exist. The default response contained 100 newest rows. limit=1000 and limit=500 returned HTTP 400; limit=3 with offset=0 returned three rows; limit=3 with offset=1, offset=2 and offset=3 returned HTTP 200 with empty arrays. No offset value tried reached rows beyond the newest 100. This tool reports the rows returned by the upstream and nothing else.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
offsetNo
playerYes
endDateNo
startDateNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.0.2
    • removedInput schema / additionalProperties
      Removed value: -false
  2. First observedv0.0.0

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so richly: return shape, field types, malformed-date returning HTTP 500, unknown player returning HTTP 200 empty, default 100-row cap, limit=1000/500 failing with HTTP 400, and offset behavior beyond the newest 100 rows. This is exceptional disclosure of edge cases and failure modes.

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 purpose and route, then dense with useful behavioral detail. It runs long and repeats the 'returns fields unchanged / reports only what upstream returns' idea twice, which slightly dilutes it, but nearly every sentence carries empirically useful information.

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?

No output schema exists, yet the description fully documents the {status, data} envelope and the row fields, plus pagination, date and error semantics. An agent has everything needed to call and interpret this tool correctly.

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 0%, so the description must compensate and it does: player is identified as a path segment (not query param), startDate/endDate accept both YYYY-MM-DD and ISO-8601, and limit/offset semantics are demonstrated with concrete observed outcomes. Every parameter gains meaning beyond the bare schema.

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 ('List') and resource ('resource-balance history rows for one account and optional dates') and ties it to a concrete upstream route. It is clearly distinguishable from sibling land_resources_balances_history_count by promising actual rows rather than a count.

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?

Usage context is implied through the described behavior (returns rows unchanged, does not convert/total/compare), which steers selection away from aggregation siblings. However, it never explicitly states when to prefer this over land_resources_balances_history_count or land_resources_history, and no exclusions are stated.

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