Skip to main content
Glama
Silverkazimi

splinterlands-mcp

by Silverkazimi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

land_resources_balances_history

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.

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. A positive offset was measured not to page conventionally; use land_resources_balances_history_window for bounded, count-checked windows.

Input 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.7/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: it discloses response envelope and field types, that the server performs no conversion/rounding/totaling, that malformed dates yield HTTP 500 while far-past ranges yield empty arrays, and that unknown players return 200 with an empty array. The pagination quirks (limit cap at 100, non-conventional offset) are also surfaced.

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?

Purpose and route are front-loaded, but the body is dense with anecdotal test evidence ('a fresh 2026-09-29 row contained nested token legs...', granular limit/offset HTTP-code transcripts) that could be condensed. It is informative but longer than necessary and buries the key routing advice at the end.

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 and no annotations, the description supplies the missing return-format, error-behavior, and pagination context an agent needs to call and interpret the tool correctly. Nothing essential is left undocumented.

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 0%, so the description must compensate, and it largely does: player is called out as a path segment, startDate/endDate are shown to accept both YYYY-MM-DD and full ISO-8601, and limit/offset behavior is described empirically. It stops short of defining the exact filtering semantics (e.g., inclusivity/which field the dates filter on), leaving a small gap.

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 states a specific verb+resource+scope ('List the resource-balance history rows ... for one account and optional dates') and pins the tool to a concrete upstream route. It explicitly distinguishes itself from the sibling by noting that bounded/count-checked windows belong to land_resources_balances_history_window.

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?

It names the alternative tool and the condition that selects it ('positive offset was measured not to page conventionally; use land_resources_balances_history_window for bounded, count-checked windows'). Combined with the warning that empty results do not establish account existence, an agent gets clear when-to-use and when-not-to-trust signals.

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