Skip to main content
Glama
Silverkazimi

splinterlands-mcp

by Silverkazimi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

land_resources_rewardactions_count

Get the count of reward actions for a Splinterlands land deed by supplying a plot ID or deed UID, returning the upstream-reported numeric count.

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. 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

A3.9/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and excels. It discloses that the tool returns the count unchanged, does not assert equivalence with list results, and even reports measured anomalies (count 313 vs list 100, fake deed returning 0). This is exceptionally transparent about behavior and limitations.

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 overly long and includes excessive probing details (measured counts, verified responses, empty arrays) that are tangential. Important usage is buried in a wall of text, making it hard for an agent to parse quickly. It should be front-loaded with the purpose and essential parameters.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity, the description covers the purpose, return format, and parameter constraints well, but it omits specifics like expected error responses or the meaning of the count beyond the measured case. Some uncertainty remains, but it's adequate for an agent to invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description compensates by explaining that exactly one of plot_id or deed_uid must be supplied, and that plot_id can be numeric or display label or original UID. However, it doesn't detail the exact format of display labels or UID vs deed_uid, leaving some ambiguity.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves the reward-action count for a deed UID, matching the REST endpoint, and distinguishes it from the list tool. However, it could more concisely differentiate from siblings like land_resources_rewardactions, but the intent is clear.

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?

It explains when to use this tool (to get the count) and mentions the parameter alternatives (plot_id or deed_uid), but does not explicitly contrast with sibling list tool or other count tools. The guidance on resolution and parameters is useful but could state 'use this instead of the list when only a count is needed'.

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