Skip to main content
Glama

land_resources_richlist

Fetch resource-richlist rows for a specified region and resource, returning player, amount, region_uid, and resource_symbol for each ranked entry.

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

TDQS

A4.7/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 it delivers richly: it discloses the exact response shape ({status, data}), that amount is returned unchanged (no conversion/rounding), case-sensitivity, the uppercasing of resource, the inability to distinguish empty results, and tested paging limits. This goes far beyond typical descriptions and leaves no behavioral ambiguity.

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 description is front-loaded with purpose but is extremely verbose, listing exhaustive probe results and edge cases. While every detail adds value, the density could overwhelm an agent; a more concise summary of key behaviors (e.g., 'no paging beyond limit', 'case-sensitive', 'empty array ambiguity') would suffice. It is not inappropriately sized, but it is not concise relative to typical tool descriptions.

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 output schema and zero schema parameter documentation, this description is exhaustive. It covers response format, error conditions, parameter requirements, case handling, and paging limitations. An agent has everything needed to call it correctly and interpret results without surprises.

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%, so the description must compensate. It explains region/resource are required, resource is uppercased, and limit is the only paging knob (tested at 5 and 50). It also notes that offset/page/cursor/start are ignored. While it doesn't formally define each parameter, it provides sufficient behavioral context for correct invocation, though limited explicit type/format details beyond the 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 clearly states the tool lists resource-richlist rows for one region and one resource, matching the upstream GET /land/resources/richlist endpoint. It distinguishes itself from sibling tools by emphasizing the region (not region_uid) parameter and proximity to land_resources_* siblings. The purpose is specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly warns that this route uses 'region' not 'region_uid' (other routes use region_uid, and using the wrong name yields HTTP 400), and states both region and resource are required. It also clarifies paging behavior (no offset/page/cursor support) and empty-array ambiguity, giving agents clear when-to-use and when-not-to-use guidance without requiring inference.

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