Skip to main content
Glama

land_stake_dec_staked

Get an account's per-region DEC staking rows, including staked amounts and claimable percentages, from Splinterlands. Pass a player name to see their staked DEC details.

Instructions

List the per-region DEC staking rows the upstream reports for one account, as GET /land/stake/decstaked returns them. A successful response is {status, data}, where data is an array of rows carrying id, region_uid, player, amount, percent_claimable, last_trx, created_date and last_updated_date. Every numeric field on this route is a JSON number, and a change in that wire type would be reported as a malformed response rather than converted silently. Rows carry the account name as the upstream returns it. An empty array is a successful answer, and an unknown name and an unscoped call were observed to return an empty array; behaviour for a known account with no staked DEC was not captured, so an empty answer establishes neither that an account exists nor that it does not. This route does not enforce its declared-required player parameter — a call with no parameters at all was measured to return that same empty array — so this tool refuses a call with no player rather than return an unscoped empty answer as though it described somebody. What percent_claimable measures is not stated by the response and is not claimed here. This tool reports the rows the upstream returned and nothing else: it does not total the amounts, does not compare them with the account's overall figure, and makes no statement about regions the response does not list.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
playerNo

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 full behavioral burden and meets it: it defines the {status, data} envelope, enumerates row fields, discloses JSON number wire-type handling, empty-array semantics, upstream parameter-enforcement inconsistency, and the refusal to infer meaning for percent_claimable or totals. This exceeds typical disclosure.

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 dense and front-loaded, with the fundamental purpose first followed by response shape, edge cases, and explicit non-claims. Some sentences are defensive (e.g., wire-type behavior), but they add value in a tool with no annotations. It could be tightened slightly 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?

For a one-parameter tool with no output schema, the description fully covers response structure, field names, success behavior, failure/edge behavior, and the tool's enforced input policy. Nothing needed to invoke or interpret the tool correctly 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?

The schema only gives player as a string with minLength 1 and 0% description coverage, but the description compensates by identifying the player as the account whose rows are listed and by explaining exactly how missing player input is handled (refused rather than silently unscoped). It could add more explicit account-name format detail, but what is present is actionable.

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 opening sentence states a specific action ('List') and precise resource ('per-region DEC staking rows ... for one account'), and ties it to the upstream route GET /land/stake/decstaked. This is distinct from nearby siblings like land_stake_dec_overall or land_stake_dec_region because it emphasizes per-region rows for a single account.

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 clear context for invoking the tool: a single account is expected, the tool refuses calls with no player, and an empty array must not be treated as proof of account non-existence. It does not explicitly name alternative tools or state when to prefer them, so it stops short of a full 5.

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