Skip to main content
Glama

land_resources_rewardactions

Retrieve reward-action records for a Splinterlands land deed using its UID or plot ID, including resource, amounts, and transaction details.

Instructions

List the reward-action rows the upstream returns for one deed uid, as GET /land/resources/rewardactions/{deedUID} returns them. A successful response is {status, data}, where data is an array of rows carrying id, plot_id, tract_id, region_uid, site_efficiency, region_number, land_worksite_id, land_project_id, resource_id, resource_symbol, working_pp, duration, deed_uid, claim_amount, grain_required, claim_amount_eaten, amount_received, tax_burnt, amount_taxed, trx_description, trx_id, block_num, created_date, last_updated_date and fragment_roll. The numeric fields are JSON numbers, and this server returns them unchanged; it does not convert, round, total or compare them, and a change in their wire type would be reported as a malformed response rather than converted silently. fragment_roll is a nested object; this server returns it unchanged and does not interpret its fields. The default response contained 100 rows. A nonzero offset was measured to return data:[] rather than advance the list: limit=3&offset=3 and limit=1&offset=1 both returned empty arrays for a deed with 313 recorded actions. This is not the repeating-offset failure measured on the deeds search; it is an empty-array failure, and no offset value tried reached rows beyond the first 100. Supplying a limit narrows the returned rows from the start, but this tool does not imply that pagination works. A fake deed uid and a real deed with no actions both returned data:[], so an empty array establishes neither that the deed exists nor that it has no reward actions. A trx_id appears in these rows; this tool reports the rows returned by the upstream and nothing else, and does not claim what any numeric figure means. Supply exactly one plot_id (numeric or display label) or deed_uid; the original UID spelling is also accepted. Reference resolution may add one verified deed GET before the target GET, with a hard two-request limit. Populated resolved results include all three plot identities and resolution freshness.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
offsetNo
deedUIDNo
plot_idNo
deed_uidNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.0.0

TDQS

A4.8/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 behavioral burden and does so thoroughly. It discloses the response envelope, field types, the fact that numeric fields are returned unchanged without conversion or rounding, that fragment_roll is an uninterpreted nested object, and the exact pagination failure mode (empty arrays beyond 100 rows). It also explains the significance of empty arrays (do not prove existence) and the reference-resolution behavior. This is exceptional transparency.

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

Conciseness5/5

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

Although lengthy, every sentence adds unique information. The description is front-loaded with the core purpose and response shape, then progressively discloses behavioral caveats and parameter constraints. There is no redundancy or filler; the density is justified given the tool's complexity and lack of annotations.

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?

For a tool with no output schema and no annotations, this description is remarkably complete. It covers response structure, field lists, numeric handling, nested object behavior, pagination and offset quirks, empty-array interpretation, parameter requirements, and upstream request behavior. An agent has everything needed to invoke it correctly and interpret results.

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 entirely. It does: it explains the required selector (exactly one plot_id or deed_uid), accepts original UID spelling, describes how limit narrows results, and explicitly warns that offset does not advance the list. It also mentions reference resolution with a hard two-request limit. This adds rich 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?

The description opens with a specific verb and resource: 'List the reward-action rows the upstream returns for one deed uid.' It explicitly names the upstream endpoint GET /land/resources/rewardactions/{deedUID}, making the tool's scope unambiguous. It also distinguishes itself from sibling tools by referencing a different failure mode than 'the deeds search', which helps an agent differentiate.

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 clear context: it is for listing reward-action rows for a deed, and it gives explicit input constraints ('Supply exactly one plot_id (numeric or display label) or deed_uid'). It also warns about reference resolution and pagination limitations. However, it does not explicitly name sibling alternatives or state when to prefer this tool over land_resources_rewardactions_count or other related tools, so it stops short of a 5.

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