Skip to main content
Glama
Silverkazimi

splinterlands-mcp

by Silverkazimi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

land_stake_evp_pending_claim

Retrieve the exact pending EVP claim amount for a Splinterlands player, as reported by the game's upstream API.

Instructions

Get the pending EVP claim figure the upstream reports for one account, as GET /land/stake/evp/pending-claim returns it. A successful response is {status, data}, where data is an object carrying a single pending_claim_amount field, a JSON number returned exactly as received; this server does not convert, round or accumulate it, and a change in that wire type would be reported as a malformed response rather than converted silently. What EVP is, what makes an amount claimable, and over what period the figure accrues are not stated by the response and are not claimed here. A zero is a successful answer. This server has observed zero for both a real account and a name that matches no account, while the real account's pending amount was also zero; whether this route distinguishes those cases is untested, so no answer from this tool may be read as saying that an account exists or that it does not. A call with no parameters at all was measured to answer HTTP 200 with a figure, so this tool refuses a call with no player rather than return a figure that describes nobody. This tool reports the figure the upstream returned and nothing else: it does not accumulate it, compare it with any DEC figure, or treat it as a balance.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
playerNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. 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 behavioral burden, and it is exceptionally transparent: no conversion/rounding/accumulation, zero is a valid success, upstream wire-type changes become malformed responses, and the no-account case is untested. It even discloses the measured no-parameter upstream behavior and the tool's refusal policy.

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 key purpose and response shape are front-loaded, but the description is long and partly redundant: the final sentence repeats the no-accumulation/no-comparison caveat already stated earlier. The hedging around account existence is valuable but could be tightened without losing information.

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 no output schema and no annotations, the description is remarkably complete: return envelope, field name and type, exact number semantics, failure behavior, zero handling, account-existence ambiguity, and missing-player behavior. Nothing an agent needs to call or interpret this 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?

Schema coverage is 0%, but the description compensates by explaining that the single account context is the player, that a call with no player is refused, and that the number is returned exactly as received. It does not explicitly name or format the player parameter, but the behavioral guidance goes meaningfully beyond the bare 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 names the exact resource and operation: retrieve the pending EVP claim figure as reported by GET /land/stake/evp/pending-claim for one account. It is specific enough to stand apart from the large sibling set and even clarifies what the response does not claim to define (EVP, claimability, accrual period).

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: call for one account's pending figure, and it explicitly forbids interpreting an answer as evidence of account existence. It does not name sibling alternatives such as land_stake_dec_overall or player_balances, so it stops short of the explicit when-to-use-versus-alternative guidance that would earn a 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