Skip to main content
Glama

land_stake_dec_staked

Lists per-region DEC staking rows for a specified player, returning amounts, claimable percentages, and transaction data from Splinterlands.

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. Changed1 schema field changedv1.0.2
    • removedInput schema / additionalProperties
      Removed value: -false
  2. First observedv0.0.0

TDQS

A4.8/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 behavioral disclosure burden. It covers response shape and fields, strict JSON number wire types, empty-array semantics for unknown or unscoped calls, the upstream route's lack of player enforcement, the wrapper's refusal of player-less calls, percent_claimable ambiguity, and the fact that no totals or region inferences are made.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Although long, the description is dense and front-loaded: purpose appears in the first sentence, and every subsequent sentence addresses a real edge case or inference hazard. With no output schema or annotations, those details are earned rather than redundant.

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 one parameter, no annotations, and no output schema, the description is self-sufficient. It documents the full response envelope, field list, empty-answer behavior, malformed-response handling, and explicit non-behaviors, so an agent has everything needed to call and interpret 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 description coverage is 0%, so the description must compensate, and it does. It explains that player identifies an account, that rows carry the account name as upstream returns it, that unknown names yield an empty array without proving nonexistence, and that the wrapper refuses calls without player even though the upstream route does not enforce it.

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 first sentence uses a specific verb ('List') and identifies the exact resource (per-region DEC staking rows for one account) as returned by GET /land/stake/decstaked. This clearly distinguishes the tool from aggregate or overall staking siblings such as land_stake_dec_overall.

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 context: use it to see raw per-region staking rows for a single account, and it explicitly states the tool does not total amounts or compare against an account's overall figure. It does not name a specific sibling alternative for aggregate figures, so it stops short of full when-to-use/alternative guidance.

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