Skip to main content
Glama

land_resources_richlist

Retrieves land resource richlist rankings for a specified region and resource, returning each player's amount and resource symbol.

Instructions

List the resource-richlist rows the upstream returns for one region and one resource, as GET /land/resources/richlist returns them. A successful response is {status, data}, where data is an array of rows carrying player, amount, region_uid and resource_symbol. amount is a JSON number, and this server returns it unchanged; it does not convert, round, total or compare it, and a change in that wire type would be reported as a malformed response rather than converted silently. The upstream matches resource case-sensitively against its exact symbol. This tool uppercases resource before making the request, but it does not enforce an enum because the observed symbols are not a declared exhaustive set. An unrecognised resource or region was observed to return data:[], which this server cannot distinguish from a genuinely empty ranking. Both region and resource are required by the upstream, and this tool refuses either missing parameter before making the request. This route uses region, not region_uid; other routes in this server take region_uid, and carrying that parameter name across to this route produces HTTP 400. Paging probes supplied offset=0, offset=5, page=2, cursor=5 and start=5; each returned parsed data equal to the limit=5 baseline. limit=50 returned 50 rows whose first five matched that baseline in the same order, and no ceiling was found at the tested limits 5 and 50. No value tried for offset, page, cursor or start produced a later slice. This tool reports the rows the upstream returned and nothing else.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitYes
regionYes
resourceYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. 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 carries the full burden and goes beyond basics: response shape, no conversion/rounding of amount, case-sensitive upstream with client-side uppercasing, empty-data behavior indistinguishable from genuinely empty rank, determinism of paging probes, and no observed limit ceiling. This is unusually specific behavioral disclosure.

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 front-loads the purpose and then adds only load-bearing caveats and probe results. No sentence is filler; all details prevent avoidable mis-calls.

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 tool with no annotations and no output schema, the description covers expected response, parameter constraints, known failure modes, and pagination behavior. Nothing critical appears missing for an agent to call this 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 coverage is 0%, so this section must compensate; it does. Every parameter receives meaningful semantics: resource case handling and no enum, region vs region_uid naming, limit tested at 5/50 with no ceiling, and explicit statement that paging parameters do not slice. This is far beyond bare parameter names.

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 opens with a specific verb and resource: 'List the resource-richlist rows the upstream returns for one region and one resource' and ties it to the exact endpoint. It distinguishes this route from sibling routes by noting it uses region rather than region_uid, so an agent can tell it apart without opening another schema.

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 call context: one region and one resource, both are required, and it warns not to carry the region_uid parameter from other routes because that yields HTTP 400. It does not name direct sibling alternatives, but it makes the boundary explicit enough for selection.

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