Skip to main content
Glama
Silverkazimi

splinterlands-mcp

by Silverkazimi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

land_resources_rewardactions

Fetch reward-action rows for a Splinterlands land deed or plot, with resource claims, tax, and transaction details, preserving numeric values as returned by the game.

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. Changed1 schema field changedv1.0.2
    • changedInput schema / properties / plot_id / anyOf
      Previous value: -[
-  {
-    "minimum": 1,
-    "type": "integer"
-  },
-  {
-    "type": "string"
-  }
-]New value: +[
+  {
+    "maximum": 9007199254740991,
+    "minimum": 1,
+    "type": "integer"
+  },
+  {
+    "type": "string"
+  }
+]
  2. First observedv0.0.0

TDQS

A4.6/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 of behavioral disclosure, and it excels. It discloses that numeric fields are returned unchanged (no conversion or rounding), that fragment_roll is passed through without interpretation, that a nonzero offset returns an empty array rather than advancing, that an empty array is ambiguous (fake or real deed with no actions), and that the tool does not interpret numeric meanings. These are significant edge cases that are clearly documented.

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?

The description is long but each sentence carries behavioral weight, covering response shape, numeric handling, offset failure, empty-array semantics, and input requirements. It is front-loaded with purpose and then layers important details. While it could be tightened, the verbosity is justified given the tool's many quirks.

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 the tool's complexity (5 params, no schema descriptions, no output schema, and multiple behavioral caveats), the description covers everything an agent needs: response structure with field list, numeric handling, offset failure, empty-array ambiguity, input requirements, and reference resolution. Nothing critical is missing.

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 does. It explains the key parameters: limit narrows from the start, offset yields empty arrays, and it clarifies the accepted identifiers (plot_id or deed_uid with spelling variants). While it doesn't describe each parameter exhaustively, it provides actionable guidance on how to use them, which is well above the baseline.

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 clear statement of purpose: 'List the reward-action rows the upstream returns for one deed uid, as GET /land/resources/rewardactions/{deedUID} returns them.' This specifies the verb (list), resource (reward-action rows), and the endpoint, making the tool's function unambiguous. It also implicitly distinguishes from the sibling count tool (land_resources_rewardactions_count) by focusing on row listing, so an agent can tell them apart.

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 explicit input requirements: 'Supply exactly one plot_id (numeric or display label) or deed_uid; the original UID spelling is also accepted.' It also gives practical usage context, such as the note that supplying a limit narrows rows from the start and that pagination is not reliable. However, it does not name alternative tools or explicitly say when not to use this tool versus related ones, which is a minor gap.

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