Skip to main content
Glama

land_stake_assets

Retrieve the cards and items staked to a Splinterlands land deed using a plot ID or deed UID. Returns arrays for cards and items, including empty arrays when nothing is staked.

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. 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, and it does so richly. It discloses that wire types are JSON strings and are returned unchanged, that empty staked arrays are a success, that upstream rejections become HTTP errors rather than empty results, and that no inference is made about free slots or powered status.

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 nearly every sentence conveys necessary behavioral or edge-case information that is not available elsewhere. It front-loads the core purpose and then systematically covers wire types, empty responses, error behavior, and resolution limits. It is dense but not padded.

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 absence of an output schema, the description provides an unusually complete picture: response shape, array names, empty-success semantics, string wire types, error behavior, resolution limits, and relationship to the deed-details sibling. An agent has enough information to call this tool and interpret its results correctly.

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?

Since schema description coverage is 0%, the description serves as the only parameter guidance. It explains that plot_id can be numeric or a display label, that deed_uid is accepted, and that the original deedUid spelling also works. It also mentions reference resolution limits, but it does not fully spell out the exact format or semantics of every parameter.

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 clearly states the resource and action: it reads worker-level production figures and lists the cards and items staked to one land deed. It distinguishes itself from the sibling deed-details tool by emphasizing worker_view and per-worker figures as opposed to deed-level figures.

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 gives clear invocation constraints, such as supplying exactly one plot_id or deed_uid, and notes that the original UID spelling is accepted. It contrasts behavior with the deed-details tool on bad deed UIDs, but it stops short of explicitly stating 'use this tool when you need worker-level data, use deed-details when you need deed-level data.'

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