Skip to main content
Glama

land_resources_history

Retrieves the raw resource-history rows for a given Splinterlands transaction ID, returning each row's player, amount, end balance, operation, and other fields as the upstream API provides.

Instructions

List the resource-history rows the upstream returns for one transaction id, as GET /land/resources/history/{trx_id} returns them. 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, including signed amount values; balance_history is an array; this server returns these fields unchanged and does not convert, round, total or compare them. These rows are not the private history of the deed whose reward-action row supplied the input: in one captured transaction, both measured rows named the same player, that player was not the source deed's owner, and the rows carried no deed identifier, so nothing in the response ties them to that deed. This is a bounded observation from those two rows in that one transaction, not a claim about every transaction. This route must not be described as that deed's history. A fake transaction id returned data:[] rather than an error, so an empty array establishes neither that the id exists nor that the transaction has no rows. No measured route surfaces a trx_id except reward-action rows, so this tool is reachable only by chaining from one of those rows; otherwise a caller has no measured way to obtain its input. This tool reports the rows returned by the upstream and nothing else, and does not claim what any numeric figure means.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
trx_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.0.0

TDQS

A4.4/5.0
Behavior5/5

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

With no annotations present, the description carries the full burden and exceeds it: it discloses exact response shape, passthrough behavior (no convert/round/total/compare), empty-array semantics for fake IDs, and the absence of any linkage to a deed. The caveat that 'This route must not be described as that deed's history' prevents misinterpretation.

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

Conciseness2/5

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

The description is a single block of overly long, repetitive caveats. Core facts are buried under repeated disclaimers ('not a claim', 'bounded observation', 'must not be described', 'does not claim what any numeric figure means'). The first sentence earns its place, but most subsequent sentences could be condensed without losing 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?

Despite lacking an output schema, the description supplies the full response shape, field names, types, and key runtime behaviors (empty array, no error, unchanged numbers). The input provenance and scope limitations are also covered, so an agent can invoke the tool and interpret results correctly.

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%, but the description compensates by explaining that the trx_id comes from a reward-action row and that a fake ID yields an empty array rather than an error. It does not detail format beyond 'transaction id', but provides enough context for correct use.

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 and resource: 'List the resource-history rows the upstream returns for one transaction id', and even names the HTTP route. It clearly identifies the unique scope (one trx_id) which distinguishes it from other land_resources_* tools that operate on balances or history by different keys.

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?

Explicitly says 'this tool is reachable only by chaining from one of those rows; otherwise a caller has no measured way to obtain its input', telling the agent when it can be used displacing any ambiguity. It doesn't name alternative sibling tools, but the prerequisite is clear and actionable.

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