Skip to main content
Glama

land_resources_rewardactions_count

Get the total reward-action count for a Splinterlands deed by plot ID or deed UID, as reported by upstream. Use it to check totals without fetching full lists.

Instructions

Get the reward-action count the upstream reports for one deed uid, as GET /land/resources/rewardactions/{deedUID}/count returns it. A successful response is {status, data}, where data is an object carrying count, a JSON number; this server returns it unchanged and does not convert, round or derive it. The measured count was 313 for a deed whose reward-actions list returned 100 rows by default; limit=3&offset=3 and limit=1&offset=1 both returned empty arrays, so roughly 213 counted actions were absent from those three list responses. The count and list do not contradict each other: the count reports more actions than those responses contain. Whether the count covers exactly what the list would return was not verified, so this tool does not assert equivalence. A fake deed uid returned count 0, while the list route returned data:[] for both that fake deed and a real deed with no actions; these responses do not establish what an empty deed count would be. This tool reports the count the upstream returned and nothing else, and does not claim what the count means beyond the measured response. 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
deedUIDNo
plot_idNo
deed_uidNo

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, the description fully carries the transparency burden and does so richly: it discloses the response envelope, the fact that count is returned unchanged with no conversion, the non-equivalence of count and list responses, observed fake-deed behavior, and the hard two-request resolution limit. This is far beyond what annotations would have provided.

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?

The description is front-loaded with the core purpose and response shape, but it is verbose, repeating the non-claim caveat and including lengthy empirical measurement details. These details are valuable for transparency, but the same points could be made in roughly half the length without losing meaning.

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 having no output schema and no annotations, the description is complete for a caller: it defines the response shape, clarifies count semantics, warns against assuming equivalence with list responses, covers edge cases like fake deed UIDs, and states the parameter and request-limit behavior. An agent has enough to select and invoke the 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%, but the description compensates thoroughly by explaining all parameter variants: numeric plot_id or display label, deed_uid, the original UID spelling, and the exactly-one constraint. It also explains that a verified deed GET may precede the target request, which clarifies how resolution parameters behave.

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: 'Get the reward-action count the upstream reports for one deed uid,' and ties it to the exact GET route. This clearly distinguishes it from the sibling list tool land_resources_rewardactions, which would return 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?

The description gives clear invocation guidance: supply exactly one of plot_id or deed_uid, and explains how reference resolution can add a preliminary deed GET. However, it never explicitly says when to use this count tool versus the list counterpart or when not to use it, so the usage context is mostly implied rather than 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