Skip to main content
Glama
Silverkazimi

splinterlands-mcp

by Silverkazimi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

land_lineup_estimate

Read-onlyIdempotent

Estimate offline land production for Grain, Wood, Stone, or Iron by analyzing worker lineups, plot terrain, boosts, and regional power to compare alternatives and validate efficiency.

Instructions

Optionally supply up to ten uniquely labelled comparisons, each with a complete lineup snapshot, to evaluate alternatives alongside the baseline in one offline call. Each result retains its own validity; any invalid result sets isError while valid alternatives remain available. Alternatives are independent, not sequential moves. Offline deterministic Land what-if for Grain/Wood/Stone/Iron worksites. Supply an ordered worker snapshot (UID, detail ID, level, base PP, element and bloodline), plot terrain and efficiency, Power Core, optional Runi and item boost fractions. Bare UIDs cannot be resolved offline. Known edition-19 abilities use the dated resource; other workers require explicit ability tuples or an empty array. Returns raw/capped Base, Boostable and Total PP, gross resource/hour, food/hour, cap losses, ability activation and validity checks. Five ordinary slots with Core/Energized; Runi alone powers four plus itself. No HTTP, signing, ownership or live staking validation. Supply exactly one of plot.efficiency or regional_power (staked_dec, current_required_dec including this plot, current_plot_required_dec). Regional mode also needs each worker’s raw land_dec_stake_needed before cap/discount; it replaces old plot demand with the estimated new demand and holds all other plots unchanged. Output reports per-worker/plot demand, regional efficiency and shortfall. Runi needs no plot DEC and runs at full efficiency. Neutral workers have zero terrain modifier; dual-element workers use the better modifier. Terrain eligibility is checked for all four resources. Castles/Keeps, SPS and Research are outside this current estimator. Public-client formula evidence is dated; use an agreeing land_lineup_snapshot baseline for live comparisons.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
plotYes
runiNo
workersYes
power_coreYes
comparisonsNo
title_boostNo
totem_boostNo
regional_powerNo

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?

Annotations already mark it read-only, idempotent, and non-destructive. The description adds substantial behavioral detail: alternatives are independent, invalid comparisons set isError while valid ones remain, bare UIDs cannot be resolved offline, edition-19 abilities use dated data, regional mode replaces only the target plot demand, and Runi behaves differently from normal workers. No contradiction with annotations.

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 dense and packed with unique, useful information; nearly every sentence adds value. However, it is a single long wall-of-text rather than a structured or front-loaded explanation, which makes it harder to scan quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the high complexity, zero schema coverage, and no output schema, this description is remarkably complete: it explains input requirements, regional mode specifics, output values, error behavior, exclusions, and caveats. Minor gaps remain around exact output structure and a few nested input fields, but nothing critical 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 description coverage is 0%, so the description carries the burden. It adds meaningful semantics for comparisons, workers, plot efficiency vs regional_power, land_dec_stake_needed, Runi, and item boosts. It does not spell out every parameter group (e.g., runi's required fields, title_boost/totem_boost exact structure, base_cap), so it is strong but not exhaustive.

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 states a specific verb and resource: it is an 'offline deterministic Land what-if for Grain/Wood/Stone/Iron worksites'. It also explains the comparison capability and explicitly distinguishes itself from land_lineup_snapshot, which is for live comparisons.

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 provides clear context: this is offline, deterministic, and does not perform HTTP, signing, or live staking validation. It names land_lineup_snapshot as the alternative for live comparisons and lists exclusions (Castles/Keeps, SPS, Research). However, it stops short of an explicit 'use this when / use that when' formulation.

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