Skip to main content
Glama
Silverkazimi

splinterlands-mcp

by Silverkazimi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

land_stake_assets

List the cards and items staked to a Splinterlands land deed and view each worker's production breakdown.

Instructions

Read each worker’s Base Production, Base PP after cap, Terrain Boost, Boostable Production and Total Production in worker_view, alongside unchanged source cards and items. Display labels follow the public client; explicit unpowered rows display zero while missing values remain unknown. The cap preview allocates ordinary workers in ascending slot order, then adds Runi outside the cap; see splinterlands://land/rules/screen-fields for source and limits. List the cards and items staked to one land deed, as GET /land/stake/deeds/{deedUid}/assets returns them. A successful response has {status, data}, where data holds a cards array and an items array; a deed with nothing staked returns both arrays present and empty, which is a successful answer and not a failure. On this route the boost, production-point and work figures are JSON strings, not numbers, and this server returns them exactly as received: it does not convert, round, compare or combine them, and a change in that wire type would be reported as a malformed response rather than converted silently. The deed-details tool returns the equivalent deed-level figures as JSON numbers; the two routes disagree about wire type and this server does not reconcile them. Rows carry the staking account name as the upstream returns it. A deed uid the upstream rejects is answered with an HTTP error on this route and is reported as an upstream failure rather than as an empty result, so this tool and the deed-details tool do not behave alike on a bad deed uid. This tool adds only a same-response worker label view: it does not count free slots, does not infer whether a deed is powered, and makes no statement about cards the response does not list. 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

A4.5/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 and meets it: it discloses that production figures are JSON strings returned unchanged, that empty staked arrays are a successful response, that upstream-rejected deed uids surface as HTTP errors, that resolution may add a verified deed GET with a hard two-request limit, and that the tool does not infer power or available slots. It also documents the exact worker-field contents and display-label conventions.

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 very long and written as a single dense paragraph rather than being front-loaded or structured; the core 'list assets' purpose appears only in the fourth sentence. On the other hand, nearly every sentence conveys substantive operational detail, so the length is not padding.

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, no annotations, and three optional-looking parameters, the description fully covers the success shape ({status, data} with cards/items arrays), empty-result semantics, wire-type behavior, error semantics, parameter cardinality, and resolution request limits. Nothing an agent needs to call and interpret the route is left unstated.

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 identifies plot_id and deed_uid as alternatives, accepts the original camelCase spelling, and clarifies that exactly one identifier is required despite no schema-required fields. It does not fully define the accepted 'display label' format, but it adds enough mapping above the raw 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 immediately names a specific GET endpoint and states the tool 'List[s] the cards and items staked to one land deed', while also specifying the worker production fields it reads. It contrasts this route with the deed-details tool on wire type and bad-uid behavior, so it is distinguishable from its siblings.

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 gives an explicit invocation rule: 'Supply exactly one plot_id (numeric or display label) or deed_uid'. It also warns that this tool and deed-details 'do not behave alike' on a bad deed uid and that the deed-details tool returns numbers, giving an agent enough context to choose between routes, though it never says 'use this when you need assets and deed-details when you need deed-level totals'.

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